First step is to use a newer theme – this feature was added around WP 2.7, so themes before that time simply won’t show nested comments. The good news is that if you’re using any recent theme you should be OK. And of course, if you’re using TwentyEleven, it IS built into it.

Fine – but you say love your current (yet very old) theme – what to do? Unfortunately, it requires some editing of the theme – check this WordPress site tutorial for the code changes you (or someone you hire) will need to do.

One more thing: It turns out that if you have an old blog, you won’t automatically get that feature, even if you use a new theme. I was sweating over my theme wondering what went wrong when I stumbled upon the setting in Admin: Settings; Discussion; “Other comment settings” – then check the box in front of “Enable threaded (nested) comments…” (you can leave the level at 5 for now, and change it later if you need to). Save that, and with that one change, your comments will now be nested!

However, one issue is that little gray bar that appears at the top. Normally it’s not a problem, but when I use the dark display (as I did on UtopiaMechanicus.com) it becomes quite visible.

If you have the same problem, here’s how to turn it off – just edit your style.css file for the theme, and look for this text:

#branding {
	border-top: 2px solid #bbb;
	padding-bottom: 10px;
	position: relative;
	z-index: 2;
}

Comment out (or delete) the border-top entry, like this:

#branding {
	/* border-top: 2px solid #bbb; */
	padding-bottom: 10px;
	position: relative;
	z-index: 2;
}

Then save the file back. From there, refresh your blog pages, and you’re good to go!

Here’s the problem: since shortcodes are meant to DO something, how do you go about documenting them?

Well, one option is to use a double entry, like this:

[[c]]

WordPress understands that you are not using a shortcode, simply displaying it, and it will correct the issue, giving you the display of [c], and no activating.

However, what if the relevant plugin is missing? In this case, if I tried to use the doubled code without the plugin active, I’d get both pairs of brackets – very messy.

So, plugin active, [[…]] works, plugin inactive, [[…]] doesn’t work (and remember, that’s only for relevant plugins – if another plugin has another shortcode, then that plugin controls whether that shortcode displays right).

Of course, that’s annoying, and in fact there’s a few complaints about this feature in WordPress bug tracking. But that doesn’t help us right now.

For example, the last article described how to use a specific group of shortcodes. But the plugin wasn’t set up on this blog. However, if I later set it up, all those code examples would become ‘live’, and I’d end up with accidentally formatted normal text.

The only solution so far? Use an HTML entity for the left bracket, [

[c]just an example, no ‘working’ here![/c]

This breaks the shortcode scanning routine, preventing it from being used. Note that the one character is enough, you needn’t do it for the right bracket as well (but if you did, the code is ])

As the post title suggests, I had encountered a 406 error in working on a WordPress blog (otherwise known as “An appropriate representation of the requested resource XXX could not be found“) – but the error was extremely odd and a real pain to troubleshoot.

First off, this error message didn’t appear right away. In fact, the only problem was that the client couldn’t include images in his WordPress posts anymore. Trying to save/publish the post simply sent him to a blog page!

It took quite a bit of fiddling, but eventually the problem was found: the “http://” in the  <img> tag’s image URL was not working – leave it off, or use something like “https://” instead, and it saved the post fine (but of course wouldn’t display right).

The next step was to see what was causing it. I turned on the default theme, turned off all plugins, and tried again. Still no go – the file wouldn’t save, but went to a blog page.

Try again: this time I reset the permalinks from the usual text to the default setting (the ?p=XXX posts version). I also renamed .htaccess so it wouldn’t be influencing the blog at all. Still, no way to save the post when “http://” appeared in it. Not only that, but I now found I couldn’t set the permalinks back either! That is, trying to reenter

/%category%/%postname%/

back into the permalinks also sent me to a blog web page.

By now I was getting annoyed. Time to check the PHP settings via phpinfo(), using two variations:

<?php phpinfo(); ?>

and

<?php phpinfo(INFO_MODULES); ?>

(The former gives the PHP settings; the latter, the modules loaded in. To use, just create a file for each, upload, and then call via your browser. Be sure to remove them from your site after, as they leak a lot of information you don’t want passed around).

At this point, I was looking for something outside of the WordPress blog; a setting/module called MOD_SECURITY, which is a filter on data passed to the website. No dice, and no setting.

Unfortunately, no setting visible doesn’t mean MOD_SECURITY is not there (in fact, that turned to to be the case). But because I couldn’t access it, I couldn’t use the usual troubleshooting methods of editing .htaccess

For example, you can usually add this to the top of your .htaccess file to turn off MOD_SECURITY:


<IfModule mod_security.c>
SecFilterEngine Off
</IfModule>


For the most safety, you can selectively turn off MOD_SECURITY just within the /wp_admin/ section, by creating an .htaccess file there and including those lines. Alternately, for either location you can use these entries to turn off only POST filtering:


<IfModule mod_security.c>
SecFilterScanPOST Off
</IfModule>


By just turning off the POST filtering, the rest of MOD_SECURITY remains active.

Oddly enough, for my client, none of these worked. I figured it must be something else (like some server filtering, perhaps). But since I had explored all the options, I was certain that WordPress was doing nothing, and it must be a server setting. So I asked my client to contact support, mentioning that certain keywords were being filtered.

The result? THEY turned off MOD_SECURITY, and his site was as good as new!

So to recap for those pulling out their hair:

