Best WordPress WYSIWYG Editor

When I explained how NicEdit has become my personal best WordPress WYSIWYG editor, I mentioned some issues.

Whilst the best solution would be to delve into the NicEdit code, and change the parts that present problems, I have found workarounds that mean I can get by without this for now.

In fact, I am not certain if this is truly a NicEdit issue, or the way WordPress builds it’s comments forms. I’ll leave the strict coding debate until I’ve fully investigated why it works in FireFox but not in MicroSoft Internet Explorer (MSIE).

In my first investigation I explained how wrapping elements in HTML Paragraph tags will break NicEdit under MSIE. The symptom is a small disabled NicEdit toolbar that renders it useless. I explained in that article about modifying the comments.php to remove the paragraph tags (or change them to DIV tags) re-enabled NicEdit. However, WordPress 3 has changed the way the comments form is built.

The good news is that there is no need to hack the WordPress core that serves the form. All that is needed is a simple change to the way the comments form is called in your theme.

Restore NicEdit As Your MSIE WordPress WYSIWYG Editor

If you are using a pre-WordPress 3 theme, your comments form is built directly in comments.php. Current themes replace many lines of code with a simple call to a new function – comment_form().

This is much tidier, but the default settings are very NicEdit unfriendly. Not only does it retain the MSIE-breaking paragraph tags, but default width settings do not get passed to MSIE at the toolbar rendering stage.

Additionally, the default form displays the allowed HTML tags. This is something very dear to my heart in a normal comments textarea. Visitors should be told which tags are allowed to save those frustrating times when you type a long and interesting comment, only to see it posted as garbled rubbish because the pre or code tags are not allowed. With NicEdit, such vital information is unnecessary, as the tags are all processed before the code is saved, and you can even configure which buttons are available.

So how do we get the comments form to display NicEdit properly?

The call to comment_form() is near the end of comments.php in the theme editor area. If you are not happy with editing themes, get in touch with the theme author and ask them to add comment form parameters in the theme options. Or if the theme is not supported, then let me know, and I’ll produce a NicEdit enabled version of it.

If you cannot find comment_form() then chances are that you have an older theme, in which case search for the textarea line, and adapt the following.

The comment_form() function allows most aspects of the comment form to be changed by passing an array of parameters. More details are in the WordPress codex, but all you need to do is paste the following between the brackets() of the comment_form function:

array('comment_field'=>'<div class="comment-form-comment"><label for="comment">' . _x( 'Comment', 'noun' ) . '</label><textarea id="comment" name="comment" style="width:350px" rows="8" aria-required="true"></textarea></div>','comment_notes_after'  => 'Thank you.')

This simply changes 2 settings, comment_field and comment_notes_after by slightly changing the default WordPress code. I’ve cheated a little by including an inline style statement – my site is about getting things done quickly, and then we can argue with the purists to find more elegantly coded solutions. The important thing is that the following 3 NicEdit defeating issues are overcome:

  1. p is replaced with div to prevent MSIE “Unknown runtime error Line: 8 Char: 721”
  2. cols=”45″ is replaced with a width setting. Alternatively, you could probably set this in the style sheet, but I have not tested this.
  3. The allowed tags are replaced with a simple ‘Thank you’ message. You could change this to something else, or just the quotes to remove it entirely.

Change Defaults To Make NicEdit Your Best WordPress WYSIWYG Editor

In my previous article I explained the quick way to enable NicEdit to be your editor for WordPress comments or Question2Answer questions, answers and comments. Posting the default code certainly works, but you are at risk of losing the editor if the NicEdit site is unavailable.

The first thing you should do is copy NicEdit to your own server, and amend the first NicEdit line in your header.php to:

<script src="path-to-your-nicedit/nicEdit.js" type="text/javascript"></script>

If you like to keep images in a separate folder from js files, you will also need to change the NicEdit defaults. You will probably need to do this anyway to change the default buttons and add extra features. So, amend the second NicEdit line to:

<script type="text/javascript">bkLib.onDomLoaded(function() {nicEditors.allTextAreas({iconsPath : 'path-to-your-nicedit/nicEditorIcons.gif'})});</script>

In this instance we are only changing the iconsPath, but any nicEdit parameters can be amended in a comma separated list.

If you’ve implemented these improvements and still have unresolved issues, please let me know below. As I mentioned earlier, I will soon publish complete step-by-step guides for NicEdit enabling Question2Answer and WordPress, combined and in isolation. I’d appreciate your help in making it as complete as possible by clarifying any issues you may still have.

