I think enabling client side filtering would work well with #242096: Expose filter configurations for editors
and as long as filtering is done on the server side too #294417: Disable client-side editor HTML filtering isn't necessary
The best user experience is gained when changes are made interactively, the user can see that what they copy-pasted has been reformatted.
Yes this needs to be double checked server side.
I hope to follow up this issue with a patch.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | tinymce_valid_elements-wysiwyg_2.0.patch | 4.44 KB | manuel.adan |
| #3 | tinymce_client_side_cleanup2.patch | 4.43 KB | seanburlington |
| #1 | tinymce_button_extended_valid_elements.patch | 2.1 KB | seanburlington |
Comments
Comment #1
seanburlington commentedThis patch builds on the one for #488506: Plugins that provide multiple buttons need seperate extended_valid_elements
It creates the list of valid elements from the buttons enabled and the block_formats allowed.
The effect is that the cleanup button now removes all formatting except that which could be created using the interface.
This allows easy restriction of input from copy-pasted text.
TODO:
Comment #2
sunLet me first say: Thanks for contributing! Always appreciated.
Unfortunately, though, this won't work out. TinyMCE is one editor that implements client-side filtering. However, there are many others that do not support that.
I am tinkering about this since a long time already. We need a solution that works for all editors. And we most likely need to support dynamic filtering when an input format is changed (and the editor changes). Further, this probably needs to be configurable in some way - but we don't want to knock users off with a configuration form like http://drupal.org/project/wysiwyg_filter. And last but not least, most of the validation/filtering configuration should happen automatically, either based on enabled input filters in an input format, or vice versa, input filters are auto-configured based on required markup for editor functions (whereas the latter is probably very insecure).
That is a monster challenge, which might even require changes in Drupal core.
I am not sure if we should, but I would be happy if we could merge #488506: Plugins that provide multiple buttons need seperate extended_valid_elements into this issue. Note that I'm not (yet) sure whether that makes sense. Perhaps, we should merge both into #242096: Expose filter configurations for editors. It is hard to understand the bigger picture.
Comment #3
seanburlington commentedThanks for the response :-)
I am often puzzled by Drupal's lowest common denominator approach - and here I don't understand why we can't use a feature of an editor just because it isn't available somewhere else. This does seem to make Drupal development a monumental challenge - not just in technical terms - but in motivation. A lot of work can get done if everyone can "scratch their own itch".
I'm not sure if I've explained properly what this patch does - it does provide dynamic filtering that is responsive to the options the user has configured - and so far I haven't had to extend the user interface. If I did extend it - this would probably only be to add an option "use these settings for text cleanup?"
I completely agree that the next level up would be server side sanitisation to match - and this patch could be taken as a step in that direction - after all it does build a list of allowed elements/attributes on the back end.
New patch with bugfix:
Comment #4
sunLet me point out again that I really appreciate each and every patch.
To answer your question: This is the Wysiwyg API project. We are trying to standardize the way Drupal "talks" to client-side editors. The module was based on the former tinymce.module, which is the only reason why that "extended_valid_elements" key exists at all. It is a TinyMCE-specific property, which no other editor understands. To recap: the goal of this project is to provide an API that works for all editors.
This means, the goal and intention is the opposite of this patch: Instead of introducing another specialty, we need to work on the opposite, removing specialties and make them work for all editors. That is, because Wysiwyg API allows all Drupal modules to implement so-called "Drupal plugins", without even knowing of the editor that is currently attached. I know that this will sound embarrassing to you - but like some other issues in the queue (advanced editor settings, sorting buttons), we want to implement a proper solution instead of supporting one editor more than another.
The most negative part on this issue is probably that there is no valid, proper solution - not even a nifty idea - to the overall issue at all. We are slowly getting a bigger picture of that, but it still needs some time to get a proper idea. Proposals are always welcome, of course.
We need more people that understand Drupal core's APIs as well as all possible client-side editors to get this done. And we are only two very busy developers ("two" since "yesterday", see #487000: Craziness!). Will you participate?
Comment #5
seanburlington commentedHi Sun,
I'm afraid this feature is a requirement for my current project and as it clearly isn't going to become a feature of the WYSIWYG API I won't be able to contribute to the API as part of my work.
I'll investigate the tinymce module, or maybe write a custom module.
While we obviously have a fundamental disagreement about approach, I do applaud your hard work and contribution.
Comment #6
manuel.adanHi there,
I didn't find out another way to using (extended_)valid_elements from TinyMCE editor in drupal but patching. May be other people in the same situation, so I made a review in seanburlington patch for the 2.0 version of wysiwyg module.
After a few days searching for client side body content filtering, that's the most reliable option I found. I tried Wysiwyg cleaner, but it does not catch "paste event", and depends on jQuery 1.3, still in dev status for drupal 6.x.