• MOD_SECURITY is a filter that tries to prevent ‘bad’ words from getting into the forms via POST (or GET). In this case, it thought the <img> (image) tag’s src= entry URL with “http://” in it might be an attempt at hacking, and likely /%category%/%postname%/ an attempt to hide data (the % is used for encoding).
• The problem was hidden at first because of permalinks. When the post was killed by MOD_SECURITY, the website generated a 406 error. But there was no handler for a 406 error, so the result was a 404 (file not found) error, which quite naturally IS handled by WordPress. Without turning off permalinks and resetting them, this would have continued to muddy the waters, making the problem very hard to figure out.
• MOD_SECURITY is elusive: although the setting may appear with phpinfo(), in this case it didn’t. No trace of it, yet the webhost had it activated.
• MOD_SECURITY can be deactivated. Although in this situation it needed a call to tech support, it’s possible to deactivate directly in many cases. You can use .htaccess to turn it off completely at the blog root, or turn it off in the /wp-admin/ directory only, or even better, use only the “SecFilterScanPOST Off” entry to turn off the POST filtering, leaving the rest of MOD_SECURITY still active.

I hope this little summary helps you if you encounter the problem. It was a hair-puller, but the end result was a little more Apache server information gleaned!

In the end, it was because of old wp-cache-config.php and advanced-cache.php files in my /wp-content/ directory. Briefly, these files caused a cache issue that was not needed on this blog. Remove them, and the blog was AOK.

The reason for mentioning this? I thought I’d explain how I troubleshooted (troubleshot?) the issue. Perhaps you’ve encountered a similar problem, but even not, here’s how you can narrow down many WordPress blog problems and troubleshoot your blogs:

• View the source. Just because a page is blank doesn’t mean it is blank. For example, a white page could still include HTML head and body tags. If part of them are missing, this might be a clue to where the program broke.
• Try to log in. If the main page is gone but the admin page works, start with theme/plugin issues. In this case, every link into the blog failed, so I knew it was a bit bigger.
• Try elsewhere on the site. I checked other blogs, other sections (such as a forum). No problems there, but if there was, I’d focus on site issues (server problems, htaccess issues, bandwidth/space constraints, etc).
• Try the site basics. Via FTP, I could confirm all the files were there and appeared complete. I logged into cPanel and confirmed the database was there and was fine.
• Tweak. For instance, with my FTP tool, I could change file names. Rename htaccess to something else, and then reload the page. Do the same for wp-config.php. I even downloaded, edited, and uploaded a modified wp-config.php, with a bad password, hoping it would complain. Nothing, which led me to realize the blog startup was not even getting to the database access section.
• Upgrade. I was planning to do this anyways, but I wanted to wait until I solved the problem, since this often adds problem on top of problem. However, it seemed it was not going to be solved anytime soon. I uploaded the new files directly, but keeping the current files safe by moving them to a separate location (I wanted them for later checking). I also DID NOT reuse the /wp-content/ directory (with my plugins and theme) yet.

My reason for this was simple: I wanted a pristine installation to see if it could start up. In fact, it did, and I was relieved. Yet when I started adding my /wp-content/ back in I encountered problems. The reason, as I said was those files, which triggered caching where they shouldn’t.

If it appeared I just did divide and conquer, you’re right – breaking things up into smaller sections makes for easier checking, and eventually caught up with the problem. Look to breaking up a WordPress issue like this, and you might find troubleshooting easier and problem-solving faster.

It’s always possible to save money by doing it yourself. There are many online tutorials, and sites that explain how to do WordPress setup and configuration (like this one). However, if your primary goal is to make money, it pays to stick to what you’re good at.

But if you prefer to get someone to set up your WordPress blog, add features to it, customize the design, etc., here’s some hiring tips:

• A website is like a house. You pay for the amount needing to be done. Do you have a domain name? A website hosting plan? If someone has to clear the field and dig the foundation to make way for your site, then their time will cost.
• WordPress uses themes to change the look. There are many available for free, but they may not suit, so you’d be paying for modifications (it’s also VITALLY important to get someone to check over a theme, as it can have malicious/spam code in it). Generally, the fewer the modifications, the lower the cost.
• Much of your expense will likely be extras. For example, do you need your blog set up, are there any other items on the site to be set up or connected to the blog (forum, helpdesk), etc.
• Selecting and setting up plugins are another aspect – these are code pieces that ‘plug in’ to your blog to add features. For example, one plugin takes care of comment spam (which can be a time-consuming chore daily).
• Finally, you will want your blog to be search engine optimized, which means an edit or two of the theme to add SEO options. For example, you should do tracking of your site, which will require a setup of Google Analytics (a free but powerful tool).

You’ll notice I never mentioned quality of work, references, or the usual stuff. That’s because I’m sticking to WordPress in particular here. General hiring tips should always apply of course, and just because someone says ‘WordPress Pro’ doesn’t mean they can be trusted. Get to know them if possible, and see what work they offer.

Nonetheless, it’s not easy finding reliable people. So as a service, you can open a held desk ticket on this site and ask me! I meet (and get to know) a lot of WP techs online, and I may know of someone who’s a good fit. If nothing else, I may be able to steer you towards a way to save money.

And of course, I still recommend a little bit of getting your hands dirty – and what better way than with a membership in ActiveBlogging, and the ‘Knowledge You Need For The Blog You Want!’