WordPress.org

Make WordPress Core

Opened 4 weeks ago

Closed 2 weeks ago

Last modified 13 days ago

#42574 closed defect (bug) (fixed)

MediaElement upgrade causing JS errors when certain languages are in use e.g de_DE-formal

Reported by: erich_k4wp Owned by: johnbillion
Milestone: 4.9.1 Priority: high
Severity: normal Version: 4.9
Component: Media Keywords:
Focuses: javascript, administration Cc:

Description

Also JavaScript errors in a language with a locale code such as de_DE-formal:

mediaelement-and-player.js lineno. 318

if (!/^[a-z]{2,3}((\-|_)[a-z]{2})?$/i.test(args[0])) {
  throw new TypeError('Language code must have format 2-3 letters and. optionally, hyphen, underscore followed by 2 more letters');
}

reference #42071

Attachments (5)

42574.diff (2.5 KB) - added by blobfolio 4 weeks ago.
Improve locale-handling
42574.2.diff (1.9 KB) - added by flixos90 4 weeks ago.
42574.3.diff (1.5 KB) - added by ocean90 3 weeks ago.
42574.4.diff (3.0 KB) - added by joemcgill 2 weeks ago.
42574.5.diff (1014 bytes) - added by SergeyBiryukov 2 weeks ago.

Download all attachments as: .zip

Change History (63)

#1 @Clorith
4 weeks ago

  • Milestone changed from Awaiting Review to 4.9.1

This affects JavaScript heavy sites such as the widget screen and customizer, as the fatal error prevents further code execution.

A temporary workaround while we look into this is to change your own users language in the back-end (if you don't wish to change the language used for your site in general), this can be done from your profile page.

#2 @Presskopp
4 weeks ago

I think this would be (more) correct:

Language code must have format 2-3 letters, optionally followed by underscore followed by 2 or more letters

something like:

^[a-z]{2,3}((_?)[a-z]*)?$

EDIT: Turns out it's a bit more complicated, disregard please

Last edited 4 weeks ago by Presskopp (previous) (diff)

#3 @swissspidy
4 weeks ago

#42577 was marked as a duplicate.

#4 @afercia
4 weeks ago

Of course this happens also with other languages, e.g. formal Dutch nl_NL_formal, one of the consequences is the inability to add Media in the editor (Add Media button does nothing).

#5 @ChantalC
4 weeks ago

#42582 was marked as a duplicate.

#6 @SergeyBiryukov
4 weeks ago

#42582 was marked as a duplicate.

This ticket was mentioned in Slack in #forums by jcastaneda. View the logs.


4 weeks ago

This ticket was mentioned in Slack in #core-media by mike. View the logs.


4 weeks ago

#9 @mikeschroder
4 weeks ago

cc: @rafa8626 @joemcgill

#10 @mikeschroder
4 weeks ago

  • Component changed from External Libraries to Media
  • Priority changed from normal to high

Moving this to Media for visibility.

It looks like for the languages this affects, the media grid isn't visible in the Media section of the panel at all.

#11 @Presskopp
4 weeks ago

  • Component changed from Media to External Libraries

After talking to @desrosj, who is working on the patch, I share a new regex. I copied all the codes which are in the optgroup and they all get catched, I just wonder about the correct syntax

^[a-z]{2,3}((\-|_)?[a-z]*(\-|_)?)[a-z0-9]*

https://imgur.com/a/RPfCP

FYI: You can test live on https://regex101.com/

Last edited 4 weeks ago by Presskopp (previous) (diff)

#12 @Presskopp
4 weeks ago

  • Component changed from External Libraries to Media

@blobfolio
4 weeks ago

Improve locale-handling

#13 @blobfolio
4 weeks ago

  • Keywords has-patch 2nd-opinion needs-testing added

The attached patch should do the trick. :)

There are two changes:

  • The $ has been removed from the problematic regexp mentioned in the OP. This allows locales with non-conforming end pieces like "-formal" to survive.
  • An extra condition is inserted to truncate such locales if ME.js doesn't have a translation. For example, de-DE-formal becomes de-DE.

All remaining locale-handling logic continues as usual after that.

(Quick note: the patch only includes changes for the unminified Javascript. To test, be sure to regenerate the minified copy or just replace it with the full version.)

Last edited 4 weeks ago by blobfolio (previous) (diff)

