Here is a simple patch that introduces the $op = 'javascript' to hook_filter(). This allows filter modules to expose some attributes which can help WYSIWYG editors to know how filters will act on their output on the server side. E.g. for core filter_filter() a list of allowed tags is made available, allowing the RTE to enable/disable some features based on it, another one tells editors that line breaks will be replaced with paragraphs tags, urls will be made links, etc.

Probably the term 'javascript' is not good enough, but I could not come together with a better one ATM.

For now it only adds some settings to Drupal.settings object. I'm planning to make a javascript API available, so RTEs can know what format is currently available and fire events when a user switch between available formats.

Here is what is added to Drupal.settings object on /node/add/page:

{"filter":{"format":{"1":{"autoLinks":true,"allowedTags":["a","em","strong","cite","code","ul","ol","li","dl","dt","dd"],"autoLineBreaks":true,"htmlCorrector":true},"2":{"autoLinks":true,"autoLineBreaks":true,"htmlCorrector":true}}}}

Comments? Does this approach sounds right?

CommentFileSizeAuthor
wysiwyg_support.patch2.6 KBrecidive
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

recidive’s picture

Status: Active » Needs review

Oops. Needs review.

sun’s picture

Just tracking.

maartenvg’s picture

Status: Needs review » Needs work

No longer applies.

patching file modules/filter/filter.module
Hunk #1 succeeded at 476 (offset -3 lines).
Hunk #2 succeeded at 501 with fuzz 2 (offset -3 lines).
Hunk #3 FAILED at 522.
Hunk #4 succeeded at 657 (offset 1 line).
Hunk #5 FAILED at 720.
Hunk #6 succeeded at 723 (offset -13 lines).
2 out of 6 hunks FAILED -- saving rejects to file modules/filter/filter.module.rej
sun’s picture

I'm not sure what those JavaScript settings buy us. For Wysiwyg API, we need that information during the page generation process, so we are able to limit editor configurations in front of them being available to the user. When talking about improvements in wysiwyg support in Drupal, we should always keep in mind that a fully wysiwyg-enabled Drupal system needs a bunch of editor configurations - for example, at least one for each content-type (if not even one per input field), comments, user signatures, aso.
Hence, this JavaScript settings array would become quite big in the end.

I think the scope of this issue is too broad; needs a better title. What I like in this patch is the _filter_allowed_tags() function. However, Wysiwyg API would need to access it and I see no reason for making it a private function.

sun’s picture

Title: Better support for WYSIWYG editors » Expose filter configurations for editors
Project: Drupal core » Wysiwyg
Version: 7.x-dev » 6.x-1.x-dev
Component: filter.module » Code
Assigned: recidive » Unassigned

Moving over to Wysiwyg API.

markus_petrux’s picture

Oh, thanks for moving to the Wysiwyg API queue.

This is something I was talking about at g.d.o..

I just pushed the Wysiwyg Filter module to RC state, though I would love to have a method to tell TinyMCE (or whatever else editor) parameters such as valid_elements (this is how one of the options of the filter is configured) and invalid_elements (this one is hardcoded in the filter code for security reason).

Not sure which is the best approach to do this, though. Maybe the filter could expose what it is able to do in a somehow structured way that the Wysiwyg API could use to setup editor options based on features supported by each one of them, which probably means extending the information editor packages (I mean wysiwyg/editors/*.inc, etc.) generate for the API. What could a filter be able to pass on to a Wysiwyg editor? Knowing that, would make it easy to design the API for that.

On the other hand, it would so much user friendly to configure the filter based on options enabled for the Wysiwyg editor. In example, if the editor is configured with the color button, and that means the editor will need the filter to accept the corresponding tags, inline styles, etc. then, the filter could just do it, if there was a way to tell the filter what to do based on editor profile settings. And the filter would have to be able to do it safely.

RobLoach’s picture

Wicked rock awesome socks!

sinasalek’s picture

subscribed

naught101’s picture

subscribe