I am considering the idea of creating a module that would work with WYSIWYG filter and the WYSIWYG API module by pulling the API configuration for a format and automatically setting the correct options for a WYSIWYG filter.

I spoke to sun on IRC and he says it is feasible and agrees that that WYSIWYG filter already does most of the work. I think the feature would probably be best as a seperate module providing a seperate filter that would be like "Auto-config WYSIWYG filter" or something. That way the code for this would only be loaded if the user is using the WYSYWYG API and wants its features. Plus they would be agreeing to the automatic configuration which could be allowing items unknown to them.

I am willing to make at least a first draft towards accomplishing this. My questions are:

  • Are you interested in this idea?
  • How feasible do you see this?
  • Do you think that it would be more appropriate as a submodule of WYSIWYG Filter or should I make a completely seperate module?

Comments

markus_petrux’s picture

markus_petrux commented

In fact, this is something I had on my todo list. I created this module for a big project I'm involved, and while I work on other stuff, I was waiting for the WYSIWYG API to mature a bit more. At the moment I finished this module there was no clear method yet to pass the allowed elements list (and other settings) to editors. I believe I talked about this here: http://groups.drupal.org/node/15979

I'm still busy. The project I'm working on may take a year, so I had time to approach this until we really needed.

That being said, I'm fine if you wish to do it. I can try to help you in whatever direction you wish to take, as far as it's possible to take advange of the settings defined by this filter to customize the editor. :)

It could be a separate module, a submodule of this one, or just something that could be integrated here, which is what I had in mind initially.

It shouldn't be difficult, specially integrating with TinyMCE 'cause this is the format we're using here. It might be necessary some kind of conversions for other editors though. We need a somehow plugable bridge to join both worlds.

Or it might be interesting to provide a method to autoconfigure the input filter based on the features enabled in the editor.

There's another thing that I'm not sure it's obvious, is that this module contains a hardcoded backlist of elements, which could be used to setup the TinyMCE option invalid_elements. It's hardcoded because if someone needs one of these, then it can probably have access to the Full HTML input format.

dragonwize’s picture

dragonwize commented

Thanks for the link. I've read through the conversations listed in all the talks in g.d.o and the issue queue now. There is, however, one very big difference in what I am proposing than what I have read so far.

I am proposing configuring Drupal via the wysiwyg editors (indirectly because there API in between) instead of configuring the editors with the Drupal filters. More description: http://groups.drupal.org/node/15996#comment-61015

That seems to be a much better solution that what I am reading being proposed. What are your thoughts?

markus_petrux’s picture

markus_petrux commented

I believe that if you configure the input formats from the editor, then it might happen that a security hole is opened and that could happen silently. For example, an editor may try to enable the onmouseover attribute, but you don't really wish that.

Though, I agree it would be easier for the user to just concentrate on editor features, and that the system could configure the input format automatically, but... it should be secure too. Also, it might be complex to know what the editor needs to touch in the input format for each one of its features (and there are a lot of different editors / input filters outthere). So I'm not sure which is the ideal solution. Maybe just one that can really be done as close as possible to the ideal solution.

Anyway, I'm busy with other things, so I would not be able to work on this right now, though I would be happy to help or review any patches that you may consider for the WYSIWYG Filter module.

markus_petrux’s picture

markus_petrux commented

Related issue in the Wysiwyg API queue: #242096: Expose filter configurations for editors

markus_petrux’s picture

markus_petrux commented
Status: Active » Closed (fixed)

Well, I'm following the evolution of the Wysiwyg API, so I'll be adding here anything that the API supports to integrate both worlds better than what we can do today.

Please, feel free to reopen if you wish to add more feedback. Thanks.

DrewMathers’s picture

DrewMathers commented
Status: Closed (fixed) » Active

markus_petrux,

How about reviving this idea as a feature within the WYSIWYG Filter module rather than a separate module?

markus_petrux’s picture

markus_petrux commented
Status: Active » Closed (fixed)

I do not have the time for this. So, better re-open if/when someone has the time to work on this. I think though that the first thing to approach is mostly a job for the Wysiwyg API to be able to generate information that can then be passed to input filters (there are several filters involved: Wysiwyg Filter, HTML Purifier, htmLawed, ...).