Hi, I've done something screwy and it's really affecting how I can use my site.

Not sure if this is a WYSIWYG issue but it is only a problem on sites where I have attempted to implement WYSIWYG. (installation and implementation on this is very confusing?)

On creating or editing nodes of content type Page, somehow the system's javascript that enables pop-down selection for menu settings or input format are disabled. So I cannot actually select an input format or define a menu setting on pages.

All other content types are fine! I can access and use WYSIWYG, menu settings etc just fine. just not on Pages.

Using lots of modules but these are what I suspect is relevant, as they may involve js:
Drupal 6.26
Admin Menu 6.x-1.8
CCK 6.x-2.9
jQuery UI 6.x-1.5
jQuery Update 6.x-2.0-alpha1
Libraries API 6.x-1.0
Superfish 6.x-1.8
Wysiwyg 6.x-2.4

TinyMCE 3.5 is editor selected for Input format WYSIWYG. Filtered and Full have no editor.
tinymce is in sites/all/libraries. Default is set to filtered html. Only Editor and Admin have permission to manage filters.

Again, this is only a problem on sites where I have WYSIWYG. Never seen it anywhere else.

Comments

katharine_gates’s picture

katharine_gates commented

I switched to CkEditor, that didn't help. Trying a different theme (Garland, Minelli) didn't help.
Disabled a bunch of modules. Flushed Caches.
WYISWYG works by the way on all other node creation than Page.

Could the fact that I added WYSIWYG, filters, libraries etc. as an afterthought (after there was already "Full Html" content in the body field of many pages) be causing this?

twod’s picture

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

On creating or editing nodes of content type Page, somehow the system's javascript that enables pop-down selection for menu settings or input format are disabled.

This gives a clue to what happened. Most likely, there was a JavaScript error somewhere, which caused the browser to stop script execution on the page, preventing behaviors like the drop-down fieldsets, context menus and the editors from loading properly.

It does not matter when you enable Wysiwyg module, it does not directly interact with the formats other than associating an editor profile with the name of a format and it does not require content to have been created using an editor.

If you see this happen again, check the browser's JavaScript console for errors. If there are errors, disable JavaScript minification/optimization in Drupal's Performance settings and note in which files and on which lines errors appear. If your browser includes backtraces with the errors, those would be helpful too. If you can, please also check if the errors happen in more than one browser.

Which parts of the Wysiwyg module and editor installation did you find confusing? How could we improve it?

katharine_gates’s picture

katharine_gates commented
Status: Postponed (maintainer needs more info) » Closed (works as designed)

Thank you for a great module and for your help!

Turns out it was a problem with a conflict between jQuery Update and the latest version of Drupal 6 (6.26). I had to update JQuery Update to the latest dev version.

I hope this is helpful to someone.

As for what I found confusing, it's the many-step process of enabling input filters and assigning filters and going back and selecting buttons to put in the editor. Wish this could be somehow written into the module so that install/config is a little simpler.

twod’s picture

twod
Primary language Swedish
Location Sweden
commented

Ah, yes, that can be a bit confusing. When not using an editor it's simple enough, there's just Drupal's own filtering system to configure. With the addition of an editor comes the task of setting up the editor so it only produces the output Drupal will accept, while keeping in mind these are "soft filters" since users can simply disable the editor at will. I've seen a couple of people getting these mechanisms mixed up and thinking that once they've set up the editor the way they want, they don't need to care about Drupal's serverside filtering - though that is the most critical part.

I've been meaning to go over the online documentation to clarify the initial setup process and perhaps how to make it a bit smoother.
The ideal situation would be to have the editor automatically adapt to what the filter settings are, or at least give warning when things get out of sync. The main issue with that is the scope and nearly unlimited amount of permutations possible between the filter and editor settings. Unless done in some very clever way, the logic to determine which editor settings to change when certain combination of filter settings are enabled would get enormously complex and difficult to maintain as editors evolve.

If you have any ideas on how to make steps towards a smoother setup experience, I'm all ears.
I can also recommend following a couple of the big issues we've got related to this, such as #313497: Allow configuration of advanced editor settings and #277954: Allow to sort editor buttons.