Use case 1: A particular node or block needs to include code that would be damaged by the editor (e.g., TinyMCE or CKEditor).

Use case 1: A system field which should not be edited as WYSIWYG is loading the WYSIWYG editor.

I'm not seeing a way to configure the WYSIWYG module to address either of these use-cases, which I encounter routinely when building websites for clients.

Comments

TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD commented

Wysiwyg only cares about which formats are available, and there's currently only one editor profile per format. We're aiming to provide multiple editor profiles (perhaps even an "empty" profile) in the future, but not much work is done yet.
The basic idea is to always keep the editor configuration in sync with the current text format configuration, so you won't suddenly be stuck with an editor outputting BBCode when the server only understands wiki syntax.

1) What part of the content is broken/mangled by the editor? Do you have a more specific example?
Wouldn't that situation be a perfect candidate for having a plugin which lets you deal with that content in WYSIWYG mode? Or perhaps just replaces the sensitive snippet with a placeholder (image?) so users - and the editor - won't be confused.

2) If the content shouldn't hold markup, why is the text format used on it assigned a markup editor?
Do you have an example of these system fields where an editor makes no sense?

escoles’s picture

escoles CreditAttribution: escoles commented

1: It's a case-by-case thing. As often as not, the problem is that people editing the page can insert things that would cause formatting issues (such as extra paragraphs, or containers without appropriate style classes or IDs). But there are also cases where it's necessary to have precise HTML in a Body or CCK field on a particular node, or in a particular block.

2: It's not that the content shouldn't hold markup -- it's that the markup can be broken by a WYSIWYG editor.

It seems to me that the responses I hear to this request basically amount to rationalizing away the need for it.

TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD commented

There's a feature I just realized I forgot to mention in my earlier post, apologies for that.
With the later versions of Wysiwyg it's possible to use the FAPI and a hook_form_alter() implementation to add a '#wysiwyg' => FALSE property to any format-enabled field, and it'll be completely ignored by the module. It's meant for when it's critical for some fields not to have an editor. I think it should preferable be accompanied by a note somewhere saying that editors have been disabled by purpose, despite the same text format being used elsewhere with an editor.

Is that what you're looking for or do you need something else?

In response to your last paragraph; I'm just more eager to find ways to adapt the editors to work with content actually used in production, rather than disabling them in some places and having people wonder why they don't always show up when their format is selected. That, and I want to make sure the request isn't being made because the person thinks disabling the editor will in any way prevent other users from entering malicious content. (Yes, that does happen.)

escoles’s picture

escoles CreditAttribution: escoles commented

I simply find that in every site I implement I have to disable some fields, and the decision about whether or not they need to be disabled doesn't have anything much to do with what particular field it is -- it has to do with what particular node or block it is, which (conveniently) can normally be matched to a URL substring. From what I can see, this is a common scenario for others as well.

It sounds to me like what I need to do is create an add-on module for WYSIWYG that affords the ability to add exceptions as needed. I imagine I can crib the form code from older versions of the CKeditor or TinyMCE modules. Whether I do it here or in the CKeditor module would probably be driven by how easy it is. (That feature has currently been regressed out of CKEditor.module in 7.x.)

TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD commented

Yes, I suppose an add-on module could be made to put the #wysiwyg property on fields based on a URL blacklist, or blacklists based on field/node/entity type/id combinations if that's desired. It would technically not need to depend on Wysiwyg, so it could be used with other editor modules that check the #wysiwyg flag. I know several did before, but I haven't checked lately.

The module could be implementing hook_form_alter(), check the current URL/form-id/entity-id/etc and traverse all fields using element_children() until all text_format fields have been found and compared to the blacklist. Maybe it could be made more efficient and only work with text_format fields by implementing hook_element_info_alter() and adding a process/after-build/pre-render callbacks? I guess that depends on if the filter criteria can be checked using the data in those callbacks...

Wysiwyg and other editor modules could recommend users to try such a module if this type of functionality is desired, and it the filtering method(s) could mature on its own without being hampered by Wysiwyg's currently slow pace. It might even be preferable if you at one point decide to switch to a different module. If all modules support that flag, your blacklists would not have to change or be recreated.

Thanks for the note about CKEditor.module for 7.x, I didn't know they had made that change.