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?
Comment | File | Size | Author |
---|---|---|---|
wysiwyg_support.patch | 2.6 KB | recidive |
Comments
Comment #1
recidive CreditAttribution: recidive commentedOops. Needs review.
Comment #2
sunJust tracking.
Comment #3
maartenvg CreditAttribution: maartenvg commentedNo longer applies.
Comment #4
sunI'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.
Comment #5
sunMoving over to Wysiwyg API.
Comment #6
markus_petrux CreditAttribution: markus_petrux commentedOh, 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.
Comment #7
RobLoachWicked rock awesome socks!
Comment #8
sinasalek CreditAttribution: sinasalek commentedsubscribed
Comment #9
naught101 CreditAttribution: naught101 commentedsubscribe