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

[erich_k4wp]

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

[Clorith]

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.

[Presskopp]

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

[swissspidy]

#42577 was marked as a duplicate.

[afercia]

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

[ChantalC]

#42582 was marked as a duplicate.

[SergeyBiryukov]

#42582 was marked as a duplicate.

[kirasong]

cc: @rafa8626 @joemcgill

[kirasong]

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.

[Presskopp]

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/

[blobfolio]

Improve locale-handling

[blobfolio]

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

[Clorith]

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.

[flixos90]

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.

[Clorith]

#42625 was marked as a duplicate.

[shreyaskhatri]

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?

[Matthias Reuter]

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.

[westonruter]

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

[westonruter]

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

[presswizards]

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.

[kreativhuhn]

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.

[orlandooo]

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.

[webdados]

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

[joemcgill]

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.

[webdados]

@joemcgill I like that solution :-)

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

[ocean90]

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.

[flixos90]

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

[johnbillion]

#42689 was marked as a duplicate.

[cuba84]

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

[pursch]

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]

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.

[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/

[joemcgill]

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.

[SergeyBiryukov]

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.

[joemcgill]

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

[ocean90]

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.

[johnbillion]

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'

[johnbillion]

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

[johnbillion]

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

[johnbillion]

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.

[bluesaphyer]

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?

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

[viajarapie]

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?

[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!

[viajarapie]

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!

[Doobeedoo]

Hi,

Same error here : ​http://bit.ly/2DL0ua9

[vyskoczilova]

Same error reported here: ​https://wordpress.org/support/topic/good-plugin-but-conflict-with-other-plugin/ with [SO Widgets Bundle](​https://cs.wordpress.org/plugins/so-widgets-bundle/) plugin and mine [Simple Admin Language Change](​https://cs.wordpress.org/plugins/simple-admin-language-change/), if I can help, let me know.

[Drumsk8]

Hello I recently just had this exact issue and it was driving me crazy I couldn't find a solution, however, I've found one.

It was being caused by my user account not having a language set, it was supposed to be using the default site language(English US) but wasn't actually defined.

Having now defined the langauge as English US, it's now working for me.

This was affecting both version 4.9.7 & updated to 4.9.8.

Just sharing this experiance as it may save someone else a ton of time and bother.