#14 @Clorith
4 weeks ago

This either needs to be reported upstream, so that ME.js can support our non-ISO language strings, or we need to change it in the script loader and handle it properly on our end to use a string compatible with ME.js

https://github.com/WordPress/WordPress/blob/4.9-branch/wp-includes/script-loader.php#L360 is the offending line if we want to handle it our selves, and I think this is where we should be focusing the fix.

This ticket was mentioned in Slack in #meta-wordcamp by iandunn. View the logs.


4 weeks ago

@flixos90
4 weeks ago

#16 @flixos90
4 weeks ago

I prefer to go with @Clorith's second suggestion as that makes us independent of MediaElement.js, and given our formats for those more specific language variants are not really any standard (at least to my knowledge), we should ensure what we pass to the script is valid.

I uploaded 42574.2.diff as a possible implementation with a new function to accomplish this, as the logic is a little more than a one-liner. This furthermore makes it reusable, as plugins might enqueue other JS dependencies that don't handle those variants, and they could then use that function.

#17 @Clorith
3 weeks ago

#42625 was marked as a duplicate.

#18 @shreyaskhatri
3 weeks ago

Hi,

New over here. I'm getting the following error after upgrading to 4.9.

wp-mediaelement.min.js?ver=4.9:1 Uncaught TypeError: b(...).not(...).filter(...).mediaelementplayer is not a function
    at HTMLDocument.a (wp-mediaelement.min.js?ver=4.9:1)
    at fire (jquery-1.10.2.js:3048)
    at Object.fireWith [as resolveWith] (jquery-1.10.2.js:3160)
    at Function.ready (jquery-1.10.2.js:433)
    at HTMLDocument.completed (jquery-1.10.2.js:104)
a	@	wp-mediaelement.min.js?ver=4.9:1
fire	@	jquery-1.10.2.js:3048
fireWith	@	jquery-1.10.2.js:3160
ready	@	jquery-1.10.2.js:433
completed	@	jquery-1.10.2.js:104

on this site: http://www.packnfly.in/ on Chrome/Safari.

Default language: English (UK). Tried English (US)/ English (Australia), but issue persists. Any ideas if the issue related to this thread?

Last edited 3 weeks ago by shreyaskhatri (previous) (diff)

#19 @Matthias Reuter
3 weeks ago

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

I've got the same issue when adding mediauploader to frontend theme by loading it via wp_enqueue_media(); - Patch 42574.2.diff has fixed all the javascript errors, so I confirm that this patch works on frontend usage of wp_enqueue_media, too.

#20 @Matthias Reuter
3 weeks ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

This ticket was mentioned in Slack in #core-customize by melchoyce. View the logs.


3 weeks ago

#22 @westonruter
3 weeks ago

Here's a workaround plugin you can install which will allow the formal locale to remain active:

<?php
add_action( 'wp_default_scripts', function( \WP_Scripts $scripts ) {
        $scripts->add_inline_script(
                'mediaelement-core',
                'mejsL10n.language = mejsL10n.language.replace( /^(\w\w+[-_]\w\w).+/, "$1" );',
                'before'
        );
}, 11 );

#23 @westonruter
3 weeks ago

Here's the plugin code in a Gist for easier installation: https://gist.github.com/westonruter/2ed5d98957c5a6e94c580c47abbb476a

#24 @presswizards
3 weeks ago

Sorry, I’m using “en” (English – United States) and I’m still seeing the same error:

Uncaught TypeError: b(...).not(...).filter(...).mediaelementplayer is not a function

so I don’t think it’s the same language setting issue, and it breaks all remaining JS on the page.

Ah I found my issue… it turned out jquery was being loaded twice, once by WP 4.9 and again by another code block on the page, and once I removed the code block jquery load, it stopped throwing that error.

WP 4.8.3 did not have this issue, so now sites that were double-loading jquery without fatal issues will have fatal JS issues in WP 4.9.

#25 @kreativhuhn
3 weeks ago

I can confirm the problem:
No troubles up to 4.8.x with de_DE-formal.
Since upgrading to 4.9/4.9.1 I get this error, that is gone if I switch my user settings to en. But that's no acceptable workaround for the clients of my agency that are used to the German interface.

This ticket was mentioned in Slack in #forums by clorith. View the logs.


3 weeks ago

#27 @orlandooo
3 weeks ago

