I posted previously about my desire for my HTML code to remain completely unaltered when I enter it through the SS CMS's raw HTML editor. I have to reimplement this functionality every time I upgrade (and have been unsuccessful so far with SS 2.4.0.) I understand that such a feature goes against SS's target audience's needs. Yes, this feature is also tasteless and vile, but it is exactly what I need. (I am the sole or primary editor for most of the SS sites I set up.)

I'm likely part of a very small minority, and wouldn't want to distract you from work that will help SS's main audience. However, I'd really appreciate any pointers you'd care to give me. My goal is to get my dream (nightmare?) feature up and running as easily as possible each time a new SS release comes out. There are several approaches that come to mind:

A) Hack the CMS code into submission each time a new release comes out (my current approach.)
B) Implement an additional TinyMCE toolbar button (possibly labeled RAW). Such a button would bring up a window with a text editor, whose text would remain unaltered after editing and while saving. Insert that button's code into the TinyMCE source files after installing the latest version of SS.
C) Create a module with it's own custom TinyMCE configuration and installation. Upon a new SS release, update my module, disable SS's default TinyMCE field, and replace it with the one from my module.
D) Replace TinyMCE with a plain text field.
E) Submit a feature request for the ability to easily disable all HTML-editor content alterations.
F) Submit a feature request for code comments to identify all functions that alter the HTML-editor's contents.

It's possible that some of these ideas make no sense from a technical standpoint. (My knowledge of SS CMS's or TinyMCE's implementation is very limited at present.)

Which of these approaches is likely to be most successful in the long term (and not just for the current version of SS)? Please mention the best approach or rank them in order. If there are other approaches worth looking into, please mention them as well. (I'd prefer to have the best of both worlds--WYSIWYG from TinyMCE but also full control over the raw HTML. But if I have to pick, I'd choose unaltered HTML over the WYSIWYG, and get the WYSIWYG elsewhere.)

Thanks in advance.

Hi domador,

Have you played around with the HtmlEditorConfig class yet?

Chances are it will allow you to achieve the majority (if not all) of what you require without any core hacks. It is responsible for creating and configuring profiles for the TinyMCE WYSIWYG editor, with full access to tinyMCE.init. I have set up very simplified configs and pretty much unrestricted configs for the editor which can be applied to user groups. Have a look at cms/_config.php to see how the default "cms" config is set up. I recommend adding new configs in your project's _config.php.

The key change you will want to make is removing the cleanup_callback. I am not aware of any other places where SS "sanitises" raw HTML (but take a look at HtmlEditorField and HTMLText just in case).

If that fails, I would recommend creating a replacement for HtmlEditorField and use this new class in your Page class (or decorate SiteTree) as the field type for the page content (i.e. getCMSFields). Either a new field that also uses TinyMCE or a TextareaField with just raw html.

I hope that does what you need, I'd be interested to hear how you get on.

Cheers,

Rich

Rich (@TotalNet),

Thank you for your reply. I performed a couple of changes to my SS configuration. In my site's _config.php file, I added the following line:

HtmlEditorConfig::get('cms')->setOption('extended_valid_elements', "*
");

(There is a left bracket - star - right bracket combination after the first star, but this forum does not display it for some reason. I've attached a screenshot showing what the code really looks like.)

It's pretty sloppy, but now many more HTML tags are left alone when I enter them from the HTML source editor.

I made the second change by commenting out line 32 of the cms/_config.php file:

//	'cleanup_callback' => "sapphiremce_cleanup",

This keeps the editor from removing HTML comments (and performing some other changes to which I'm indifferent.)

The HTML source is still being processed in other ways, some which I don't object to (such as turning <b> tags into <strong> tags.) However, there is also one process still in place which is very problematic. I tried entering the following sample code into the HTML source editor:

<script type="text/javascript"><!-- 
blah = 1; 
// --></script>

When I close the source editor and open it back up again, it's changed into this:

<script type="text/javascript">// <![CDATA[
 
blah = 1;
// ]]></script>

If I open and close the source editor several times, the code stays in its second form. However, after I save the page, and open up the source editor again, I see this:

<script type="text/javascript">// <![CDATA[
[CDATA[<![CDATA[// <![CDATA[
 
blah = 1;
// ]]]]]]<![CDATA[><![CDATA[><![CDATA[>]]]]<![CDATA[><![CDATA[>]]]]
// --&gt;]]></script>

If I repeat the process a third time, I find that the code has mutated even further:

<script type="text/javascript">// <![CDATA[
[CDATA[<![CDATA[// <![CDATA[
[CDATA[<![CDATA[// <![CDATA[
 
blah = 1;
// ]]]]]]<![CDATA[><![CDATA[><![CDATA[>]]]]<![CDATA[><![CDATA[>]]]]
// --&gt;
// ]]]]]]<![CDATA[><![CDATA[><![CDATA[>]]]]<![CDATA[><![CDATA[>]]]]
// --&gt;]]></script>

I suspect that TinyMCE itself is responsible for this change. It's the first time I run into this particular issue. However, it reflects my usual experience when upgrading SS--having to search for and follow several false leads until I finally get the source editor to leave the HTML source (mostly) undisturbed. This is why I am looking for a more productive long term approach for future SS upgrades. (I wouldn't mind fixing this CDATA issue in the meantime, though. But it'll probably take some digging around in TinyMCE.)

Andrés (@domador)

Andrés, I'm glad that helped.

If you want to save yourself effort each upgrade then you have to find a way around editing core files (including cms/_config.php) and there are many ways to do that; sub-classing, decorating etc. but this one is easy, instead of commenting-out lines in cms/_config.php use the following in mystite/_config.php

HtmlEditorConfig::get('cms')->setOption("cleanup_callback", "");

An even better approach would be to set up a completely new editor profile, basically copy the config from cms and replace ...get('cms')... with ...get('fulledit')... or similar title, and remove the options you don't want and it will use tinyMCE's defaults which gives you a starting point to work out whether it's tinyMCE altering your code or not. "fulledit" will then be available as an editor profile for security groups. (think you might want to change the "priority" option from memory)

That should be all you need to avoid making changes to core files and therefore ease the processes of keeping up-to-date with security releases.

As for the CDATA issue, there are a couple of ways to deal with this; get on the TinyMCE wiki and find out how to control the behaviour there or find another way of getting script tags into your page ... another page field perhaps.

Ultimately, if you want your html source left as is under all circumstances then ditch the wysiwyg editor, it will always try to be smart on your behalf which will often result in something you weren't in intending. This too can be done without hacking core files via getCMSFields() for a start.

If there are specific core hacks you have made then list them here, I think that's addressed all the hacks you've mentioned so far.

Rich

Rich,

I like the approaches you mentioned. It will take me some time to become acquainted with the SS and TinyMCE aspects you pointed out, but I'm sure they'll be very helpful once I do. I'll try to remember to submit a follow up post once I've followed the leads you gave me.

In my chronic frustration, I've often felt and sometimes expressed a desire for the editor to leave the HTML source unaltered. However, when I really think about it, I prefer a tradeoff rather than full control over the HTML. Of course, I'd personally prefer that tradeoff to happen closer to the technical side of things, giving up the aspects that protect non-technical users from messing up the underlying HTML.

I didn't make any other core file hacks other than the one I mentioned. I'll try to get things set up so that even these are unnecessary in my installation.

Thanks so much for your help!

Andrés