5 thoughts on “Best WordPress WYSIWYG Editor

  1. vince jelenic

    thanks. a bunch.
    don’t have time right now. have bookmarked, will come back to view again. right now fixing some “minor” html bugs for IE first.

    Seems it might work if I get a few kinks outta the old html.
    strange, though, Pretty-Comments using the jquery wysiwyg library had no problem.

    Thanks.

    1. Keith from shrewdies

      Strange indeed vince, and the debugging tools in modern browsers hint at reasons why.

      When you view the source in a debugging tool (F12 for MSIE, Right-click – Inspect element for Firefox & Chrome) you see 2 completely different approaches.

      I used these tools to see that NicEdit was getting fooled by the way browsers handle property inheritance on nested elements. Now this is so far out of my comfort zone that I’m not even sure that the terminology that I’ve used is correct. What I mean is that NicEdit wraps each textarea in DIV tags but as these must be compiled prior to the textarea being displayed it has to calculate the expected width. Something is going wrong with this calculation in MSIE, but debugging it means delving into the NicEdit code, so my shortcut is to force the width.

      That approach is the equivalent of nailing a leg back onto one of your antiques. I can get away with it because the visitor on most of my sites has absolutely no concept of the value of ‘correct’ approaches to coding a website. As long as the website performs, it does not matter how it is built. As long as a table holds my dinner 200 year old hand carved tenon joints have no value! 😉

      I can see that Pretty-Comments takes a completely different approach. It hides the original textarea (display:none) and builds its own iframe to present and control the WYSIWYG input.

  2. vince jelenic

    Hey, Keith.
    I didn’t get a chance to try your implementation.

    I found a thread in the WordPress forums at this address
    http://wordpress.org/support/topic/plugin-front-end-editor-text-area-become-very-narrow

    I grabbed the “development version” noted there.
    I’m using it now. it works nicely.

    1. I had to clean up my older html code anyways… so I hunkered down and filtered out all deprecated calls and got rid of a few hanging tags.

    2. I downloaded the Front End Editor, as noted above.
    3. I used the nicedit.dev.js from that package and placed it on my server.
    4. I then proceeded to point to my server location as you recommend.
    5. I like your solution for fixing the “icons” pointer… I saw that too late, as I just changed the location in the javascript file itself.
    6. now working like a charm with IE8 (help, haven’t tested 7, just dumped it the other day, hope it works).

    This without any changes to the template files , or modified calls to functions.

    In MY case, there were two problems. the javascript which required fixing… and the “unclean” html code in the files.
    (example, a hanging tag with no opener seemed to hang IE altogether from rendering a page properly. )

    sigh… working nicely now.
    ps. I do like the way Pretty-comments renders within it’s own iframe, but I really NEEDED the added image upload nicedit supplies with imageshack. (mine is a highly visual biz).

    And thanks for the notes…. So I guess I beat you to implementing it already?

    That was the last piece for our website we needed done right now, so it’s off the races of listing stuff for sale again.
    cheers.
    Vince.

    1. Keith from shrewdies

      I’m glad it worked OK. I find it interesting that the NicEdit fix comes from the Front End Editor developer. That plugin started me on NicEdit, and I’m pondering if I should return to it when I get shrewdies Interactive running.

      Though you certainly beat me to implementing it on shrewdies, I new that it worked from my implementation on a couple of live sites. But unless you are suffering from gout, or getting married in the UK, you are not likely to be interested.

      vince, it’s refreshing to correspond with someone who actually uses a website for real business, rather than those who push Internet marketing, or blind me with technical convolutions. Good to learn that your website is ready for action.

  3. vince jelenic

    Keith, I must thank you for helping me implement it, even if in an indirect way. It’s been a pleasure meeting here.

    Your explanation of the wraps around nicEdit became the moment when I put together some previous readings with my problems and got an eureka moment.

    I had already tried the FEEditor “fixed” js file before…. and still no go.. So I noted your comments and thoroughly checked and validated the html on our site. Sure enough the problem was created by interplay of nicEdit js and our theme format.

    I had been in the process of moving to style sheets from 6 year old html at the same time. After reading your notes, I decided time to clean up our databases (it generates our product listings automatically) to current stylesheets formatting, and voila — after many “validations” later, got a working version of nicEdit, and a much more stable website for IE than before.

    Our problem was caused by the CONTENT we were inputting (in the guise of posts). Silly me, after all the checking I did on the templates end, it turned out to be what I thought as the least likely source. argggghhhh..
    So we tackled theme, nicEdit js fix, and content cleanup.

    All in a day’s work for a busy antiques shop owner, no?

    See ya next time I have to change theme. — although that will likely never happen, as we’ve torn apart a canned theme down to it being a simple framework for our customizations.
    About 95% of the site functionality is actually hidden from public and it would be no simple matter to “switch theme” anytime soon. We’ll just consider it a php framework within wordpress engine from here in.

    cheers.
    Vince.

Leave a Reply