Title: http://wordpress.org/plugins/plugin-organizer/ Breaks 3.7 Last modified: August 21, 2016 --- # http://wordpress.org/plugins/plugin-organizer/ Breaks 3.7 * [Radices](https://wordpress.org/support/users/radices/) * (@radices) * [12 years, 6 months ago](https://wordpress.org/support/topic/httpwordpressorgpluginsplugin-organizer-breaks-37/) * Should add this one to the Master List. The author is working on a fix. Hacking the core can work as a temporary solution. (Did for me) * Call to undefined function wp_get_current_user() in /home/…/public_html/…/wordpress/ wp-includes/user.php on line 215 * that doesn’t require the uploading of the entire INCLUDES directory. * You need to add this line to the top of your CAPABILITIES.PHP file – * require_once (‘pluggable.php’); * so it looks like this – * ``` 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. * [Jeff Sterup](https://wordpress.org/support/users/foomagoo/) * (@foomagoo) * [12 years, 6 months ago](https://wordpress.org/support/topic/httpwordpressorgpluginsplugin-organizer-breaks-37/page/2/#post-4257708) * 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. * Moderator [Samuel Wood (Otto)](https://wordpress.org/support/users/otto42/) * (@otto42) * WordPress.org Admin * [12 years, 6 months ago](https://wordpress.org/support/topic/httpwordpressorgpluginsplugin-organizer-breaks-37/page/2/#post-4257709) * > 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. * Moderator [Sergey Biryukov](https://wordpress.org/support/users/sergeybiryukov/) * (@sergeybiryukov) * WordPress Dev * [12 years, 6 months ago](https://wordpress.org/support/topic/httpwordpressorgpluginsplugin-organizer-breaks-37/page/2/#post-4257711) * > 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: [http://core.trac.wordpress.org/ticket/25690](http://core.trac.wordpress.org/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. Viewing 4 replies - 16 through 19 (of 19 total) [←](https://wordpress.org/support/topic/httpwordpressorgpluginsplugin-organizer-breaks-37/?output_format=md) [1](https://wordpress.org/support/topic/httpwordpressorgpluginsplugin-organizer-breaks-37/?output_format=md) 2 The topic ‘http://wordpress.org/plugins/plugin-organizer/ Breaks 3.7’ is closed to new replies. * In: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/) * 19 replies * 5 participants * Last reply from: [Sergey Biryukov](https://wordpress.org/support/users/sergeybiryukov/) * Last activity: [12 years, 6 months ago](https://wordpress.org/support/topic/httpwordpressorgpluginsplugin-organizer-breaks-37/page/2/#post-4257711) * Status: not resolved ## Topics ### Topics with no replies ### Non-support topics ### Resolved topics ### Unresolved topics ### All topics