There are plenty of examples out there of WordPress installs suddenly displaying blank pages—on admin pages as well as frontend posts—after changing themes, adding/removing plugins or updating the WordPress backend. Whilst there is plenty of good information out there covering most of the usual suspects, I just came across another which was fairly difficult to track down given the lack of information, though pretty easy to solve once I’d found it. If like me you’ve at any point tried to streamline your WordPress install by cutting down on a few unnecessary services, and reducing the number of calls to the database, you may have added some lines to your wp-config.php file like so:

define('TEMPLATEPATH', '/path/to/theme/directory');
define('STYLESHEETPATH', '/path/to/theme/style.css');

Fairly innocuous, until you actually change your WordPress theme, in which case those long forgotten about resource savers will leave you with little more than a blank page to diagnose your problem. If this is the case though, just updating the lines or commenting them out will leave you with a workable system once again.

troubleshooting, wordpress

After initially solving my database character encoding problems by ignoring the specific strings in the wp-config.php file, I was finally forced to alter the characters in the database during a recent reshuffle. Whilst there are two automated solutions available via plugin, namely g30rg3x’s UTF-8 Database Converter and the Modified UTF8 Sanitize Plugin, sadly neither worked in my particular instance, and indeed the former is no longer supported for current versions of WordPress, though reports on the WordPress support forum suggest there should be no issues.

Fortunately, an excellent guide was available on Alex King’s blog. For more information and follow-up comments, you should definitely read the full post, but here’s a summary of the method that worked for me.
(more…)

mysql, unicode, wordpress, wordpress plugins

With the latest 2.7 release barely out of the door, the WordPress team are already looking to set out the roadmap for 2.8. The recent update had an impressive mix of tweaks, fixes, features and a nice interface overhaul, and their little survey has a list of tasks to prioritise for the next release. Unfortunately, however, the one thing I should really like to see doesn’t make an appearance, that being some simpler ways to create a multilingual blog built into the core. At the moment there are a number of plugins out there that offer to do just that, and whilst they may do exactly as they say on the tin, the potential for a plugin to become outdated and fall behind the current WordPress release could create a lot of work sometime in the future, not to mention the fact that each plugin goes about creating a multilingual environment in its own unique way. Whilst I’m not alone in calling for at least some standardised framework, I can’t see any progress being made in the near future.

Languages, wordpress, wordpress plugins

Plugins can be a major boon. They can add variety to a site, integrate third party software, collect feedback, improve navigation, or add features. Occasionally they may become integral to the way a blog is run. But they can also become a burden or a major stumbling point. The recent WordPress 2.5 release made a large of plugins for the software incompatible, and outright broke a few. In those cases where plugins simply provide some added extraneous functionality, such breakages might not be a problem, but where they form an integral part of a blog the potential changes can bring a site to a halt.

Yet some downtime during a WordPress update is not the only worry when it comes to plugins. Whilst major updates often accentuate the problems, there is no guarantee that plugin authors will continue their work to cope with bugs and software changes. The small WPPA plugin currently used on this blog was recently broken by the WordPress update, but the author considered that the features introduced in the recent version might make his plugin obsolete, and only touched up the plugin to work with 2.5 (so far). Since I hardly post any photographs, such a change makes little difference to this site, but for many others migrating to another plugin could prove a major job if automated tools aren’t available. Others may have experienced such changes when moving between multilingual plugins as the features and support changed, from Language Picker, through Polyglot, to Language Switcher or WP_Multilingual. Such a migration might involve moving media around, altering themes, or having to change tags or syntax within WordPress posts.

How do you approach using plugins on WordPress? Do you consider WordPress should avoid leave extra features to the plugin authors rather than implementing features already well covered (e.g. tags, photos)? Should plugin authors attempt to implement migration tools or leave it to end-users to do the necessary conversions?

wordpress, wordpress plugins

With the news that WordPress Photo Album plugin potentially contains a security vulnerability, I decided it was probably time that I took stock of my increasingly long plugins list and removed some of the outdated and superfluous items. One of the greatest improvements to WordPress of late has been the automatic update checks provided for plugins listed on the official site, which whilst by no means universal does at least mean that updates for many popular plugins will automatically be reported without the need to check up on each one manually. This little list of what remains represents some of the better plugins I’ve encountered.

(more…)

blogging, review, vulnerability, wordpress, wordpress plugins

That is the question; as the well known soliloquy roughly goes. A Mind @ Play is now a year old, and not a day wiser, as far its author is concerned. Courtesy of GeneralStats, I can see that in the past year (excluding this post) there’ve been 57 posts, 18 comments/trackbacks, together a total of 31,400 words, and over 8,000 spam comments caught by Akismet. But to what end?

This isn’t intended to be another one of those ‘blogging about blogging’ posts, but occasionally one has to ask why we blog at all. I wouldn’t claim to be anything near an expert on the subject, but it would appear that the more successful blogs do just that: ‘blog about blogging’. Nor should that sound derogatory, some of them do an exceedingly good job of it, but there are only so many times you can read the ‘top 10 ways to get more readers’ et al. But then these people tend to come from the professional end of the blogging community, those who aim to earn something through their work. There were and are no such intentions with this blog, and if there are any advertisements on this site I can only say they are unintentional.

(more…)

blogging, wordpress, wordpress plugins

For those upgrading their WordPress powered blogs to 2.2, just a word of warning regarding the new character encoding options available in the wp-config.php file.

The standard file should have a section which reads:

// ** MySQL settings ** //
define('DB_NAME', dbname// The name of the database
define('DB_USER', 'dbuser'); // Your MySQL username
define('DB_PASSWORD', 'dbpassword'); // ...and password
define('DB_HOST', 'localhost');
define('WP_HOME', 'http://www.yourblog.com/');
define('WP_SITEURL', 'http://www.yourblog.com/');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', 'utf8');

Note the new options added at the bottom regarding the codepage used in the blog’s database. If these are set incorrectly they may make your blog unreadable, else prevent special characters from appearing correctly. I personally found that commenting these two lines out left the blog functioning as before, but for people wishing to change the codepage of their database, WordPress has a rough guide available, originally written for the beta testers.

software, unicode, wordpress