kreativhuhn - Setting backend language to "Deutsch" (de_DE) instead of "Deutsch (Sie)" (de_DE_formal) will fix it. This way you can keep german language for your staff.

-> If you see only ""Deutsch (Sie)" in the backend language-dropdown first install "Deutsch" (without "(Sie)") in Settings > Site Language and then select "Deutsch" as your backend language.

Should work for all languages that have a formal version, like german.

#28 @webdados
3 weeks ago

I can confirm this problem with the newly created "pt_PT_ao90" variant

This ticket was mentioned in Slack in #core-committers by johnbillion. View the logs.


3 weeks ago

This ticket was mentioned in Slack in #core by johnbillion. View the logs.


3 weeks ago

This ticket was mentioned in Slack in #core-media by joemcgill. View the logs.


3 weeks ago

#32 @joemcgill
3 weeks ago

So it seems we have a few things to consider here:

  1. MEJS added validation here that won't load translation files that don't conform to the expected format.
  2. Our formal language files don't conform to the standard, or as @ocean90 put it, "There's a reason why it's called 'WordPress locale'", which means we can either parse WP locales into ISO locales, as @flixos90 suggests in 42574.2.diff or we need to work around the validation as @blobfolio suggests in 42574.diff and @westonruter suggests in his plugin comment above.

If we're going to parse WP locales, we need to be careful about not flattening formal languages into the default languages. If we're going to work around the validation, we should do so using an external shim, like @westonruter proposed so we're not maintaining a fork of MEJS.

In the mean time, I'd be happy to ship 42574.2.diff for 4.9.1 if there's a +1 from someone on the Polyglots team.

#33 @webdados
3 weeks ago

@joemcgill I like that solution :-)

I've tested with the "pt_PT_ao90" variant and it works just fine.

@ocean90
3 weeks ago

#34 @ocean90
3 weeks ago

42574.3.diff is an alternative and follows r36802. Note that we also have a locale named art_xemoji. With 42574.3.diff a translator can adjust that to make it compatible with MEJS.

This ticket was mentioned in Slack in #forums by pmfonseca. View the logs.


3 weeks ago

This ticket was mentioned in Slack in #core-media by mike. View the logs.


3 weeks ago

#37 @flixos90
3 weeks ago

@ocean90 On the one hand I like the flexible approach you're suggesting, on the other hand I'm wary about confronting translators with such a technical detail. I'd like for us to explore a viable solution without doing that first.

#38 @johnbillion
3 weeks ago

#42689 was marked as a duplicate.

#39 @cuba84
2 weeks ago

Some comment from my side: I cannot customize the theme dazzly

#40 @pursch
2 weeks ago

I can confirm this issue, it breaks for example the Yoast SEO plugin if locale de_DE_formal is used. Switching back to de_DE solves the issues with Yoast.

@joemcgill
2 weeks ago

#41 @joemcgill
2 weeks ago

42574.4.diff is a different approach that adds a modified version of mejs.i18n.language() (without the validation) to the mediaelement-migrate script so our language strings will get loaded during the migration step, rather than when MEJS is first loaded on the page.

This keeps TypeErrors from being thrown when we try to load a locale with a name that doesn't conform to the expected format and avoids forking MEJS itself in order to remove the validation.

However, after working on this, I'm not convinced we need to go to these lengths to maintain a similar locale name to what we're using in WP, since I believe the locale name is simply being used as an identifier in MEJS, and we are passing a single set of translated strings. In other words, something like 42574.2.diff may in fact be all we need here.

@flixos90 and/or @ocean90 – I'd appreciate your feedback since you're more familiar with the particularities of this particular translation issue.

This ticket was mentioned in Slack in #core-media by joemcgill. View the logs.


2 weeks ago

#43 follow-up: @akshatjiwan
2 weeks ago

I created a topic in the forums. Could it be related to this issue?

https://wordpress.org/support/topic/cant-see-my-images-in-the-media-library/

#44 in reply to: ↑ 43 @joemcgill
2 weeks ago

Replying to akshatjiwan:

I created a topic in the forums. Could it be related to this issue?

https://wordpress.org/support/topic/cant-see-my-images-in-the-media-library/

Hi @akshatjiwan,

I responded to your support ticket, but if you're not seeing the error in your JS console described above, then I don't think it's the same issue. But let's keep the conversation going in support.

