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.

I’ve switched between NicEdit and TinyMCE for a few months. I like the simplicity of NicEdit, and had it working nicely on WordPress sites.

Then all sorts of weirdness started happening when I tried the beta of Q2A on a development site. I’d taken what I thought were sensible precautions. The site in question was new and had no visitors. I prefer to experiment with this sort of site if possible, as running development sites under localhost on my PC is not always a good representation of the real world. I had an absolute nightmare with this, and suspected all the new stuff I was trying out (beta Q2A and beta WordPress 3.0!)

Turned out it was nothing to do with the beta software, and everything to do with lousy server configuration backed up by lousy tech support from Bl** Host.

In the process of trying to get back to something that worked, I tried different settings on this site. I didn’t realize that I’d left WYSIWYG turned off here until vince told me.

For now, I’ve left tinyMCE alone. It looked like a good solution, but there are a whole bunch of formatting issues, so I’ve decided to focus on NicEdit.

I use it to make WordPress commenting better, and for Q2A. Within those setups (either of Q2A, WP, or both) there are installation and configuration options, so I’ll try to cover all the permutations.

Preparing Q2A

Q2A strips out any html code from multi-line text, so we have to tweak it. If you are uncomfortable with tweaking code, raise the issue on the Q2A site, and ask for an Admin option to disable it.

We have to edit the qa_html() function in qa-base.php, which sits in the qa-include folder. At line 84, I simply comment out the string manipulation, and set the return value to the string that was passed in:
if ($multiline) {
// $html=preg_replace('/\r\n?/', "\n", $html);
// $html=preg_replace('/(?<=\s) /', ' ', $html);
// $html=str_replace("\t", '    ', $html);
// $html=nl2br($html);
$html=$string;
}


If you do not do this, NicEdit will still work, but the HTML tags will get stripped before your questions, answers, or comments get saved.

This change will need to be reapplied whenever you upgrade or reinstall Q2A.

WYSIWYG Question2Answer

The simplest implementation is to copy the from NicEdit front page:

<script src="http://js.nicedit.com/nicEdit-latest.js" type="text/javascript"></script>
<script type="text/javascript">bkLib.onDomLoaded(nicEditors.allTextAreas);</script>

Then paste it into the Question2Answer Admin area. All you do is go to the Layout settings, and paste the above code into the 'Custom HTML in <HEAD> section of every page:' and save the settings.

You should see that all your multi-line text boxes have a WYSIWYG display with edit buttons across the top. The buttons are disabled until you click into the textarea.

Now check that NicEdit works OK on your question, answer and comment boxes. The easiest way is to edit existing items.

This has worked successfully every time I have tried it, but there may be some formatting issues on some browsers. I will cover these in my next article.

WordPress Default WYSIWYG Editor

For most of my sites, I want both WYSIWYG for Question2Answer and for WordPress. I always wrap my Q2A theme inside the WordPress theme, so it makes sense to apply NicEdit to the WordPress header. In this setup, you do not have to also apply it to NicEdit, unless you want different editor configurations in each area.

So to make NicEdit the WordPress Default WYSIWYG Editor and also apply it to Question2Answer, simply post the NicEdit code into header.php within the HEAD tags. This also applies if you just use WordPress without Question2Answer.

Test your comments both at the article level, and (if you use threaded comments) the reply to comment level. NicEdit should work nicely, but there may be issues in some browsers. You really need to try as many browsers as possible, but certainly common ones that your visitors use. See your server logs or analytics program - Google Analytics is very good - to get a list of browsers that your visitors use.

In my next article, I will look at some of the issues that WordPress themes can cause, especially with MSIE. I'll explain how to overcome these issues, and approaches to investigating problems. I will also explain how to avoid the pitfalls associated with simply pasting the NicEdit code from their site. You will see how to create the best WordPress WYSIWYG editor.

