• jazzle

    (@jazzle)


    I really hoped 2.1.1 was going to fix this, but alas not.

    I get the titular error when trying to write a post or page with the ‘Visual Editor’ on.

    I’m fairly sure it’s something to do with the GZIPing of the relevant JS file(s), but changing the GZIP option makes no difference to this problem.
    GZIP option does affect the main blog as it should (confirmed via whatismyip.org).

    Same problem in IE6/7/Firefox2.
    I’ve not done anything to the .htaccess file, nor any server settings.

    Host is Dreamhost. Blog address: https://blog.carbon-360.com/

    Any help will be much appreciated.

Viewing 15 replies - 16 through 30 (of 49 total)
  • FOLKS- Found a possible solution:

    Your Profile if the WYSIWYG-Editor is checked so it is on. If not, check it and save changes.

    Moderator Samuel Wood (Otto)

    (@otto42)

    www.ads-software.com Admin

    The NoScript issue was actually discovered a couple of days ago here:

    https://trac.www.ads-software.com/ticket/3882#comment:27

    Props to g30rg3x and the NoScript devs for fixing the issue.

    Same problem with me here:

    all of a sudden (although working fine before), the icons for formatting the text were no longer shown in the visual editor and I couldn’t switch between “visual” and “code”.

    I deactivated all plugins and reactivated them one by one.

    Result:
    If WP-ContactForm (v1.4.3 by Ryan Duff) is activated, the problem appears. If it is deactivated, it’s all good.

    Does anyone know a similar plugin that’ll actually work with WP 2.1.3?

    Yeah.. I had similar problems here after upgrading. The visual editor used to work, then stopped working after upgrading to 2.1.3

    I swept back through my plugins, turning them all off, then one by one back on, and now things are normal again.

    Not running any off the wall plugins.. just:
    Spam Karma
    Widgets
    wp-polls + widget
    recent-comments
    subscribe-to-comments

    Strange that just turning them on and off would fix it. Hope it stays fixed, but I will repost if it ‘breaks’ again…

    it is not working for me either.
    I am using WP 2.1.3, tried to turn off all plugins, including refreshing with shift and ctrl – and none of it helped.

    I keep getting:
    line: 44
    char: 2
    Error: ‘realtinymce’ is undefined
    code: 0
    url: <omitted…>/wp-admin/post-new.php

    any thoughts ??
    Tal.

    Same problem here in 2.2

    Hi, I’ve got a problem with the visual editor of WordPress.
    In localhost everything works perfectly but in my hosting phpnet.us the visual editor doesn’t work. I get the following message in the Error Console:”Error: realTinyMCE is not defined
    Archivo de origen: https://manikomio.phpnet.us/wordpress…p?ver=20061113
    Línea: 43″

    I’ve tried to find a solution in lots of Forums but no post was helpfull. I think this has something to do with the hosting service, the permissions or something else…I really don’t know.

    Can someone help me with my problem?

    Thanks a lot

    For the non-technical just trying to fix their blog, the quick fix is:

    SOLUTION:

    1. Open /wp-includes/js/scriptaculous/wp-scriptaculous.js in your favourite editor
    2. Comment or delete the last line. Example:

      Scriptaculous.load();

      make it look like:

      // Scriptaculous.load();

    What really happens is that the TinyMCE script tries to find the url it is loaded from (look in /wp-includes/js/tinymce/tiny_mce_gzip.php line 257). Because of some weird problem caused by the Scriptaculous library, all of the script tags that are located after the Scriptaculous one in the source are removed from the DOM (become invisible to calls like document.getElementsByTagName("script")). TinyMCE has trouble finding the url because TinyMCE is *usually* loaded after Scriptaculous, so the visual editor won’t work. In some cases, if you hit refresh enough times, you might cause TinyMCE script to be loaded before Scriptaculous and then it would work.

    Now, the problem with Scriptaculous resides in the following code, which handles loading additional libraries via the load= parameter (see /wp-includes/js/scriptaculous/wp-scriptaculous.js), specifically:

    $A(document.getElementsByTagName("script"))

    $A applied to the scripts collection seems to cause the weird side effect of removing some from the DOM. $A comes from the Prototype framework and should normally extend the DOM objects with additional functionality. I am not sure if this weird script-disappearing thing is a known issue with the Prototype framework, so maybe somebody can comment on that.

    Anyway, the fix I presented will prevent the buggy code from being run. It is not needed because the libraries are loaded one by one, manually. Some workarounds presented earlier might work also, but this seems to be the cleanest way.

    I tried pretty much everything here…

    Upgrades, removing plugins, adding plugins, the scriptaculous onLoad bit etc.

    NONE of the wordpress sites I work with seem to have the rich text editor coming up (enabled in user profile). I’ve tried IE7, FF2.0.0.4, Safari 3.0.1 (windows) and Opera 9.21.

    I only run the windows firewall (and am double routered (is that a word?) I run avast anti-virus, and no active spyware protector (X-cleaner runs on boot, and I manually run adaware a couple times a week). Oh ya XP sp2 auto update running.

    The code helper works just fine, and I’m well versed in xhtml and css so have relied on that for the past 6 to 8months. I only noticed this when I was trying to walk a client through the rich text editor. They see it fine I cannot.

    Any clues?

    So I had a similar problem, but it was definitely an issue with the server not supporting gzip properly. (Everything worked on my local server). I went in to this file:

    /wp-includes/js/tinymce/tiny_mce_gzip.php

    and found this code:

    if ((in_array(‘gzip’, $encodings) || in_array(‘x-gzip’, $encodings) || isset($_SERVER[‘—————‘])) && function_exists(‘ob_gzhandler’) && !ini_get(‘zlib.output_compression’) && ini_get(‘output_handler’) != ‘ob_gzhandler’) {
    $enc = in_array(‘x-gzip’, $encodings) ? “x-gzip” : “gzip”;
    $supportsGzip = true;
    }

    Immediately after I overrode the $supportsGzip var with a false value by inserting the following line after the block reference above:

    $supportsGzip = false;

    Bingo! everything works fine now.

    In this way I resolved the problem! Thanks a lot! Ciao ciao

    thanks ianjohn27, that worked for me too! Seems pretty hack-y though. Is this the ‘right’ way to fix the problem?

    Thanks ianjohn27, that worked like a charm. They should include the GZIP option in their next releases.

    Strange, cause my server does accept GZIP:
    _SERVER[“HTTP_ACCEPT_ENCODING”] = gzip, deflate

    Thanks again!

    had the problem today that could be fixed with the gzip workaround.

    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.

    when i restored the tiny_mce_gzip.php to the default (with the fixe provided here) and cleaned up wp-config.php everything worked fine ??
    so look out for initial empty lines in the output of your blog ;))

    The “$supportsGzip = false;” solution worked perfectly for me! Thanks!

Viewing 15 replies - 16 through 30 (of 49 total)
  • The topic ‘realTinyMCE is not defined’ is closed to new replies.