WYSIWYG is the best Symfony friend

I’m sure if you allow visitors to submit any content on your site you use WYSIWYG in your project. Not much of them knows HTML so you have somehow to simplify their lives. Of course, you can go with built-in TinyMCE but we dont really like it. There is also easy way to use FCKEditor (for those who still did not know how to do that here is explanation:

So here are list of WYSIWYGs you can use with Symfony right now:

TinyMCE – built-in symfony
FCKEditor – built-in symfony
The WYSIWYM Markdown Editor

There were mentioned on symfony forum that someone developed plugins for

SPAWS Xinha (htmlarea successor)

but we’ve never seen them.

We would also want to mention here about usefull plugin you may want to use along with WYSIWYG:

We vote 2 hands for FCKEditor, it’s quickly developing and powerfull. The disadvantage – you have to buy license if you use it for commercial purposes. The other important thing is supporting of plugins by FCKEditor. If you would take a look into this page you can see detailed instruction on how to create plugins:

and here is big list of existing plugins and comments to them:|FCKeditor’s

We also reffer you to forum post regard using of WYSIWYGs:

Do you know any other good WYSIWYGs? We open our ears and listen up 🙂

5 replies on “WYSIWYG is the best Symfony friend”

My main problem with offering such plugins to users is security. How do you secure your HTML from XSS and other security risks?

Does sfValidatorHtmlPlugin also do security checks or does it just do validity checks. The information in their README is not clear enough to know.

the Markup one seems the most secure to me, as you can always control how the markup is generated so the actual HTML is yours, not the user’s.

I were in love with FCKEditor over TinyMCE. However, when it comes to ajax, FCKEditor became a pain in the neck which cause me lots of struggles. TinyMCE is now my flavor.

I am the author of sfWmdPlugin and I use the plugin with a Sanitizable Doctrine behavior that attaches a listener to each model that it acts on.
The listener strips all HTML tags from the string fields before any save or update query on those models.
The result is that only the markdown text is saved to the DB for security.
The problem is that markdown is not very rich for display, so when I know a field is only used by trusted users, I can set an Ignore option so that HTML can be saved with markdown.
Since HTML can be embedded in markdown, this makes for nicer pages written by admins.

The problem other than security that I found with editors based on HTML is that when used by people who know nothing or little about HTML, these people can enter malformed HTML or click on buttons multiple times and that may not render at all what they expect or worst, affects the whole document.
Then, they call you to fix their mess, which is sometimes not fun at all.

This is why I went to markdown.

Leave a Reply

Your email address will not be published. Required fields are marked *