Script tags protection should not be hard-coded

[Alessandro]

Hello, I'm needing to have unprotected script tags in my document, they are of a special that is NOT "text/javascript" and actual browser will never execute, but CKEditor protects them anyway. The script tag protection is hardcoded in the htmldataprocessor plugin and there is no way of unprotecting it by removing that regex from protectedSource array.

I propose to explicitly add protection regexes in that array, allowing users to remove or change them depending on their needs.

In addition, explicit protection/un-protection methods shall be available (I'm not sure if this a legitimate request, as I only saw that protect* and unprotect* methods are not exposed by the plugin).

Thanks

[Frederico Caldeira Knabben]

Just to clarify... considering that the browser will not execute these scripts anyway, and they will be still available in the source view, as well on the editor output, what's the point about having them unprotected?

[Alessandro]

A plugin may need to modify and/or access to the original content of that tag. By the way, unprotecting script tags results in a blank line added at the beginning of the script every time the view is switched from WYSIWYG to Source. Also, the content of the script is modified (escaped, > < etc) by the editor, but I think it shouldn't. I don't know if I've to file other tickets for these issues (?).

[Frederico Caldeira Knabben]

The thing is that we may not have changes in this sense any time soon, as this is not a generic need. I would figure out other solutions in your situations.

Regarding the other issues, I'm not aware of tickets for them. Please feel free to open dedicated tickets for each one. Thanks!

[Alessandro]

Proposed patch: moving regexps to configuration

[Alessandro]

I'm dealing with new issues of this missing feature (without this, one shall work on protected comments manually, which I assume is worse).

My proposal is just to move these regular expressions in a global scope. This doesn't hurt the old code, and let the new code to use this feature.

The only issue with this patch is an eventual conflict with the configuration variable name.

[Piotrek Koszuliński]

I think that after 3 years we can close this issue. It is a very rare need and I would avoid adding new configuration option. Especially that it's possible now to revert data processor's protection using editor#toHtml and editor#toDataFormat events.