https://www.ads-software.com/plugins/plugin-organizer/ Breaks 3.7

Or honestly, make your own table for this sort of thing.

You’re wanting to store a bunch of information indexed by (essentially) the permalink, and then to be able to retrieve it prior to the main query being executed, then use that information to change the load sequence accordingly.

This sort of thing obviously isn’t suitable for the posts table, because the query hasn’t executed yet and the rewrites have not even been parsed. WordPress, at that point in time, has no idea what post is actually being queried for. It won’t know that until the wp() function is run, which doesn’t happen until after wp-load.php has exited.

All the stuff WordPress does inside the wp-load process is to load stuff up. It doesn’t parse the query until the wp() function is called (from wp-blog-header.php), which in turn calls the $wp->main() code. The main query isn’t ready until the ‘wp’ action fires. So even ‘init’ is really too early to base anything off the main page query.

So you’re basically having to do your own index based on the URL in some way, or execute a whole long running query process. But what you really want is just some data about the post that the current URL is referring to.

Which sounds very much like a case of “make your own table” to me. Two columns, one can be the url or whatever index you wish to use, the other can be an array of the plugins or whatever information you want to use to change the load order.

Normal queries don’t happen until the load order is well and truly over, so changing the load order based on the query is always going to be problematic, no matter how you slice it. Perhaps the queried URL is more reliable for your needs.

Ok so you are obviously not going to see that this is a bug and not a feature, as you have explained it. If the meta table is not built for searching why would you ever put functionality into the core to search off of the meta value? Why is it not valid to use a function that has been provided in earlier included code at the time my plugin executes its option hook?
Its not about the rules you have made for the wordpress core. Its about basic structure. If you provide me a function it should work. If that function worked without errors in the past you should not introduce an error and then blame the person calling your provided function. There was a set variable in the old version of the function. It has been replaced by an undefined function call.
There is no reason I can’t retrieve a post once the functionality is included. I don’t want the other plugins added functionality to interfere with my queries so waiting until they are loaded would not make any sense. I can understand that you are saying the core is built that way and it is not going to change. So I guess I will have to move some or all of the data into a separate table and go back to dealing with the headaches this caused so many people.

If the meta table is not built for searching why would you ever put functionality into the core to search off of the meta value?

Oh, believe me, if I was in charge, that functionality would not be there.

Why is it not valid to use a function that has been provided in earlier included code at the time my plugin executes its option hook?

Because the function has not been loaded yet. There are cross-intersecting concerns here. Functions use code from many other files in various ways. And yet the files have to load in some particular order. If you try to do things before the relevant functions are loaded and ready, then you’re going to get errors or incorrect results. Pick your poison.

If you provide me a function it should work. If that function worked without errors in the past you should not introduce an error and then blame the person calling your provided function. There was a set variable in the old version of the function. It has been replaced by an undefined function call.

Like I said earlier, the fatal error has been fixed in the latest trunk version of WordPress, and the fix will very likely be in 3.7.1. However, that doesn’t make calling this function too early capable of giving you the correct responses.

You’re relying on undocumented and undefined behaviors of a complex system. There are defined and supported behaviors for functions and timing and when things are supposed to happen. And then there are side-effects. You have been relying on the fact that a side-effect worked for a very long time, but that effect was never an intended or documented behavior. So when it broke, well, I’m surprised that you are surprised.

There is no reason I can’t retrieve a post once the functionality is included.

Even with the fix, you still cannot retrieve the post *properly* because the users have not loaded. And if your suggested fix of loading pluggable.php yourself is implemented, then you break other plugins that are trying to override the pluggable functions.

Essentially, you have a no-win situation. I’m trying to suggest a way for you to win the situation, and that way is to not store this information in posts or post meta, and to not use post-queries to access it. This solves your problem. I’m sorry that you don’t like the solution or my answers, but those answers are not going to change just because you disagree with them.

You’re free to disagree with me. I don’t mind. Many do. But I’m legitimately trying to help you here by telling you ways of restructuring your code to overcome your problems and future-proof it. I’m not just being a dick. Really.

The wp_query->get_posts function has been modified in the new version of WordPress. It now calls a function defined in pluggable.php which isn’t defined until after plugins are loaded.

Fixed in WordPress 3.7.1: https://core.trac.www.ads-software.com/ticket/25690.

Aside from the code change that caused this error there needs to be a function where I can give it a string and it returns an array of post id’s by matching it on the meta values in the database. Having to return an array containing the entire post object for several posts when I just need the post_id is ridiculous bloat.

You can add 'fields' => 'ids' to your get_posts() call if you only need the IDs. I would really look into implementing Otto’s suggestions though.