WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 6 years ago

Last modified 5 years ago

#11526 closed defect (bug) (fixed)

JavaScript l10n inconsistency

Reported by: SergeyBiryukov Owned by: nacin
Milestone: 3.3 Priority: normal
Severity: normal Version: 2.9
Component: I18N Keywords: has-patch
Focuses: Cc:

Description

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 the more centralized solution is needed.

Attachments (3)

11526.doing_it_wrong.patch (3.3 KB) - added by jczorkmid 6 years ago.
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).
11526.2.patch (5.8 KB) - added by SergeyBiryukov 6 years ago.
11526.diff (9.3 KB) - added by nacin 6 years ago.

Download all attachments as: .zip

Change History (30)

#1 @nacin
7 years ago

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).

#2 @hakre
7 years ago

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

#3 @hakre
7 years ago

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.

#4 @nbachiyski
7 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

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.

#5 @nacin
7 years ago

  • Milestone Unassigned deleted

#6 @SergeyBiryukov
6 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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.

#7 @scribu
6 years ago

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.

#8 @scribu
6 years ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

#9 @SergeyBiryukov
6 years ago

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?

#10 @scribu
6 years ago

  • Keywords dev-feedback added
  • Milestone set to 3.1
  • Resolution wontfix deleted
  • Status changed from closed to reopened

#11 @scribu
6 years ago

Similar: #14729

#12 @nbachiyski
6 years ago

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.

#13 @nacin
6 years ago

  • Keywords needs-patch added; dev-feedback removed
  • Milestone changed from 3.1 to Future Release

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.

#14 @jczorkmid
6 years ago

  • Cc jpenney@… added

+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?

#15 @nacin
6 years ago

We can do _doing_it_wrong() now.

#16 @nacin
6 years ago

  • Milestone changed from Future Release to 3.3

@jczorkmid
6 years ago

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).

#17 @SergeyBiryukov
6 years ago

  • Keywords has-patch added; needs-patch removed

#18 @SergeyBiryukov
6 years ago

#17916 indicates the similar issue with wp_register_style().

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

#19 @azaozz
6 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

#20 @dd32
6 years ago

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

#21 @azaozz
6 years ago

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.

#22 @nacin
6 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#23 @nacin
6 years ago

  • Owner changed from nbachiyski to nacin
  • Status changed from reopened to assigned

#24 @azaozz
6 years ago

In [18557]:

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

@nacin
6 years ago

#25 @nacin
6 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

#27 @GaryJ
5 years ago

Follow-up: #20513

Note: See TracTickets for help on using tickets.