Fran Ontanaya

Only the last paragraph is related to the Word Stats Plugin. There was some issue with posts that contained a no break space html entity, which wouldn’t get counted. I made a small change to how no break space entities are dealt with and I haven’t been able to reproduce it yet on WordPress 3.4.2 with the plugin version 4.0.5.

Check if the posts contain a nbsp entity and if the 4.0.5 version I just uploaded fixes the issue (resave the posts to make the plugin count words again).

I can’t do much non commissioned work on it right now, but I’ll add it to the To Do list.

Next minor version will have an argument validation check. I’ll have to figure why bst_match_regarray wasn’t passed an array.

There’s currently a bug with posts that include a & nbsp; (without the space) which seems to prevent counting. I’ll get it fixed as soon as possible.

The code has been removed. The plugin is now all free.

Thanks for the feedback. I’ll look into it anyway. Feel free to point any other issues or request features.

Thanks. It sounds like the javascript code may be failing at some point. I have to investigate more edge cases. Can you tell me which browser and version are you using? Also, does it happen for whatever range of dates?

A new version should be up in 15 minutes or so.

You can deactivate it manually by deleting the folder word-stats in wp-content/plugins

This is an error related to older versions of PHP, which don’t support the boolean ?: I’ll rewrite that code.

New version is up.

I’ve added support for multibyte scripts in UTF-8 encoding. This should cover cyrillic, along with all the other major scripts. Check the screenshots page for an example. Other non-Latin encodings aren’t supported in this version.

I don’t expect the algorithms to do a very clever job with languages like japanese or hindi, but hey, they will try.

Thanks. I have reproduced the bug. The plugin isn’t processing cyrillic properly because it is looking for alphanumeric characters. I’ll fix it ASAP.

wp_list_comments outputs Microformat markup. This is problematic, because it is advised not to mix Microdata and Microformats in the same page.

A wide solution is needed (i.e. a global setting, and tags for themes and plugins). Otherwise, with plugins, themes and core functions each making a different choice we’ll always end with an unacceptable mix.

If I’m not missing something else, 1.4.4 should fix this.

Noted. I removed one line break outside the script in 1.4.2. Some functions output HTML, I’ll get those converted to PHP too.

I don’t get any errors or warnings in any of my WordPress installs, but I’ve received a similar report from another user.

Thanks for the feedback.

It probably would benefit of a bigger focus point. Not necessarily “huffington post” big, but certainly bigger and more centered.

Also, the login/register area could use the space in the header, somewhat like in The New Yorker.