#25294 closed defect (bug) (fixed)
Changeset 25323 causes AJAX errors in WP Admin
Reported by: | needle | Owned by: | |
---|---|---|---|
Milestone: | 3.7 | Priority: | normal |
Severity: | major | Version: | 3.6.1 |
Component: | General | Keywords: | reporter-feedback |
Focuses: | Cc: |
Description
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.
Attachments (2)
Change History (27)
#2
@
11 years ago
@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.
#3
@
11 years ago
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
#4
@
11 years ago
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.
#5
@
11 years ago
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)
#6
@
11 years ago
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
@
11 years ago
A patch for Hotfix that tries (but could fail) to define wp_validate_redirect() first.
#8
@
11 years ago
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.
#12
@
11 years ago
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.)
#13
follow-up:
↓ 14
@
11 years ago
*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.
#14
in reply to:
↑ 13
@
11 years ago
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.
#15
follow-up:
↓ 16
@
11 years ago
I nailed it. The plugin is http://wordpress.org/plugins/admin-in-english/.
#16
in reply to:
↑ 15
@
11 years ago
Replying to crashnet:
I nailed it. The plugin is http://wordpress.org/plugins/admin-in-english/
I've alerted the author.
#17
@
11 years ago
Here's what's happening:
- Admin in English attaches a filter to the
locale
filter that causes a call towp_get_referer()
wheneverget_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 filteringget_locale()
to change functionality, calling this function beforeplugins_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 toload_default_textdomain()
and the initialization of$wp_locale
occurs after all of this. The next hook that follows it isafter_setup_theme
, or you can just wait untilinit
. (I could go for ansetup_locale
hook, probably.)
So, two ways to prevent this:
- The only thing a plugin should be doing on inclusion is
add_action()
andadd_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()
, toplugins_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.
#18
@
11 years ago
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()
.)
#19
@
11 years ago
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).
#20
@
11 years ago
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
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?