You might notice that I do not use the NicEdit/WordPress default WYSIWYG editor that I have described on this site. That is because I intend to move all the interactive features to a separate site, and add more discussion and feedback tools. When I've done that, I will produce a complete step-by-step guide for integrating NicEdit and Question2Answer under a WordPress theme.

Let me know if you want to see it in action before you commit to these changes, and I will show you sites where it works so that you can see the improved front end.

There is no WordPress plugin to touch it, and the alternatives are simply too cumbersome to integrate.

For most needs, Simple:Press forum provides all that you need, but I’ve also mentioned before that it is not as simple to administer as some – but only because it has a wealth of options. And under the lid, tweaking the code is not particularly easy – again because there is so much included that it can be hard to find exactly what you want to change.

Mechanics aside, I have been trying for months to develop a simpler alternative built on posts and comments. This is not the most difficult coding challenge, but it is time-consuming, and there always seems something more important to do. Whilst doing the more important things, I noticed that Pods CMS has recently changed there forum for a completely different, simpler interface.

Looking deeper, I saw that it was based on Stack Overflow. Similar, in some ways, to Yahoo Answers, this approach means that we can focus on answering questions. This is a bit of an eye-opener for me, and I realize that promoting a forum to answer questions and share experiences and opinions is asking too much for one application.

I’ve decided to split my forum into a Question And Answer Section and a Discussion Forum. In an ideal world, these would be linked, and it would be absolutely possible to build such a beast with Pods CMS. But the time to build this from scratch means I’d rather look for something usable now, and seek better integration later.

The key here is to find something usable that is easily integrated into WordPress.

Step forward Question2Answer.

I’ve installed it on own of my sites, and I’ll report back on the details later. I’ve no intention to import questions from Simple:Press Forum, as I believe the two applications can work side by side. There will probably be a few more integration issues, but installation of Question2Answer using the WordPress user records was surprisingly easy.

Rather than repeat it here, I’ll refer you to my Question2Answer WordPress installation notes on the author’s support site.

For manual installers, it is set and forget. For automatic installers (SimpleScripts or Fantastico) it is often quite invisible.

Unless something unexpected changes, WordPress 3 adds little different to the way wp-config.php works, so it is still vital to learn a couple of tweaks.

wp-config.php is well documented internally, and the installation instructions tell you what you need to change to make sure that your WordPress installation can see the database.

But, there are two situations that commonly occur in a standard WordPress installation that are far from ideal: memory exhausted messages and excessive page and post revisions.

WordPress Memory Problems

I have mentioned memory problems with WordPress before. Though I only experienced it when upgrading with large plugins like Simple:Press Forum installed, I suspect this can also happen during normal running of some large plugins. Pods CMS has an error report, but as it looks to be a one-off, it could well be due to some other problem.

When I first experienced this problem, I used the temporary solution of de-activating large plugins during the upgrade. However, I later found the permanent solution to be an amendment to wp-config.php, as I noted on the original post, and repeat below.

Excessive WordPress Revisions

When WordPress introduced automatic saving of posts with revisions, it looked perfect for undecided people like myself. Changed a post only to realize you prefer an earlier version? No problem with WordPress, as the default installation settings give you a more or less complete revision history. But this can cause a problem if you frequently revise many posts and pages. Not only can you end up with a massive list of revisions on the edit page, but your database is becoming increasingly cluttered with copy upon copy of the same text – an absolute nightmare if you ever need to directly search or edit the database.

Many people hate the whole idea of revisions, and turn the feature off. I like to keep some recent versions, so I set the number to 3. Whichever you choose, you need to include a step in your installation routine to change the default setting by amending wp-config.php.

wp-config.php Changes

All you need to do is add the following two lines to wp-config.php. It shouldn’t matter where you put them, but for convenience I add them before the line that includes “stop editing”.
define('WP_MEMORY_LIMIT', '64M');
define('WP_POST_REVISIONS', 3);

