5411 Posts in 1648 Topics by 1187 members
Page: 1 2
|Go to End||Next >|
21 January 2010 at 6:40pm Last edited: 21 January 2010 6:43pm
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.
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...)
22 January 2010 at 4:03am
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.
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...
27 January 2010 at 10:51am
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.
27 January 2010 at 12:47pm
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.
21 February 2010 at 7:45pm
> 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.
22 February 2010 at 12:38am
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).
20 July 2010 at 2:38pm
@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.
26 July 2010 at 6:28pm
@banal: How config HTML Editor?
Page: 1 2
|Go to Top||Next >|