You can upgrade your existing Search Meter from your WordPress administration interface, or go to the Search Meter page for more information.

Excessive question marks often indicate a problem with character encoding. After a little investigation I realised that the character collation for most of the WordPress database tables was set to latin1_swedish_ci, indicating a character set of latin1. Clearly this was going to cause problems for non-western languages; I noticed problems with comments from Israel, Eastern Europe and East Asia amongst others.

The fix was pretty simple: change the character set used by the comments table to UTF-8 like this.

ALTER TABLE wp_comments CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

I think this happened when I restored the database from a backup; the collations were reset to latin1_swedish_ci, which is the MySQL default. Sadly, the encoding problem was happening when data went into the database, so all the current question marks will remain. At least future comments and trackbacks will now appear correctly, I hope.

There is one strange thing though — the comments table in another blog of mine has its collation also set to latin1_swedish_ci, but it can handle Japanese, Hebrew, Russian, and anything else I throw at it. The case continues.

Seemore makes reading posts more intuitive for your readers. With Seemore, when readers click a (more…) link they see the full article on the screen, not just the part after the (more…). For your convenience, now you can get Seemore at the WordPress Plugin Directory.

For some reason this has been touted as the “Clean Subversion Repositories” feature. They really mean “Clean Subversion Working Copy”, but in fact Subversion doesn’t really care about other files in its working copies. The feature is mostly useful for people who don’t have command-line Subversion access in their blog file systems. With the core files separated, you can upgrade simply by deleting and copying in a single directory. This is a big improvement to the previous version, which require a tricky piecemeal copy.

The problem is that there’s no definitive documentation on how to enable it. It’s annoying that the WordPress team list this as a new feature, and then leave it up to the users to figure out how to make it work. You could look at the Trac ticket for this feature for more information. That’s what I did; if you want to enable it too, you could do worse than start with my method.

Do this at your own risk, of course. It’s worked for me on the one site I’ve tried it on, but I haven’t yet been brave enough to do this on Semicolon yet.

To have your blog at http://example.com/semicolon, with the content and config files in /home/web/semicolon/. and the core files in /home/web/semicolon/wordpress/, here’s what I would do.

1. Install WordPress in /home/web/semicolon/wordpress/
2. Copy index.php from /home/web/semicolon/wordpress/ to /home/web/semicolon/
3. Edit your new index.php. Replace the line
require('./wp-blog-header.php');
with
require('wordpress/wp-blog-header.php');
4. In WordPress, go to Settings and set your Blog address (URL) to http://example.com/semicolon

Make sure everything works OK. Next comes the scary bit.

5. Move (don’t copy) wp-config.php and wp-content from /home/web/semicolon/wordpress/ to /home/web/semicolon/
6. Edit your new wp-config.php. Add the following lines just before the line that says “/* That’s all, stop editing! Happy blogging. */”

define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/wp-content' );
define( 'WP_CONTENT_URL', 'http://' . $_SERVER['HTTP_HOST'] . dirname($_SERVER['SCRIPT_NAME']) . '/wp-content');

That’s all! Test. Enjoy. Now your own files and content are in /home/web/semicolon/wp-content/ and /home/web/semicolon/wp-config.php. All system files are in /home/web/semicolon/wordpress/, which can safely be deleted and replaced by an upgrade any time.

Now apparently there may still be some problems with plugins and with file uploads. This may explain the complicated instructions in the WordPress Codex, which involve editing the .htaccess file. Yikes. A feature that requires you to edit .htaccess is an unfinished feature. My method is more like the other Codex method described in Editing the config file, except it’s more generic. I haven’t found any problems yet with my approach — but that doesn’t mean you won’t. Break a leg.

Widgets

Search Meter 2.3 includes two WordPress widgets. Popular Searches shows a list of the most popular search terms that have produced hits at your site during the last 30 days, and Recent Searches shows a list of the most recent searches that produced hits at your site. Readers can click search terms in the list to search for the term themselves. Both widgets display up to 5 search terms by default, but you can change this to whatever number you like.

Security

This version fixes a security hole in previous releases where it was theoretically possible for an unscrupulous website to trick you into deleting your saved search data. This was a pretty minor risk: the search data is transient anyway, and I have not heard of anyone even thinking of doing this, let alone actually managing to carry it out. Anyway, from Search Meter 2.3 the “attack” is no longer possible. Previous version are still vulnerable, so truly paranoid users should upgrade. And don’t forget to wear your tinfoil hat.

A polite suggestion

The Options and Statistics screens now include a button allowing convenient access to PayPal to make Search Meter donations. This is meant to be a gentle, unobtrusive suggestion rather than a blatant advertisement. There’s an option to turn it off if you don’t like it (or even better, if you have already made a donation).

