Changeset 25323 causes AJAX errors in WP Admin

[needle]

It seems that changeset [25323] causes "Call to undefined function wp_validate_redirect()" errors in WP Admin where AJAX is used. On my test install, widgets cannot be added, for example.

[dd32]

I'm seeing no issues with ajax requests, and adding a widget works for me under trunk.

wp_validate_redirect() is included in wp-includes/pluggable.php, and as a result, should be loaded for all requests, including admin ajax calls.

This sounds like it could be potentially plugin related (calling wp_get_referer() on inclusion for example), Can you duplicate it with a new install, or with all plugins deactivated?

[needle]

@dd32: It's frustrating because I cannot replicate this in trunk either - but I can confirm that downgrading to WP 3.6 on all sites which are affected by this removes the fatal error.

[ocean90]

Seeing multiple reports like this:

• ​http://wordpress.org/support/topic/after-361-update-cant-change-sticky-status-in-quick-edit ( Admin in English plugin?)
• ​http://support.advancedcustomfields.com/forums/topic/wp-ajax-error-with-acf-wp-3-6-1/ (Advanced Custom Fields plugin)
• ​http://wordpress.org/support/topic/woocommerce-gravity-forms-product-add-ons-creates-problem-in-wp-361 (WooCommerce - Gravity Forms Product Add-Ons plugin)
• ​http://wordpress.org/support/topic/361-update-error

[needle]

Further investigation... @dd32, you're right, the error does seem to be due to plugins that call wp_get_referer() on init. Presumably pluggable.php is not yet included when a plugin's code is first run, which would account for the difference in behaviour. Given the number of reports of this error, it would seem that some kind of defensive measures need to be taken.

[dd32]

Calling it on the init action, or even the plugins_loaded action would be fine, but calling it before then - when a plugin is included, is not.

I was able to duplicate this with both the Advanced Custom Fields AND Admin in English plugins loaded.
ACF by itself seems fine, but when Admin In English is also loaded, ACF calls get_locale() on include, which causes Admin In English to call wp_get_referer() on the locale filter before pluggable.php has been included.

Obviously this is going to affect a few other plugins though.

Why wp_validate_redirect() is in pluggable.php though is really debatable.. (but it's there, so too late to move it)

[needle]

Sorry for the confusion... that was what I meant to say - that the plugins I've identified call wp_get_referer() when they are first included, not via the callback from the init (or any other) action. Moreover, the plugins can't include the file themselves, since it is included with require() in wp_settings.php. Oh dear!

/me goes off to notify plugin authors

[nacin]

A patch for Hotfix that tries (but could fail) to define wp_validate_redirect() first.

[nacin]

A patch for core.

[nacin]

25294.diff​ is a patch for Hotfix. Unfortunately we are at the mercy of the load order here, which is alphabetical unless otherwise filtered.

25294.2.diff​ is a patch for core. I'm going to bump the branch to 3.6.2-alpha and get this in, now.

[nacin]

In 25399:

Return false from wp_get_referer() if it is called before wp_validate_redirect() is defined.

see #25294.

[nacin]

In 25400:

Return false from wp_get_original_referer() if it is called before wp_validate_redirect() is defined.

see #25294.

[nacin]

In 25401:

Return false from wp_get_referer() and wp_get_original_referer() if called before wp_validate_redirect() is defined.

Merges [25399] and [25400] to the 3.6 branch.
see #25294.

[nacin]

This build now works: ​http://wordpress.org/nightly-builds/wordpress-3.6-latest.zip.

You simply need wp-includes/functions.php out of that zip. (Also wp-includes/version.php, ideally.)

To update from the dashboard to this version, you can download the WordPress Beta Tester plugin. Then go to Tools → Beta Testing and ensure that Point release nightlies is chosen (it's the default). At that point when you "update" you will update to 3.6.2-alpha. If you then deactivate the WordPress Beta Tester plugin, you'll simply get stable releases from there on out. (As in, once 3.6.2 is out, you will be asked to update to it.)

[nacin]

*Please, please* alert plugin authors to fix their stuff. Doing *anything* before plugins_loaded or init is *bad* and *wrong*.

If you find an affected plugin, please feel free to report it here.

[Ipstenu]

Replying to nacin:

*Please, please* alert plugin authors to fix their stuff. Doing *anything* before plugins_loaded or init is *bad* and *wrong*.

Posted to make/plugins, Nacin.

​http://cl.ly/image/2z3n2J1E1L0W

[crashnet]

I nailed it. The plugin is ​http://wordpress.org/plugins/admin-in-english/

[nacin]

Replying to crashnet:

I nailed it. The plugin is ​http://wordpress.org/plugins/admin-in-english/

I've alerted the author.

[nacin]

Here's what's happening:

• Admin in English attaches a filter to the locale filter that causes a call to wp_get_referer() whenever get_locale() is called. This is perfectly reasonable and done properly (more on that in a moment). It is trying to change which locale to load, after all.

• Another plugin (well, probably many plugins) is calling get_locale() too early, probably to immediately load its textdomain. Because a plugin (in this case, Admin in English) may be filtering get_locale() to change functionality, calling this function before plugins_loaded is a bad, bad idea. If a plugin needs to load their textdomain, they should wait until *at least* plugins_loaded. Ideally, though, you should wait until after WordPress sets up its own locale (because why not?). The call to load_default_textdomain() and the initialization of $wp_locale occurs after all of this. The next hook that follows it is after_setup_theme, or you can just wait until init. (I could go for an setup_locale hook, probably.)

So, two ways to prevent this:

• The only thing a plugin should be doing on inclusion is add_action() and add_filter(). Admin in English is doing this. This would have prevented other plugins from causing problems.

• Even better, the only thing a plugin should be doing on inclusion is one add_action(), to plugins_loaded (or, if they can get away with it, init), and then attach all other hooks then. If Admin in English were doing this, this also would have been avoided.

[nacin]

This issue doesn't require two plugins, it should be noted.

No reports of this yet, but a single plugin calling wp_get_referer() before plugins_loaded would trigger a fatal error here. Or calling a function that calls wp_get_referer(), which isauth_redirect(), check_admin_referer(), wp_referer_field(), wp_original_referer_field(), and wp_nonce_ays(). (And, one of those functions can be called by wp_nonce_field().)

[crashnet]

I was able to stop the problem after disabling admin in english, but FYI I also have WPML active (which makes "admin in english" redundant - i only forgot to delete it).

thanks @nacin

[needle]

I've also alerted the plugin authors of the plugin I am using, which uses wp_get_referer() when included to test whether AJAX calls to wp-admin/admin-ajax.php are actually called from the admin screens or from the front-end. It should be simple enough to delay this until plugins_loaded. Thanks for the hotfix, @nacin

[nbachiyski]

I moved adding the filter to plugins_loaded and this fixed it for me.

The update is in the new Admin in English version 1.2.1. Could you, guys, please test to confirm it works?

[DrewAPicture]

Maybe related: #25296

[crashnet]

I can confirm this solved the issue, at least in my situation. Thanks.