I love the SilverStripe CMS. However, I periodically get frustrated with one aspect, one involving the TinyMCE-based page editor's default configuration. Each time I upgrade, I have to hack the editor's configuration so it doesn't strip out certain HTML tags after using the HTML-source editor. I often spend a couple of hours searching for my hack in the previous SS installation's source. Sometimes the old hack works. Sometimes it doesn't and I have to search for the same SS forum postings that helped me the last time. I am convinced that hobbling TinyMCE in this way is unnecessary and counterproductive for several reasons:

1) TinyMCE is less prone to abuse within SilverStripe: I could understand the rationale for having TinyMCE strip out certain HTML tags when used in the context of a blog's reply functionality or a forum's posting functionality. It's wise to keep random miscreants from injecting code and XSS exploits into a blog, even at the cost of decreased functionality for others. However, in SilverStripe's case, TinyMCE is used internally, by website content managers who probably have a direct interest in their content's safety. There isn't that much need, from a security standpoint, to limit what these users can do. Such users would have to go out of their way to do something harmful through the source editor.

2) Tag-stripping irritates power users: When the WYSIWYG part of the editor proves inadequate, it's nice to drop into the HTML-source editor and write exactly what you want. Except when SilverStripe strips it out! Maybe my embedding of Javascript within an article is questionable, and the need of a hack to enable it is reasonable. But I realized things had gone too far when SilverStripe 2.3.4 turned out to strip HTML-form-related tags from pages that need plain-old HTML forms. C'mon! Stripping out <form> and <input> tags? <ridiculous>This is</ridiculous>!

3) Tag-stripping is irrelevant to regular users: I applaud the SilverStripe philosophy of focusing on the CMS editor's usability for non-programmers. I understand that such a CMS editor may omit some features that technical users would like. However, the HTML-source editor is strictly a power-user feature, not a regular-user feature. Whether HTML tags are stripped out from HTML source should be irrelevant to regular users. If such users use the HTML-source editor, it must mean the WYSIWYG editor is very inadequate, that they are curious to see what the HTML button does, or that a Power User has emerged from its cocoon.

If there are good reasons for crippling the HTML-source editor, I'd like to know them. Otherwise, I hope to see future SilverStripe versions that ship with an uncrippled source editor, ready for power users right out of the box. Some existing niceties should be kept (such as transforming <b>s into <strong>s and <i>s into <em>s) but the stripping of other HTML tags (and HTML comments) should cease. I look forward to being able to easily shoot myself in the foot in the future. (Maybe it's time to take that old programmers' joke and make an HTML/WYSIWYG-editor version...)

The editor stripping out tags has never been an issue for me. Personally, I like that behavior because of the following reasons:
1) My clients are not "power users" as you describe them. I usually strip out a lot of the Editor-Buttons (using the HtmlEditorConfig class) for every website to match the clients needs.
2) I don't want my clients to be able to insert some random code they find on the internet. Doing so might break all JavaScript functionality for a page. Heck, it might even be a security risk.
3) Things that aren't meant to be edited in a WYSIWYG Editor shouldn't be allowed. Since HTML Forms and JavaScript can not be (visually) edited in TinyMCE, there's no reason to have them in there. Imagine somebody places some clever JS Code in there, and another editor deletes the Paragraph that holds the script?
4) So far I didn't encounter any scenario that would have required some additional tags in the Editor. I prefer to provide special page-types for the different use-cases instead of a "one-page-fits-all" approach. For special content inside the Editor you could always use a custom TextParser or a "Placeholder-Variable" (as the Userforms module does).

If it's possible to have these things easily configurable via _config.php or similar, I'm all for it. If not, I'd rather stick with the old behavior. Since the Editor is actually just a Form-Field, somebody could also write a module that adds a new WYSIWYG Editor (for the power users) to the CMS. I wonder why this hasn't been done before...

Banal,

Thanks for your reply. I agree that allowing unlimited raw-HTML-code insertion is a security risk. However, it also happens to be a very useful feature, one that is unfortunately lost by erring on the side of caution in the editor’s default configuration. Maybe most SS users are like your clients, and such a default configuration makes sense. However, like you said, it’d be great if it could be enabled or disabled very easily. (Like I said before, I’m tired of not being consistently successful when trying to disable the tag-stripping behavior after each SS upgrade. It'd be great if the option to disable it already came as part of the SS package.)

I’m curious about your clients’ use of the HTML source editor. If everything should be editable from the WYSIWYG editor, then why have a source editor at all? Why not go all the way and completely remove the HTML button on your clients’ sites? It still seems to me like the HTML editor is meant precisely for those situations where certain things can’t be viewed or edited through the WYSIWYG editor. As such, it would remain a tool for power users (i.e. those who know what they’re doing with their HTML code, and should be allowed to do it.) In any case, I’d be very interested in finding out what your clients use the HTML source editor for, if you’re at liberty to write about it.

I work with enterprise class CMS as my day job (Content Manager) and our editor strips out most HTML/JS/CSS code. This is done for security, stability/integrity, and consistency reasons. Allowing such things as forms in the editor, custom styles, javascript can cause huge problems. These type of things belong in more robust layer that can be tested and controlled. Just because I can do something doesn't mean that I should.

In a small scale environment when the developer is in charge of everthing it is often easier/cheaper to just plug things into the editor rather than do it properly.

I use the HTML editor to overcome the problems with our editor. It will add paragraphs and linebreak at strange places and formats the code poorly at times. It saves me alot of time by not having to fight too much with the editors limitations. In a previous job I edited content in dreamweaver and inserted this into the HTML editor.

> I often spend a couple of hours searching for my hack in the previous SS installation's source.

I think what you experience is more of a code management problem - I find it helpful to clearly mark any core hacks (e.g. // MODIFIED <author> <date>). That being said, its almost always a bad idea to alter core files. Have you looked at HTMLEditorConfig? You can tell TinyMCE which tags to allow. But I agree with banal, allowing <form> <input> <script> doesn't make sense for 95% of SilverStripe backend users.

Hmm seems like I missed some posts here.

@domador My clients don't use the source editor, I don't even enable it. Sometimes it happens that the client asks for more functionality. Then I just enable the appropriate plugin and buttons (say for tables) or implement some custom functionality for them.
Take this page as an example: http://www.grandpalais.ch
I attached a screenshot of the editor to this post. As you can see, it's stripped down to what they need. And certainly no source editor ;)

In recent releases of SilverStripe you can even specify Editor configs per User-Group, which is a great way to put the power of the source-editor into the hands of power-users only.

Still I'm all for a CMS that puts the liberty to customize it into the hand of the user/developer. Since you can implement your own Form fields, I guess it would technically be possible to implement your own Editor of choice (with full control over its behavior).

@Ingo: This is a very belated reply, but I did want to thank you for the lead on HTMLEditorConfig. Unfortunately, that is only part of the potential solution. I've found that I always need to go in and comment out code that removes HTML comments or performs other changes that are undesirable to me. My current nemesis are the CDATA sections that some code someplace inserts in place of certain HTML comments.

@Ingo, @banal, and @Greg1, thank you for your replies. I'm going to try and approach this issue from another angle, on a different post.

@banal: How config HTML Editor?