I wouldn’t normally use a beta version on a production website, but the full release will be available before that site is fully live, giving me a chance to test some new features.

Site installation continues to be simple, and I took the simplest option of using the automatic script provided by my server host. This has the nice option of changing the default admin username to something less guessable – always a good idea for improved security.

WordPress Settings

Settings are the same as version 2, so I made the usual adjustments:

General Settings

Tagline and Email. I also ticked the membership so anyone can register, but it would be better to leave this until you get the membership plugins organized (more on this soon).

Discussion Settings

Enabled threaded comments, with depth set to the maximum of 10. Set moderation to hold comment if 1 link. More on discussion settings when someone asks for it.

Privacy Settings

Always a good idea to make sure your site is visible. If you can think of a situation where you would set it to block search engines, please tell me.

Permalink Settings

Vital to select the Custom Structure and change it to /%post_id%/%postname%/ (we can discuss why this is so if you like). I usually change the category and tag base to something more site specific – there might be a slight search engine advantage, but I just think it looks better.

Other WordPress Configuration

It really should be categories and plugins next, but I could not resist investigating the new default template – Twenty Ten (surely not a tribute to Windows Ninety Five?). This seems to be a great improvement, but I have yet to find a WordPress theme that does not need a quick makeover with the editor. I think the essentials of WordPress themes needs a separate topic, so I’ll do one soon.

There also used to be essential modifications to wp-config.php. I’ll check this, and report back tomorrow.

You seem disappointed that the next version is where the real promotion potential lies, but the good news is that you do not need to wait.

If you have downloaded and activated Happiness Today, then you already have a tool for displaying random (or selected) promotion messages in your WordPress posts, pages or sidebar.

The main appeal of Pods is the way it makes extending the WordPress database so easy. But stored data is of little use if you cannot present it to your visitors. My first release of Happiness Today was just to prove that, like Hello Dolly does for standard WordPress, it is very easy to build a basic plugin. That basic plugin instantly demonstrates how Pods stores and displays data. In keeping with the Hello Dolly tradition, I displayed random lyrics in the Admin area – but the real life potential was always to be able to produce something simple yet useful, that can display random promotion messages to visitors.

Those promotional features are included in the current release, just not obvious. Here’s how to use Pods inbuilt features to get more from the Happiness Today plugin. Start your marketing campaign now.

WordPress Pods Presentation Features

In the plugin, I present the messages via a Pods template that is called whenever an admin page loads. That template adds formatting to match the admin color scheme, and configurable link buttons. I also present the full set of lyrics on the happiness_today information page using a very simple template that adds nothing but a line break.

Pods output is not restricted to templates that can be as simple or as complex as you need them. Neither is it restricted to Pods pages such as the example mentioned, where you can build a page similar to a WordPress page, but with easy access to your data. You can also include Pods output in regular WordPress posts and pages with a simple shortcode call. Like this:

Don't let our love go away
No one wants sadness to stay

That is a simple Pods shortcode wrapped in blockquote tags, but you are only limited by your imagination, and css talents. How about:

In this second example, I’ve set the limit to two records. Note that records are called randomly, but I have included the chorus several times, so that will appear more frequently – just refresh your browser to see the random effect.

All you need to do is add the following shortcode to your post, page or text widget:

[pods name="happiness_today_text" order="RAND()" limit="1" template="happiness_today_list"]

WordPress Plugin Promotion Tool: Next Steps

All the data in the Happiness Today plugin is easily edited using the Pods data table editing features. In my example, I use couplets from the Think Of Happiness Today lyrics. Though I limit the example text to two lines so that it displays in the admin area properly, you can use any HTML text you like. The Pods WYSIWYG editor allows the usual formatting including hyperlinks, or direct entry of HTML code.

Using Happiness Today for longer visitor messages might make your admin area a little cluttered. No problem – simply deactivate Happiness Today – the data management and presentation features that I have discussed here are all part of standard Pods, and will work fine.