Remember, donating is optional. You can donate nothing, or you can donate $1000 (yes, really) but Search Meter will work the same regardless.

Other changes

I have made a number of changes to the internal workings of the Search Meter code, just to tidy things up a bit and make it easier for me to work with. This version also contains the installation bug fix from Search Meter 2.2, which I released quietly a few months ago. That problem was caused by a core change made in WordPress 2.2.1.

Download

As always, go to the main Search Meter plugin page to see full details and to download Search Meter 2.3.

The best new feature is that Code Markup now fixes a WordPress bug where backslashes inside a <pre> block would not be displayed. With Code Markup, such backslashes are now displayed even if not in a code block.

The “allow” attribute is now called “markup”. I could never remember whether allow="span" meant that <span> was allowed as a literal or allowed as markup. Now I hope it’s clearer: markup="span" means that <span> will be treated as markup, not displayed literally.

For backwards-compatibility, you can still use “allow” as the attribute name. So any existing code blocks will still work with the new Code Markup.

Finally, Code Markup works better now with tags and comments that span multiple lines.

Download

For details and download, see the main Code Markup page.

I have recently redesigned this website; it now uses the marvellous jQuery library for some of the effects. So to avoid having to include Prototype, I modified Share This to use jQuery instead of Prototype. If you want to reduce the time taken for your pages to load, you could replace the original Share This with my version; this is is especially good if you are already using jQuery.

To use this version of Share This, first install the original Share This (version 1.4), and then download Share This (jQuery) and replace the original share-this.php file with the new one. Read on for more details.

Here are the changes I made, compared to version 1.4 of Share This.

Use jQuery instead of Prototype.
jQuery is included in WordPress 2.2 and later versions. For earlier versions, you should download jQuery and copy it into the wp-includes/js/ directory in your WordPress installation. Make sure the file name is jquery.js.

Behave nicely if somebody tries to load the plugin file directly.
If someone tries to load the share-this.php file directly, just show a blank screen. The original version shows an error message.

Use a sliding “roller blind” effect when showing the Share This popup window.
Just because it looks nice.

Remove some unused code.
Because it was unused.

My modifications are in the public domain.

Now, there is one other change. The position of the popup window is not the same in all browsers; in some browsers (such as Firefox) the popup appears below the “Share This” link; in others (such as Internet Explorer) the popup appears just to the right of the link. I don’t mind the inconsistency: both variations look nice in themselves.

I thought about using the Dimensions plugin to emulate the original Share This more exactly. But in the end I decided to keep things simple and avoid introducing yet another file.

If I try to write a WordPress blog post containing the word “python” followed by a space, I get an HTTP error page. The error is “403 – Forbidden”. After a bit of experimentation I have found that the “python” can be in any case, and that it’s only a problem if followed by a space.

By some coincidence, I recently read about a similar mysterious bug on the WordPress support forum. The problem seems to be caused by over-zealous mod_security rules. It looks as if my web host is using mod_security to block any HTTP POST that appears to contain a Python command. Even if it’s only me trying to write a blog post about scripting languages.

Even though my problem was with the word “python”, the forum post mentions similar problems with the words “compress” and “curl”. It just depends on what rules your web host has implemented.

I know better than to try to get my host to change their rules — it would take a bit of time, and there’s a workaround anyway. Just add some obfuscatory HTML to avoid triggering the rule. My first attempt was this:

“Python ”

This works fine, but unfortunately WordPress actually translates the   into a space. Later, if I edit the post and try to save, mod_security blocks it again. I have to manually replace the space with a   again.

So here’s the best solution I found.

“Python<span></span> ”

Note that you have to be in the code editor (not the visual editor) in WordPress to enter the < and > characters. Using this trick you can talk about Python just as much as you want, and edit your posts too. And this solution is completely general; you can write com<span></span>press or cu<span></span>rl or whatever other forbidden word you like.

See the main Less plugin page for details on what it does, and to download this fine piece of software.

There are just a handful of changes in this version. When saving a post: if there is only one category set but no main category, then that single category becomes the main category. There is also a breaking change: the topcat_the_main_category_id() template tag now has only one optional argument (it used to have three). In the unlikely event that you were using the before and after arguments, they will now be ignored. Those arguments didn’t make much sense anyway.

And there’s also a bug fix or two. (Thanks to Alfredo for pointing one out.)

The most useful addition is not even in the plugin. On the main Top Cat page, there’s now a short example explaining how to use Top Cat to make your posts change colour according to their main categories. you still need to be at least a bit familiar with HTML, CSS and PHP, but it should at least point you in the right direction.

You can get full details and download Top Cat at the main Top Cat page.