#45 follow-up: @SergeyBiryukov
2 weeks ago

As noted in comment:41, the language is simply used as an ID, and we're only passing a single set of strings, so no need to complicate things :)

42574.5.diff is my take based on the approach in 42574.2.diff. A new function should not be necessary, reducing the language tag to the first subtag with strtok() should be enough for our purposes here.

42574.4.diff would also work, but seems like an overkill.

42574.3.diff seems a bit too technical for translators. Without looking deep into MediaElement.js code, how are they supposed to know which language tags are supported and which are not? Unlike in [36802], there's no documentation link here.

#46 @joemcgill
2 weeks ago

Thanks for the feedback and patch, @SergeyBiryukov. To be clear, the approach suggested in 42574.5.diff would register a locale name like de_DE-formal in MEJS as de and art_xemoji as art. If the locale name is only an identifier, and there is no additional concerns with truncating the locale name in this way, I support this simplified approach, which avoids adding additional helper functions.

Update: I was able to confirm that 42574.5.diff works and fixes the issue when the site language is set to "Deutsch (Sie)" (de_DE_formal).

Last edited 2 weeks ago by joemcgill (previous) (diff)

This ticket was mentioned in Slack in #core-media by joemcgill. View the logs.


2 weeks ago

#48 in reply to: ↑ 45 @ocean90
2 weeks ago

Replying to SergeyBiryukov:

42574.3.diff seems a bit too technical for translators. Without looking deep into MediaElement.js code, how are they supposed to know which language tags are supported and which are not? Unlike in [36802], there's no documentation link here.

By writing our own documentation or submitting a PR which adds the missing documentation.

42574.5.diff is basically using the fallback from 42574.3.diff so that should be fine too. We could also drop the strtolower() call since the first part is always lowercased.

#49 @johnbillion
2 weeks ago

Test results for the transformation that is made by 42574.5.diff:

'af'             => 'af'
'ar'             => 'ar'
'ary'            => 'ary'
'as'             => 'as'
'az'             => 'az'
'azb'            => 'azb'
'bel'            => 'bel'
'bg_BG'          => 'bg'
'bn_BD'          => 'bn'
'bo'             => 'bo'
'bs_BA'          => 'bs'
'ca'             => 'ca'
'ceb'            => 'ceb'
'ckb'            => 'ckb'
'cs_CZ'          => 'cs'
'cy'             => 'cy'
'da_DK'          => 'da'
'de_CH'          => 'de'
'de_CH_informal' => 'de'
'de_DE'          => 'de'
'de_DE_formal'   => 'de'
'dzo'            => 'dzo'
'el'             => 'el'
'en_AU'          => 'en'
'en_CA'          => 'en'
'en_GB'          => 'en'
'en_NZ'          => 'en'
'en_US'          => 'en'
'en_ZA'          => 'en'
'eo'             => 'eo'
'es_AR'          => 'es'
'es_CL'          => 'es'
'es_CO'          => 'es'
'es_CR'          => 'es'
'es_ES'          => 'es'
'es_GT'          => 'es'
'es_MX'          => 'es'
'es_PE'          => 'es'
'es_VE'          => 'es'
'et'             => 'et'
'eu'             => 'eu'
'fa_IR'          => 'fa'
'fi'             => 'fi'
'fr_BE'          => 'fr'
'fr_CA'          => 'fr'
'fr_FR'          => 'fr'
'gd'             => 'gd'
'gl_ES'          => 'gl'
'gu'             => 'gu'
'haz'            => 'haz'
'he_IL'          => 'he'
'hi_IN'          => 'hi'
'hr'             => 'hr'
'hu_HU'          => 'hu'
'hy'             => 'hy'
'id_ID'          => 'id'
'is_IS'          => 'is'
'it_IT'          => 'it'
'ja'             => 'ja'
'jv_ID'          => 'jv'
'kab'            => 'kab'
'ka_GE'          => 'ka'
'km'             => 'km'
'ko_KR'          => 'ko'
'lo'             => 'lo'
'lt_LT'          => 'lt'
'lv'             => 'lv'
'mk_MK'          => 'mk'
'ml_IN'          => 'ml'
'mn'             => 'mn'
'mr'             => 'mr'
'ms_MY'          => 'ms'
'my_MM'          => 'my'
'nb_NO'          => 'nb'
'ne_NP'          => 'ne'
'nl_BE'          => 'nl'
'nl_NL'          => 'nl'
'nl_NL_formal'   => 'nl'
'nn_NO'          => 'nn'
'oci'            => 'oci'
'pa_IN'          => 'pa'
'pl_PL'          => 'pl'
'ps'             => 'ps'
'pt_BR'          => 'pt'
'pt_PT'          => 'pt'
'pt_PT_ao90'     => 'pt'
'rhg'            => 'rhg'
'ro_RO'          => 'ro'
'ru_RU'          => 'ru'
'sah'            => 'sah'
'si_LK'          => 'si'
'sk_SK'          => 'sk'
'sl_SI'          => 'sl'
'sq'             => 'sq'
'sr_RS'          => 'sr'
'sv_SE'          => 'sv'
'szl'            => 'szl'
'tah'            => 'tah'
'ta_IN'          => 'ta'
'te'             => 'te'
'th'             => 'th'
'tl'             => 'tl'
'tr_TR'          => 'tr'
'tt_RU'          => 'tt'
'ug_CN'          => 'ug'
'uk'             => 'uk'
'ur'             => 'ur'
'uz_UZ'          => 'uz'
'vi'             => 'vi'
'zh_CN'          => 'zh'
'zh_HK'          => 'zh'
'zh_TW'          => 'zh'

