The "$supportsGzip = false;" solution worked perfectly for me! Thanks!
The "$supportsGzip = false;" solution worked perfectly for me! Thanks!
I find it difficult to understand that this is still an issue, even with WP 2.3 installs.
I just did a fresh clean install on a brand new hosting account of WP 2.3 and...
...BING! No Rich Text Editor.
And there are about 34.65 different solutions that may or may not work.
Mine was working fine in IE after disabling plugins, however the editor was still broken in firefox. After doing the gzip thing, everything works fine.
The "$supportsGzip = false;" thing does unfortunately NOT work for me - as none of the above tricks do.
I am using WP 2.1.3.
Had the same issue with a plugin before (see this post in this thread).
Now, I installed the "Kimili Flash Embed" plugin - and I am back to the problem. WYSIWYG-editor won't work and I get a "realtinymce not defined" in the JavaScript console again.
The funny thing is:
IT WORKS OFFLINE (LOCAL) WITH XAMPP WITHOUT A PROBLEM!
So, I guess it has something to do with the server.
But I can't change the GZIP thing because my 2.1.3 tinymce GZIP php file looks totally different - there is no "$supportsGzip" variable...
Normally, I would just use a different plugin, but damn - that Kimili plugin is great, I tested the quicktag method and got XHTML-valid flash embedding. :-)
Anyone out there having a clue how to fix this?
OK, I just found another link that deals with the gzip thing, but didn't work for me, either:
http://wordpress.org/support/topic/104627#post-512864
I think I will either try and upgrade to the latest WP soon or try to edit the Kimili plugin, commenting out the code that tries to implement the buttons into the editor. There is still the quicktags option to use.
OK, I just commented out the lines for adding the buttons to the WYSIWYG-editor - and now I can use the quicktag method to embed flash objects. Who needs those buttons, anyway? :-)
Well i tried it all :) as it appears problems most of the time in how plugins a re constructed.
If all of this fails I have another possible solution to the problem of a failing tiny_mce:
Disable display_errors.
I came across a similar problem on a wordpress copy I was running on a development server (where for debugging purposes display_errors on is a good thing ;)) I had multiple blogs running on live servers with a similar setup so I could not pin down what the problem was.
Then I started firebug to check what the heck was going on and came across 3 lines through my javascript:
<br />
<b>Warning</b>: realpath() [<a href='function.realpath'>function.realpath</a>]: Unable to access /home/1234/public_html/wp-includes/js/tinymce/plugins/inlinepopups/langs/nl_nl.js in <b>/home/1234/public_html/wp-includes/js/tinymce/tiny_mce_gzip.php</b> on line <b>195</b><br />
<br />
<b>Warning</b>: realpath() [<a href='function.realpath'>function.realpath</a>]: Unable to access /home/1234/public_html/wp-includes/js/tinymce/plugins/inlinepopups/langs/nl.js in <b>/home/1234/public_html/wp-includes/js/tinymce/tiny_mce_gzip.php</b> on line <b>195</b><br />
<br />
<b>Warning</b>: realpath() [<a href='function.realpath'>function.realpath</a>]: Unable to access /home/1234/public_html/wp-includes/js/tinymce/plugins/inlinepopups/langs/en.js in <b>/home/1234/public_html/wp-includes/js/tinymce/tiny_mce_gzip.php</b> on line <b>195</b><br />
Apparently the code is searching for language pack files in a plugin folder which it cannot find and this results in PHP WARNINGS. In my opinion someone should 'condition' the code a little better to prevent it from tripping/breaking over something as trivial as this.
greftek:
I had the same problem. Disabling php safe-mode on my server solved it! I didn't have to change any php file just disable safe-mode.
Actually I got it running fine with safe-mode. Setting up safe mode (and open_basedir as well) takes a lot of tweaking to get it working right.
Funny is that i have 2 Wp installations, with the same version (2.3.1) running. The one at the root directory needed no workaround! The one in a subdirectory worked well with the "=false" one....
These things are funny.
I had the same problem.
It seems to be solved when i clear all personal data and reload the page but now the visual editor doesn't work more.
Nor the "$supportsGzip = false;" fix helps me.
I had this problem, and the thing you *HAVE* to do, is deactivate all plugins and reactivate them one by one checking it it has fixed it.
If there is a white space at the end of a php plugin file after ?> it will almost certainly be the problem!
I made a copy from the language file ("de_de.js") in
/wordpress/wp-includes/js/tinymce/langs/
and put it to
/wordpress/wp-includes/js/tinymce/plugins/inlinepopups/lang/
That fixed it for me :-)
I was having the same issues with a brand spanking new install of WP. I could not see any of the graphics on the toolbar, and all of the rest of the graphics didn't look right either. On a whim, I decided to re-upload all of the graphics, like was suggested, but instead of uploading it in "ascii", I uploaded it as "binary". Now I have my icons back. As well, I re-uploaded all the graphics that did work, and now they look right as well.
Just to mention, I tried all of the file hacks, re-wrote my site, disabled all of the plug-ins, etc. It wasn't working on my machine (Ubuntu and FF), nor my wife's computer (WinXP, but FF and IE).
Hope this helps people.
Just posting in case this might help anybody else:
I had this same problem (WP 2.3.2) and it came down to the fact that I either needed to disable the Audio Player (1.2.3) plugin or use PHP 5 (easy change on Mediatemple Grid Service)
I had also tried the gzip based fixes before and that did not work... this is weird.
wow, I checked out Bastischubert's suggestion, and that worked for me!!
then i discovered that the problem was a blank line after ?> in the wp-config.php which produces an empty line of output and screws up the gzip detection stuff, rss feeds and so on.
and that worked for me!!! I had an editor that inserted linefeeds when I edited wp-config.php.
I have to admint this is a weird one. I have a server with multiple virtual hosts all running similar installs of WP2.3.3. All are installed and updated the same way, apart from some minor variations in plugins. The visual editor broke on one site, while it was still working on others.
A couple of things worked for me and in the end I went for Octav's solution of commenting out
Scriptaculous.load();
in /wp-includes/js/scriptaculous/wp-scriptaculous.js.
The other solution that also worked for me was opening /wp-includes/scriptloader.js and replacing "tiny_mce_gzip.php" with "tiny_mce.js"
... and then I entered the twilight zone... Checking through the files, I found that I had actually edited the wp-scriptaculous.js file for the site that worked! The file on the site that had the problem was back to its original state. In between changes I had refreshed an edit window from both sites. Checked the access/error logs but nothing unusual there. I've now undone all changes and the editor is still working! ???
Linux FC6, Apache 2.2.6.1, php 5.1.6-3.7, mysql 5.0.27-1
ozbigben - Success, you've hit the nail on the absolute head.
I'm running WP 2.3.3 on two brand new, clean installs - new databases, entirely new domain names, on my own server. There was nothing obviously wrong, yet the visual editor didn't work. Not great when I wanted a few authors...
So, I have tried for the past 48 hours every single solution suggested on here. a lot of them don't even apply to 2.3.3, and its amazing how many times people are being told to "check the visual editor box" etc - it's quite clear that this is an issue suffered by many.
Just take the following steps:
1. Edit /wp-includes/scriptloader.php (not .js, but who's splitting those hairs eh?) in notepad or whatever.
2. Find "tiny_mce_gzip.php" and replace with "tiny_mce.js" reload your browser (a cache clear and/or closing and restarting it may be required also). For me, this got everything going.
Sweet relief.
But without problems like this, my life would be so dull, and my desk wouldn't have those lovely fist (and forehead) shaped impressions...
Oops... yes it is scriptloader.php ;)
The only difference I can think of in my case is that I had made some mistakes editing the template for the site which resulted in some sql errors. Whether this is significant or not I don't know, but the problem arose after the errors only on the subdomain that had the sql errors and not on the other sites... and my WP configuration is now back to it's original settings and it's working again (still).
This topic has been closed to new replies.