In future versions, I’ll add the ability to import and export different campaign text sets, with other options to make life even easier than it is with the basic release. But you do not need to wait – the current release can be used for any promotion campaign you can think of, including random advertising. In fact, it does not even need to be random, for instance specific records can be called on specific posts. The only limit is your imagination.

It is also vital to have a clear plan of the presentation outcomes that you need.

When describing the data aspect of my first plugin, I wrote of the importance of thoroughly analyzing the relationship between the presentation of content required, and the structure of data needed to support it. Recently, I saw a question on the Pods Support Forum that seemed to relate to this area. I was particularly interested in it because the issues seemed to be similar to matters I had encountered with my shrewdBar WordPress menu bar plugin.

The difficulty with forum discussions is fully understanding what the issues are. If one is sat with a client, or even on a video link, it is easy to mock up a quick display and discuss what the presentation should actually look like. Difficulties are compounded with cultural and time-zone differences. But, “All is one in their own way,” and the power of the Internet allows the following attempt at understanding the problem and suggesting a solution.

I hope it solves the problem it tries to address, but even if it doesn’t, I’ve learned a neat CSS trick that I’ll be using again.

Basic Pods Data Display

First, create the Pod (Pods – Setup – Pods – Add new pod) using the data supplied.
Second, add some test data (Pods – Add {name_of_pod}). We could have used the Pod menu settings to make this title more meaningful, or even used a separate menu out of the Pods hierarchy.
Third, create the Template (Pods – Setup – Templates – Add new template)

^{Happiness Today screenshot note}

Fourth, test the output without any styling using

<ul>[pods name="shrewdies_cafe_menu"  template="shrewdies_cafe_menu"]</ul>

Fifth, go back to the template, change the list (li) tag to anchor (a – because we need to hover), and add the labels for the prices. Then apply some styling.

The span tags in the template seem redundant up to now, but they are there for a very good reason. The popup display in the “client brief” didn’t seem relevant for the small amount of information to display. Given it’s complexity, I searched for something simpler, and found Eric’s pure css popups. So, adding some CSS styling, our list is transformed into:

WordPress Style Notes

The transforming CSS is called by wrapping our Pods call in an appropriate div:

<div id="links">[pods name="shrewdies_cafe_menu"  template="shrewdies_cafe_menu"]</div>

I’ve taken Eric’s CSS style and included it in this post, though in practice, you would probably paste it into your theme’s style sheet. Eric uses his for a menu positioned absolutely near the top left, so I have removed the container styling, and changed the span positioning to relative. I also added the bold line below – a duplicate of the preceding span line, with a greater than to signify anchor text that is a child selector of a span. Without both versions, the span element refuses to hide – I assume this is a conflict with the styling from my theme.

<style type="text/css">
<!--
div#links {width: 166px; height: 300px; font: 16px Verdana, sans-serif; z-index: 100;}
div#links a {display: block; text-align: center; font: bold 1em sans-serif;
   padding: 5px 10px; margin: 0 0 1px; border-width: 0;
   text-decoration: none; color: #FFC; background: #444;
   border-right: 5px solid #505050;}
div#links a:hover {color: #411; background: #AAA;
   border-right: 5px double white;}

div#links a span {display: none;}
div#links a > span {display: none;}
div#links a:hover span {display: block;
   position: relative; top: 0px; left: 100; width: 125px;
   padding: 5px; margin: 10px; z-index: 100;
   color: #AAA; background: black;
   font: 10px Verdana, sans-serif; text-align: center;}

-->
</style>

Happiness Today Screenshot Note

Though the two screenshots show the same lyrics from Think Of Happiness Today, do not think that the program has stuck, or in some way does not work. Those lines are the chorus, and I have repeated them in line with the original lyrics. This means that this particular couplet will display more regularly in the display area. If you adapt the plugin for your own promotional purposes, repeat your most important messages, and they will display more frequently.