#50 @johnbillion
2 weeks ago

  • Keywords commit added; 2nd-opinion needs-testing removed
  • Owner set to johnbillion
  • Status changed from reopened to reviewing

I've been trying to break this and haven't been able to. I think this is ready to go in.

#51 @johnbillion
2 weeks ago

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

In 42251:

Media: Further improvements to the handling of language codes that get passed to MediaElement.

This change means that only the leading portion of a locale code gets passed to MediaElement, removing problems that arise from locales such as de_DE_formal and pt_PT_ao90.

Props erich_k4wp, blobfolio, flixos90, ocean90, joemcgill, SergeyBiryukov.

Fixes #42574

#52 @johnbillion
2 weeks ago

  • Keywords fixed-major added; has-patch commit removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

#53 @johnbillion
2 weeks ago

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

In 42252:

Media: Further improvements to the handling of language codes that get passed to MediaElement.

This change means that only the leading portion of a locale code gets passed to MediaElement, removing problems that arise from locales such as de_DE_formal and pt_PT_ao90.

Props erich_k4wp, blobfolio, flixos90, ocean90, joemcgill, SergeyBiryukov.

Fixes #42574

Merges [42251] to the 4.9 branch.

#54 @bluesaphyer
13 days ago

Hi, I am getting these media element errors on the Add New Post page and am unable to use the visual editor. I have tried adding the patch but it does not seem to make a difference. The language is set to English (United States). Is my problem related to this or being caused by something else? How do I go about finding out what the problem is?

#55 follow-up: @johnbillion
13 days ago

@bluesaphyer Can you try clearing your browser cache? The updated JS file might be cached in your browser. Failing that, can you try the 4.9.1 beta?

#56 in reply to: ↑ 55 @viajarapie
13 days ago

Hi, the patch didn't work for me either. I cleared the browser cache too. I think there's another problem beyond the language codes. In fact, I'm only using es_ES and en_GB. The key might be in what @presswizards describes in entry #24 above. I checked the source for my problem pages (Post Editor for example) and I verified jquery is being loaded twice. I checked some other pages and I get malfunction every time jquery is loaded twice. The backend pages that work well show only one jquery load.

I don't know javascript but there seems to be an obvious correlation here.

Hope you all can help.

Replying to johnbillion:

@bluesaphyer Can you try clearing your browser cache? The updated JS file might be cached in your browser. Failing that, can you try the 4.9.1 beta?

#57 follow-up: @johnbillion
13 days ago

  • Keywords fixed-major removed

@viajarapie This sounds like it might be an issue unrelated to the language code, in which case would you mind opening a new ticket please with as much detail as you can? Thanks!

#58 in reply to: ↑ 57 @viajarapie
13 days ago

I will right away, thank you

Replying to johnbillion:

@viajarapie This sounds like it might be an issue unrelated to the language code, in which case would you mind opening a new ticket please with as much detail as you can? Thanks!

Note: See TracTickets for help on using tickets.