I just installed WYSIWYG with the latest stable version of TinyMCE on a Drupal 5 site, and although I think I've configured everything correctly (I had already set it up on about a dozen Drupal 6 sites, so I'm pretty familiar with the setup), the editor is not showing up on the actual edit page.

As advised by a comment in another issue, I checked the error log in my browser (Firefox 3), and saw several occurrences of "Error: Drupal is not defined" from line 9 of wysiwyg.js. I checked that line and it says:
Drupal.wysiwygInit = function() {
However, I am really not sure what to about that. I also tried checking the site in Safari, and the editor didn't show up there either, though no errors were reported.

Just to eliminate some of the issues raised in other TinyMCE-related posts, I am not using any language other than English; I am not using IMCE; there is no Flash button in this version, enabled or otherwise; yes, Javascript is enabled in both browsers; yes, I enabled TinyMCE for the input format I'm using; and the version numbers of everything are as follows: Drupal 5.18, WYSIWYG 5.x-2.0, Image Assist 5.x-2.0-alpha3, and TinyMCE (the editor, not the defunct module) 3.2.4.1.

I did notice that the handbook page (http://drupal.org/node/358296) says that even "passive users" should be using a development version of ImageAssist (3.x-dev), and lists version 2.x as being "abandoned", which seems weird to me, given that the ImageAssist page lists 5.x-2.0-alpha3 a the recommended version for Drupal 5, and development versions of anything are usually not a good idea to use on production sites, especially sites like the one I'm working on, which will be administered by people who are not very technical and would probably panic if they saw an error message.

I don't know if the ImageAssist version would be a factor in this problem, though, and I'm reluctant to upgrade it since it can be difficult to revert successfully back to an older version of a module if the new one proves to be unstable, as a dev version likely might be.

Has anyone else run into the "Drupal is not defined" error before? Could it have anything to do with ImageAssist, or is it something separate? And if ImageAssist is involved, is it actually safe to use 3.x-dev on a production site that will be maintained by non-geeks?

Any advice would be appreciated...

Comments

TwoD’s picture

Let's focus on the error message first. If Drupal is undefined, it might mean that the Drupal core script which defines it somehow failed or is missing. There's a possibility that Image Assist, Wysiwyg API or any other JavaScript on the page is also the cause if there's an error severe enough to halt all or some script executions in the browser.
You can easily check if a script is missing by installing the Firebug extension in FF and looking at its Net tab. Any files that could not be downloaded are highlighted in red. (Turn of JavaScript compression/optimization if you have it on.) That is, as long as the correct script tag to include them is present in the code, if not it's a bit harder to figure out what went wrong.

Drupal 5 has a much earlier version of jQuery so Wysiwyg API depends on http://drupal.org/project/jquery_updates, is that installation ok?

And of course, if you haven't already looked in the FAQ, check this:
http://drupal.org/node/417166#theme-scripts

sun’s picture

Status: Active » Postponed (maintainer needs more info)

Can you disable Image Assist, also remove Image Assist from your wysiwyg profile(s), and test again whether it works, please?

"Error: Drupal is not defined" from line 9 of wysiwyg.js

could mean that wysiwyg.init.js was not loaded before wysiwyg.js. wysiwyg.init.js should be loaded as one of the first JS files, directly after jquery.js.

Last, but not least, the only thing preventing a first alpha release for Image Assist 3.x are missing testers. So, if you install it, and report back that it works flawlessly for you, then you will probably get a release. Sounds good? :)

spidersilk’s picture

Status: Postponed (maintainer needs more info) » Closed (fixed)

OK, taking these one at a time:

1. I tried first removing Image Assist from the profile I was using, and then disabling the module altogether, and neither of those helped - the editor is still not showing up. So I guess it's not Image Assist that's the problem.

2. I do have Jquery Update installed - version 5.x-2.0.

3. I checked the Net tab in Firebug (didn't know about that option in there - thanks!) and wysiwyg.js appears to be the only Javascript that's loading at all - no other appears in the list at all, not even as a failed upload!

4. Given that, I checked the HTML source of the page (which I really should have done to start with -- I think I was just very tired and not thinking too clearly last night) and voila, no Javascript in the head section of the page whatsoever.

So at that point I suspected I might know what the problem was, and just to check, switched to the Bluemarine theme and tried the edit page again. Behold, TinyMCE in all its glory!

So apparently this is a theme problem rather than a WYSIWYG problem as such. I should perhaps mention that this site was originally running 4.7 and I just upgraded it to 5 very recently, including having to manually upgrade the theme it was using since I'd customized it fairly extensively. I'm thinking I must have screwed up whatever part dealt with Javascript loading, so I will need to go and revisit that. Sorry to pester you with something that was apparently my own mistake!

Finally, to sun - I'd be happy to test Image Assist 3.x, but I'm a little reluctant to install a dev version on a client's site. However, when I next have a chance to work on one of my own sites, I'll install it and give it a try. I am much more comfortable working with bleeding-edge software than I suspect most of my clients are. :)

konsumer’s picture

Category: support » bug
Status: Closed (fixed) » Active

This is not a theme problem. $script should not be required at top of page template. If you really need to be putting your scripts in header (you don't) put them in $head. Otherwise, they should work either way.

The problem is that wysiwig does not have it's init function in a "$()" (or "$(document).ready()")

It took me a while to troubleshoot this issue.

A workaround is to put print $scripts in head, instead of later in source.

I am annoyed by this issue, because it is more efficient (browsers load them faster) and better for SEO stuff if scripts are at end of HTML source, and this is generally not a problem (in fact, often recommended), as long as init functions are used correctly (after DOM source is fully loaded)

I just noticed the comment in tinymce-3.js:

* This function needs to be called before the page is fully loaded, as
* calling tinyMCE.init() after the page is loaded breaks IE6.

This forum provides more info about this bug, and better workarounds:
http://tinymce.moxiecode.com/punbb/viewtopic.php?id=3725

sun’s picture

Status: Active » Closed (fixed)

That forum post only contains hacks of the TinyMCE library. But also a final statement that moxiecode is not able to replicate the issue.

Good. Now I moved $scripts and $styles into the footer. Of course, before $closure - as explained in the FAQ:

    <?php print $styles ?>
    <?php print $scripts ?>
    <?php print $closure ?>

Works without any issues.