After upgrading from 6.x-2.x-dev (i want to start using ckeditor), i lost my wysiwyg editor.
In my existing situation I had a wysiwyg profile tinymce coupled to its own input format tinymce. The input format was set to default for all content types and all roles. When reverting to 6.x.-2.0 everything would be back in working order.

My debugging process:
I disabled all devel modules.
I disabled suspect modules (like hierarchical select and the dev version of admin 2)
I reset language to English.
I reverted to Garland.
I reset buttons to just bold & italic for wysiwyg profile tinymce.
I uninstalled and reinstalled wysiwyg-6.x-2.x-dev, updating the database and flushing cache as i went along.
I disabled all filters for input format tinymce.
I disabled all plugins for wysiwyg profile tinymce.
I rearranged default input formats.
I applied the same input format to all roles.
I installed new wysiwyg profile wymeditor.

None of this worked. Firebug was still only throwing an undefined exception #.
After retracing my configuration steps a couple of times, I figured that the only thing that was different is that i've stopped using the default body field on my content types. (I did this because the way I understood it, body will be deprecated in D7.)
I reactivated body for a content type, flushed my cache and found wysiwyg up and ready again. What I do not grasp is that after a retry (flushing cache between attempts) wyswyg was now active for the other content types as well.

With this write-up I hope to save other people some time and I look forward to input from under the hood.
The one exotic setting I have not checked for was having vertical_tabs and form enabled. They may intrefere with the rendering as well.

Comments

whatdoesitwant’s picture

whatdoesitwant commented

Correction: The issue occurs after upgrading to 6.x-2.x-dev (version 2009/11/22).

twod’s picture

twod
Primary language Swedish
Location Sweden
commented
Assigned: whatdoesitwant » Unassigned
Status: Active » Postponed (maintainer needs more info)

As far as I know, the body will not be deprecated in D7 but implemented the same way as other fields as parts of CCK is now in core.
I found this issue #372743: Body and teaser as fields discussing the details [currently 230+ comments so no, I didn't read it all and might have missed somehting important ;P].

Did Firebug mention on which line or in which file the error was? Did it appear when just when the page had loaded, a while after or when you did something specific?

What did you use instead of the body, a CCK field? (i.e, where were you expecting the editor to appear?)

Thank you for taking your time to do all those debug steps, especially switching back to Garland, testing a different editor and removing plugins etc. The input format settings do not affect the editors as their code only runs when the node is viewed, but that list rules out a bunch of other things.

whatdoesitwant’s picture

whatdoesitwant commented

Thank you for the link to the body field discussion. I have cried wolf with wysiwyg before, hence the elaborate steps. I appreciate knowing that some of them were the right ones.

I use a custom cck field "tekst" (textarea, required, 1 instance, filtered) instead of body. The timing of the problem is after the content form is rendered. In the old version of wysiwyg with caches cleared and update run, there's a millisecond of a moment where the plain textarea is visible before the editor rendering kicks in. After upgrade this '2nd stage' just didn't happen anymore. After reverting to to the production version of wysiwyg it would.

In hindsight, Firebug's uncaught exception wasn't referring to wysiwyg at all. Now that all editors are working again, I get a referral to the autosave module's autosave.js, which I have installed by default on all sites and had completely forgotten to disable. Before, I was too focused on the wysiwyg to look at firebug when it was working.

What I can not figure is how adding the body field for one content type jumpstarts wysiwyg for all other relevant fields and content types (even after I remove it again), when adding a completely new wysiwyg profile would not. But it is good to know that this works. Unfortunately, with dev now working I have to finish my project before I can look into this further.

twod’s picture

twod
Primary language Swedish
Location Sweden
commented

I have a feeling the Autosave module uses AJAX, right? AJAX behavior usually collides with this module as we need to detach an editor to make it synchronize its contents with the original textarea before the form is submitted in the background, but they might also collide if one script breaks and script execution is halted or 'disturbed' in some way.

I don't know yet why re-enabling the body field on one content type solved it, but I'll look into that after resetting my dev environment. If you have time after the project is done (some of my projects never seem to end :/), could you try reproducing this error in a new 'sandbox' installation for?

whatdoesitwant’s picture

whatdoesitwant commented
Priority: Normal » Minor

Recheck shows that the issue is limited per content type, depending on whether or not Body is enabled. I must repeatedly have forgotten to clear the browser cache properly. I will try to be more careful.

I have set up a sandbox with a minimal installation. In this environment I cannot reproduce. Disabling Body does not break behaviour. I seem to really have screwed things up in my dev and production environments prior to upgrading wysiwyg. It becomes likely that wysiwyg is symptom instead of cause. I will continue to bring the sandbox up to dev level and definitely get back to you if i find something. For now I seem to have cried wolf once more, marking as fixed. Very sorry for the inconvenience. Thank you for your valuable support.

Off topic, the bug that was thrown by firefox (unrecognized expression: [@href^=http]) seems to be unrelated to wysiwyg or autosave. Apparently one of my installed modules is still suffering from #358082: jQuery 1.3 in Drupal 6.x, still narrowing it down...

Edit

I have brought my sandbox up to dev level. I have not been able to reproduce the issue. After reinstalling most modules in the dev sites the issue was gone from there as well. This suggests corrupted tables, but in a similar fashion. Still, with the problem not recurring I cannot pinpoint the source.
I tracked the unrelated issue to #666980: xpath selector in external.js breaks sites with current jquery version and it is now solved.

whatdoesitwant’s picture

whatdoesitwant commented
Status: Postponed (maintainer needs more info) » Fixed

Setting to fixed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

nickrice’s picture

nickrice commented
Version: 6.x-2.x-dev » 6.x-2.1

I've got a similar, possibly identical, issue and am getting some weird behaviour. But an odd work-around fixes it for me that I'll note here in case it helps someone.

I'm not looking for anyone to spend any time looking into this as I suspect some sort of other hidden corruption in my site might be contributory and I don't currently have time to look into something that is now working.

Symptoms:

1. Initially had a body with ck editor (enabled for Wysisyg, of course) working fine.

2. Decided to use a cck text area instead (as I wanted to fire a Rules rule on it when it gets changed). The ck editor was fine on that new field.

3. Turned off body in the content type (after deleting all nodes' body content) and the text area lost the editor.

4. Re-enabling the body got the editor back.

Now, here's the really weird work around ...

If I disable the body (in the content type) AND hide the body field as the form is being built using Rules (which I'm using anyway so it's just an additional action) then I don't get the problem - even though there's nothing for Rules to actually hide.

If I try removing the apparently redundant Rules action the problem returns.

(Clearing all caches makes no difference to any of this.)