WordPress.org

Ready to get started?Download WordPress

Forums

[resolved] Tinymce Error - Missing JS files, breaks on every upgrade. (19 posts)

  1. Andrew Martin
    Member
    Posted 2 years ago #

    For some reason, I am STILL getting this stupid tiny mce editor on all sites when I upgrade WordPress. My workaround is to simply copy and paste wp-langs-en.js to 'en.js' in the missing directories and it works fine...but what's causing this? Can we please, please get a solution? It's breaking multiple sites consistently when I upgrade WordPress, and has been occuring since the early 3.0 releases of ACF.

    Here's the source of the missing scripts:

    GET https://SITEURL.COM/wp-includes/js/tinymce/langs/en.js?ver=345-20111127 404 (Not Found)
    wp-tinymce.php:2Failed to load: https://SITEURL.COM/wp-includes/js/tinymce/langs/en.js

    I read several threads, including:
    http://wordpress.org/support/topic/visual-editor-not-working-mimicing-html-editor-blanking-out-no-tool-bar?replies=4
    http://wordpress.org/support/topic/upgraded-to-32-visual-editor-buttons-missing/page/2?replies=62

    But neither offer a solid solution aside from simply copying those files. I really hate having to do that every single time I upgrade the site.

    is there any way we can see a fix in the next version?

    [ Please don't bump, that's not permitted here. ]

  2. Andrew Martin
    Member
    Posted 2 years ago #

  3. vtxyzzy
    Member
    Posted 2 years ago #

    It might work to reinstall WP by going to Dashboard->Updates and clicking 'Reinstall Now'.

  4. miniwod
    Member
    Posted 1 year ago #

    I have been struggling with this for 2 days now.
    Have tried everything I can find.
    Disabling all plugins.
    Renaming plugins folder to plugins-old to refresh them.
    Switching to Twenty-Ten theme.
    Making new users of different levels.
    Renaming the language file to en.js and copying it to both locations
    Downloading WP Super Edit
    Hardcoding the paths inside wp-tinymce.php
    Unzipping the gzip version of wp-tinymce.js.gz and putting the.js version in the folder.
    Reinstalling WordPress.

    In FireFox when I open a Page to edit, these errors always pop:
    [20:23:07.256] SyntaxError: missing ; before statement @ http://minimalwod.com/wp-includes/js/tinymce/wp-tinymce.php?c=1&ver=349-21274:2
    [20:23:07.594] ReferenceError: tinyMCE is not defined @ http://minimalwod.com/wp-includes/js/tinymce/langs/wp-langs-en.js?ver=349-21274:1

    This is CRAZY that no consensus exists on the nets on how to resolve this. Please, for god's sake, if you have the answer, please post it.

    I think the only thing I *didn't* try was a post about messing with the Unix permissions of the files because that seemed like it would do more harm than good (like the post where someone suggest just commenting out the admin-footer line in the wordpress code--which i tried anyway).

    Thanks

  5. hbchai
    Member
    Posted 1 year ago #

    This is This is a very annoying issue; I've been struggling with it with a friend's WordPress 3.5 install. It really doesn't help that the minified TinyMCE code is so opaque, making debugging basically impossible. Observations:

    - The issue appears to be browser-specific. The visual editor fails to load in Firefox and Chrome, but works in IE9.

    - Copying wp-langs-en.js to en.js does indeed resolve the problem. However:

    - My personal WP installation does not have an en.js file, and yet works flawlessly in all browsers.

    - I noticed when performing some file diffs that the files on my friend's install had DOS newlines, while my own have Unix newlines. Red herring or clue? Not terribly motivated to spend more time figuring it out, but worth a mention.

  6. tgrux
    Member
    Posted 1 year ago #

    I was having this same issue and found that our Git version control system was ignoring the file "wp-includes/js/tinymce/wp-tinymce.js.gz". Once I uploaded this file everything started working.

    So the issue could be your server can't work with a .gz compression or the file needs to be uploaded.

  7. Andrew Martin
    Member
    Posted 1 year ago #

    @timg19 wow. Thank you.

    Snippet from my gitignore:

    # Packages #
    ############
    # it's better to unpack these files and commit the raw source
    # git has its own built in compression methods
    *.7z
    *.dmg
    *.gz

    It looks like, in fact, that file was getting ignored. WOW. Feels good to finally get at the root of this issue!

  8. tgrux
    Member
    Posted 1 year ago #

    Glad I could help!

  9. ronnieg
    Member
    Posted 1 year ago #

    Yes, this is still happening, up to and including 3.5.1, on two of my sites hosted with different hosting services. And yes, I saw the Trac post on this subject where WP changed how it handles language translation since 2.5, supposedly with a WP universal lang file, so individual language files should no longer be necessary. But even in that Trac post, it says that with each subsequent release of WP, especially when there is any upgrade to anything in tinymce, they need to scan for certain strings that load and call the old lang files and replace them with the new technique. It seems they may not be following their own advice on that.

    I have disabled all plugins (renamed the plugins folder in cpanel), re-copied all of wp-includes from a clean 3.5.1 installation folder, switched to TwentyTwelve theme, flushed cache, closed browser, tried in multiple browsers, and this issue just does not go away for all browsers unless the en.js files copied/renamed into the tinymce folders tinymce is trying to load them from.

    Whether it is a missing gz file in the installation package, or missing en.js files in the two tinymce folders that the WP custom version of tinymce tries to load them from, or something browser or server specific, it sure seems to me that since the new language handling is now WP specific, that it is a WP bug that needs to be fixed somehow, either with core code fix to the WP customized tinymce or something in the installation packages.

    For example, in FF, in the WP editor page html, I see:

    <script type="text/javascript">
    		tinyMCEPreInit = {
      .... various stuff ... then on the last line:
    			load_ext : function(url,lang){var sl=tinymce.ScriptLoader;sl.markDone(url+'/langs/'+lang+'.js');sl.markDone(url+'/langs/'+lang+'_dlg.js');}
    		};

    Since lang is set to en, it tries to load en.js and fails.

    A solution that I have implemented successfully, on all of the sites I support, is that instead of cloning the missing files as referenced in several places, I simply do a 301 redirect in the .htaccess file to point the two invalid file references, whether caused by a core WP or tinymce bug, ill-behaved plugin, server issue, theme issue, or browser issue, to the appropriate file. This means it should not ever break again, even when I upgrade WP next time, and regardless of the browser or server, and even if I install or upgrade an ill-behaved plugin.

    ie:

    # Universal fix for invalid tinymce language file references for WP site
    RewriteRule ^wp-includes/js/tinymce/langs/en.js$ wp-includes/js/tinymce/langs/wp-langs-en.js [L,R=301]
    RewriteRule ^wp-includes/js/tinymce/themes/advanced/langs/en.js$ wp-includes/js/tinymce/langs/wp-langs-en.js [L,R=301]

    Obviously if you are having this issue, but language is not en, you will need to modify the rewriterules accordingly.

  10. Samuel Wood (Otto)
    Tech Ninja
    Posted 1 year ago #

    @ronnieg: I think the problem with what you're saying is that the load_ext function is indeed defined as the way you have it, but it's not called to load the main language files. The load_ext function is to load language files for "external plugins", which are pieces of TinyMCE that can be added on. You'll find the calling code in the editor_settings function in class-wp-editor.php.

    Given what I've found and what others have said on this issue, I'd make very sure that you actually have all the WordPress files on the problem installations, because TinyMCE is a bit sensitive to load order and will behave differently (and oddly) when parts of it are missing.

  11. ronnieg
    Member
    Posted 1 year ago #

    All standard WP files are present, and if they are not, then it is a problem with the WP version upgrade process. My process for insuring all clean standard WP files are in place if there is any question, which I have done a number of times while trying to isolate this particular problem, is to unzip the standard WP release download package into a temporary working folder using cpanel file manager, then copy wp-includes and wp-admin folders and contents to the root or other folder the site resides in.

    I have also manually copied/cloned the missing en.js files to applicable folders as some others have suggested, and that also solved the problem. But that is not a standard or supported WP file any more, so a WP version upgrade that replaces those folders and contents "breaks" it again. That's why the .htaccess approach works better in the long run, IMO.

  12. Samuel Wood (Otto)
    Tech Ninja
    Posted 1 year ago #

    TinyMCE does not load an "en.js" file on a normal installation. So you really need to find out why your site is trying to load that file at all, instead of trying to trick it that the file exists. The file doesn't exist, and doesn't need to exist.

  13. ronnieg
    Member
    Posted 1 year ago #

    Samuel,
    Are you suggesting that something outside of WP, like a plugin, may be calling the editor_settings function with parameters that are causing the failing load attempts for en.us?

    I compressed all of the contents of wp-content, downloaded the zip file to PC, unzipped, and searched all folders/files for "editor_settings" in their content (required special folder search options), and found no such function calls in any plugin or theme code.

    The only such calls I found were in the standard WP 3.5.1 release files. The only tinymce "external plugins" I see are those included in the WP 3.5.1 standard release zip file.

    The standard editor_settings function in class-wp-editor.php for WP 3.5.1 is coded to default to load en.js, not wp-langs-en.js, as the current Codex specifies. Doesn't this suggest that either this core file is not coded correctly, or the other WP core files that call it may not be doing the function call properly?

    I do not have debugging/trace tools or experience to get any further with this than I already have, so the .htaccess rules will have to stay in place until someone else figures it out.

  14. joe.toomey
    Member
    Posted 1 year ago #

    I've seen this issue once before, and it recently happened on our staging server. I found this thread on google and although it doesn't have a complete fix, it seemed current, so I thought I'd add some additional information in the hopes that we can find a solution together. We're running WP 3.5.1 with the Advanced Custom Fields plugin (latest version) among several other plugins.

    I see these errors when I try to edit a page:

    GET http://OURSITE/wp-includes/js/tinymce/langs/en.js?ver=358-23224 404 (Not Found) wp-tinymce.php:1
    Failed to load: http://OURSITE/wp-includes/js/tinymce/langs/en.js wp-tinymce.php:1
    GET http://OURSITE/wp-includes/js/tinymce/themes/advanced/langs/en.js?ver=358-23224 404 (Not Found) wp-tinymce.php:1
    Failed to load: http://OURSITE/wp-includes/js/tinymce/themes/advanced/langs/en.js wp-tinymce.php:1

    Digging through the results of http://OURSITE/wp-includes/js/tinymce/wp-tinymce.php?c=1&ver=358-23224 pointed to the source of the request, but finding it has taken a fair amount of digging (thanks for minify). It is indeed TinyMCE that generates these requests, although it could be due to a language configuration setting that varies or some other variable I haven't identified.

    In wp-includes/js/tinymce/tiny_mce.js (version 358-23224), 155,528 characters into the minified script is the following function (JS Beautified so we can at least try to figure out what's happening). This function is added to tinymce.AddOnManager among numerous functions.

    requireLangPack: function (e) {
      var d = b.settings;
      if (d && d.language && d.language_load !== false) {
        b.ScriptLoader.add(this.urls[e] + "/langs/" + d.language + ".js")
      }
    }

    I have not dug in to understand why this is called for some WP configurations and not others. I'm open to suggestions on how to get this fixed.

  15. joe.toomey
    Member
    Posted 1 year ago #

    Debugging a bit further, it appears that requireLangPack() is called by editor_template.js:

    // Tell it to load theme specific language pack(s)
    	tinymce.ThemeManager.requireLangPack('advanced');
  16. Samuel Wood (Otto)
    Tech Ninja
    Posted 1 year ago #

    You can disable minification and such by adding these lines into your wp-config.php:

    define('SCRIPT_DEBUG', true);
    define('CONCATENATE_SCRIPTS', false);
    define('COMPRESS_SCRIPTS', false);
    define('COMPRESS_CSS', false);

    However, this won't directly affect TinyMCE's script, which is pre-minified and gzipped and everything else under the sun. Still, might aid in debugging.

  17. Samuel Wood (Otto)
    Tech Ninja
    Posted 1 year ago #

    Also, if you call the get_locale() function on a system showing the problem, what do you get back? Just call it in a theme's index.php or something.

  18. joe.toomey
    Member
    Posted 1 year ago #

    I tried calling get_locale() from our theme's index.php file but I didn't see any result (not sure where I'd expect to see it.) Tried writing the result to error_log and got no result, so maybe index.php is cached somewhere (I cleared our hosting company's cache to no avail.) To be honest, I'm not a php guy and don't have any sort of debug environment set up for the php side.

    I managed to call the function from wp-tinymce.php by adding the following code that I found on stackoverflow for pulling in references to wordpress core code:

    require_once('../../../wp-blog-header.php');
    header("HTTP/1.0 200 OK");
    error_log(get_locale());

    That got around the "Call to undefined function" error I was getting prior to that. Here's what I got in the error log:

    [Wed Mar 13 15:04:00 2013] [error] [client xxx.xxx.xxx.xxx] en_US, referer: http://OURSITE/wp-admin/post.php?post=XXXX&action=edit

    So, en_US locale.

    I might be in a good position to help debug this problem, because it occurs on our staging server but not on our production server, although both are running the same set of plugins and plugin versions and are configured essentially identically. (We host at WPEngine and use their staging capability to take a snapshot of our site to staging for testing out changes.) I wish I knew when the problem first surfaced on our staging site, but I don't. I don't have tons of cycles to spend, but I'm happy to help get to the bottom of it with some assistance.

    Thanks for your help.

  19. Samuel Wood (Otto)
    Tech Ninja
    Posted 1 year ago #

    I doubt I can walk you through a debug session. Unless you can give me access to the site so that I can see it in my browser, probably no easy way to figure it out.

    Email me at otto@wordpress.org and I'll take a look at it, if you like.

Topic Closed

This topic has been closed to new replies.

About this Topic

Tags