Make WordPress Core

Opened 15 years ago

Closed 13 years ago

Last modified 3 years ago

#11526 closed defect (bug) (fixed)

JavaScript l10n inconsistency

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

Description (last modified by 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.

Attachments (3)

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

Download all attachments as: .zip

Change History (31)

#1 @nacin
15 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
15 years ago

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

#3 @hakre
15 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
15 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
15 years ago

  • Milestone Unassigned deleted

#6 @SergeyBiryukov
14 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
14 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
14 years ago

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

#9 @SergeyBiryukov
14 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
14 years ago

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

#11 @scribu
14 years ago

Similar: #14729

#12 @nbachiyski
14 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
14 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
13 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
13 years ago

We can do _doing_it_wrong() now.

#16 @nacin
13 years ago

  • Milestone changed from Future Release to 3.3

@jczorkmid
13 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
13 years ago

  • Keywords has-patch added; needs-patch removed

#18 @SergeyBiryukov
13 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
13 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
13 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
13 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
13 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#23 @nacin
13 years ago

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

#24 @azaozz
13 years ago

In [18557]:

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

@nacin
13 years ago

#25 @nacin
13 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
13 years ago

Follow-up: #20513

#28 @SergeyBiryukov
3 years ago

  • Description modified (diff)
Note: See TracTickets for help on using tickets.