JavaScript l10n inconsistency

[SergeyBiryukov]

After activating some plugins the standard messages displayed in the admin area using JavaScript (for example, the confirmation message when deleting categories or tags) become not localized.

Among these plugins are the latest versions of Popularity Contest and Cimy User Extra Fields. It turns out they use wp_enqueue_script() and wp_register_script() functions not hooked to init action as ​recommended by Codex, but instead right in the plugin body.

The following code is currently used in Russian version to restore localization in this case:

function restore_scripts_l10n() {
	global $wp_scripts;

	if ( is_a($wp_scripts, 'WP_Scripts') ) {
		wp_default_scripts($wp_scripts);
	}
}
add_action('init', 'restore_scripts_l10n');

However I think a more centralized solution is needed.

[nacin]

Sounds like this might be related to #9370. In that ticket, it seemed like wp_enqueue_script() outside of an action just fubar'd the plugin. But if it also affects localization, then perhaps it is important to have wp_enqueue_script to not enqueue the script or mess with the global $wp_scripts variable return false when called incorrectly (suggested by dd32 in #9370).

[hakre]

Sounds like this is a bug in the plugins. Has that reported to the plugin authors?

[hakre]

It would be nice to know which plugin actually breaks the behaviour so it can be further analyzed what the root cause of the problem is. From what I read so far it can be something like a documentation problem in trac, a misconception in the API or a misuse in some plugin. Would be good to have something to look further.

[nbachiyski]

We should make plugin developers properly use the enqueue functions. I am sure we can think of a workaround, but calling these before init can lead to other troubles, too.

[SergeyBiryukov]

The plugins I've encountered this problem with are listed in the original report. I haven't got in touch with their authors yet, but it looks like Popularity Contest hasn't been updated for a long time.

Some users still complain that the confirmation message when deleting a tag is displayed in English, supposing the localization is incomplete, which is not the case. It's not always easy to determine which plugin breaks JavaScript l10n. I guess the workaround is still needed. Also it should be stated directly in Codex that using wp_enqueue_script() or wp_register_script() before init is wrong.

[scribu]

Also it should be stated directly in Codex that using wp_enqueue_script() or wp_register_script() before init is wrong.

Feel free to make that modification to the Codex.

[SergeyBiryukov]

Feel free to make that modification to the Codex.

Done.

perhaps it is important to have wp_enqueue_script to not enqueue the script or mess with the global $wp_scripts variable return false when called incorrectly (suggested by dd32 in #9370)

Should I create a patch for this?

[scribu]

Similar: #14729

[nbachiyski]

I prefer leaving it at the current state.

If wp_enqueue_script() doesn't enqueue before init it may cause the plugin to be unusable. But a missing translation is just annoying.

I suggest that we issue a warning (like the deprecated ones) that tells developers they shouldn't do that.

[nacin]

Agreed. Let's do a _deprecated_message() in a future release, and recommend tying wp_enqueue_script() to an action.

Specifically, the actions wp_enqueue_scripts and admin_enqueue_scripts.

[jczorkmid]

+1 to having some sort of message logged when these functions are mis-used.

I've encountered a numerous issues related to use of wp_*_script functions being called before init. This includes wp_dequeue_script and wp_deregister_script (basically anything that causes $wp_scripts to initialize early).

Should the same apply to the wp_*_style functions as well?

[nacin]

We can do _doing_it_wrong() now.

[jczorkmid]

Here's an attempt at a patch for the script related functions. I tested it with a default install, and with "bad" plugin and a "bad" theme (both of which triggered the message).

[SergeyBiryukov]

#17916 indicates the similar issue with wp_register_style().

In 11526.2.patch​ I've added _doing_it_wrong() for $wp_styles as well.

[azaozz]

In [18556]:

Add _doing_it_wrong() when a plugin or theme accesses $wp_scripts or $wp_styles too early (also fixes localization), props SergeyBiryukov, fixes #11526

[dd32]

Do we really want to potentially call debug_backtrace() on every pageload for users of a theme/plugin which is doing it wrong?

[azaozz]

There was a discussion of whether we should disallow instantiation of WP_Scripts and WP_Styles before 'init' (return false?), can add this if needed.

[azaozz]

In [18557]:

Don't call debug_backtrace() in wp_scripts_init() and wp_styles_init(), props dd32, see #11526

[nacin]

In [18561]:

Call _doing_it_wrong() individually in wp_scripts and wp_styles functions. Partially reverts [18556], [18557], removes wp_styles_init(), wp_scripts_init(). fixes #11526.

[SergeyBiryukov]

Follow-up: #19959

[GaryJ]

Follow-up: #20513