Visual Editor Not Working on Upgrade

I did the following per the suggestions on ian_spare’s thread:
https://www.ads-software.com/support/topic/166212

– Deleted the files in wp-content/uploads/js_cache
– Set the WPLANG define in wp-config.php to ‘en’
– Cleared all the caches on browser
– Manually reloaded /wp-includes/js/tinymce/tiny_mce_config.php

It’s not a cache issue, it simply doesn’t work. If I click to toggle to HTML view Firebug displays the following error:

tinyMCE is not defined
var ed = tinyMCE.get(id);

I just noticed that I am getting the following JS error when the visual editor pages load:

missing : after property id
var tinymce={majorVersion:’3′,minorVersion:’0.6′,releaseDate:’2008-03-xx’,_init:…
tiny_mce_config.php (line 37)

This should be the problem, can we get a patch please?

Problem resolved! It seems to be an issue with the TinyMCE code in the 2.5 WordPress release.

1. Download the latest version of TinyMCE from the offical site:
https://prdownloads.sourceforge.net/tinymce/tinymce_3_0_6_1.zip?download

2. Unzip the following files into wp-includes/js/tinymce:
– tinymce\jscripts\tiny_mce\tiny_mce.js
– tinymce\jscripts\tiny_mce\tiny_mce_popup.js
– tinymce\jscripts\tiny_mce\tiny_mce_src.js

3. Delete the files in wp-content/uploads/js_cache. Clear all the caches on browser, manually reload this URL on your blog: /wp-includes/js/tinymce/tiny_mce_config.php to verify

is there someway you can post the output if you just enter https://ksjdksadj/wp-includes/js/tinymce/tiny_mce_config.php?ver=20080327 in the browser?

another check might be useful, with an editor just make a page at the root of your install :

<?php
require(‘./wp-blog-header.php’);
echo “locale is “.get_locale().”\n”;
?>

I just reverted mine to the error state to convince myself the source was the WPLANG and there’s no doubt. I did need to do a little dance with caches to get the change to start failing again though.

If nothing else, in firebug the script tab should show the line, at the end of the line is something like :

tinyMCEPreInit.start();tinyMCE.addI18n({ :{

that’s the broken version.

And after fixing WPLANG, using inspect from firebug here’s the good version :

tinyMCEPreInit.start();tinyMCE.addI18n({en:{

It’s obfuscated code really, practically impossible to read.

ah, our posts crossed ! I still think you had the WPLANG problem, did you leave it defined or not? It takes a hard kick on the caches once you’ve fixed it to get the new version. I altered the version string in the MCE code so I knew I’d got my version and not the original.

ian_spare: I may have had the WPLANG problem, however even after fixing my wp-config file and deleting caches I was unable to get it working without the TinyMCE update ?? I just checked the following, am getting expected locale results:

– Your script results: “locale is en”
– Firebug inspect: tinyMCEPreInit.start();tinyMCE.addI18n({en:{

I reset my wp-config have WPLANG unset as of now just for grins.. and it’s working A-OK.

Mine worked just fine after reverting the WPLANG, right until I removed the js-cache files and flushed my browser cache. The js-cache validation just looks plain wrong.

@ian_spare so what did you have set in WPLANG to break get_locale()? In your other thread you mention you use French, setting WPLANG to ‘fr_FR’ works perfectly on my server. Even downloaded the French .mo file and all of WordPress including TinyMCE is translated nicely.

Seems that either your installation of 2.5 didn’t go through well, or you’re using a plugin that breaks get_locale(). The only difference between using WPLANG directly or using get_locale() is that the function allows a plugin to filter what’s set in WPLANG.

If you’ve looked through tiny_mce_config.php, you must have noticed that there are settings to control compression and caching in the init array there. You can either hard-code them or use the small plugin mentioned in this thread. Also setting a different locale will (of course) invalidate the local disk cache and load the translated strings in TinyMCE.

@aphexddb, there are few minor differences between the TinyMCE version included in 2.5 and the latest one, mostly dealing with rare memory leaks in IE6. What might have happened is that the first time you uploaded 2.5, tiny_mce.js got corrupted.

I would suggest backing up the tinymce directory, deleting it and uploading a fresh copy from the 2.5 installation package, as there may be more corrupted files. Also make sure your ftp client is set properly: uploading .js, .css and .php files as text and image files as binary.

After that you will have to manually delete the /wp-content/uploads/js-cache/tinymce_… file.

azaozz the WPLANG variable was empty and unset initially. I suggest you review the get_locale code and you’ll see how the locale is actually detected. Your test using French isn’t useful. I’d also re-read the code for js-cache invalidation, altering the WPLANG won’t invalidate the cache (of course). In fact, I don’t believe you’ve actually looked at the code at all.

My installation is 2.5 was fine, I don’t have a broken plugin. At some point it’s just insulting that you assume everyone else is wrong. It’s broken, get_locale will leave WPLANG and locale unset in some instances and there’s code in tiny_mce_config.php which assumes WPLANG or locale is never unset. We call that a bug or we have been doing for the 20 years I’ve been a software engineer.

If it’s now mandatory that WPLANG is set that’s just super, in that case it’s a bug that the install process isn’t highlighting it.

i had this problem, but i deleted the js folder in the wp-includes folder, reuploaded it all and then it worked.

Aphexddb’s solution fixed it for me.

Thanks.

@ian_spare, the get_locale() is only few lines long and does 2 things: checks if locale is set as a var or in WPLANG, then runs it through apply_filters( ‘locale’, $locale ); and returns it. It’s been in WordPress for a few years, since version 1.5 and don’t think anyone has ever had problems with it.

The compressor calls get_locale() and if empty, sets the language code to ‘en’, if not – uses the first 2 letter from the locale. It expects that the locale is either empty (default) or is set according to the WordPress installation and configuration instructions.

In your case, as you describe it, the locale is neither empty, nor is set to a proper value, like de_DE, fr_FR, etc. If you didn’t set that in WPLANG, the only logical explanation is that some script is using add_filter( ‘locale’, ‘%$#^%$’ );. It may be a plugin or a localization script, or my-hacks file, etc. You could try commenting out both filters in get_locale() to see if it makes a difference.

Also the constant WPLANG is one of the first to be set as it is defined in wp-config.php that’s loaded very early. It is always set, either to an empty string or a proper locale.

Anyways, if you really feel offended from me trying to help you or understand your problem, then I don’t see a point in this…

None of these suggestions work. Any other ideas?

I tried all that methods above and in other topics, and still no visual editor. I think actually to have tried EVERYTHING on the forum ??

In firebug I get this message:

uncaught exception: Illegal document.domain value (NS_ERROR_DOM_BAD_DOCUMENT_DOMAIN)
var tinymce={majorVersion:'3',minorVersi...MCEPreInit.start();tinyMCE.addI18n({en:{

Some additional info:
I have 4 installs of WP on the same server (yeah, I knew of WPMU only after setting everything up…): the issue occours only on the root install, the others that are in 3 subfolders are working like a charm!

It seems that on my other machine, with Ubuntu 7.10 and FireFox 2.0.0.14, it works OK for the visual editor, but it doesn’t insert the uploaded picture in the post.
The same occours on my main machine if I use Opera. (main machine: Ubuntu 8.04 – FF3beta5). Tried also with Epiphany, but it is exactly the same of FireFox3.

Ask me if you need further informations, but please someone find a solution!

Make sure you access the admin with exactly the same url as set in WordPress and that it’s the right one. NS_ERROR_DOM_BAD_DOCUMENT_DOMAIN means that TinyMCE is trying to access some of its files probably from a sub-domain and it takes the path from the setting in WordPress.

If all this is OK, check your .htaccess file for possible improper redirects. Also look if there are more than one .htaccess in different sub-directories and check them all.