Although it’s only slated for release sometime in May, the first beta of the new WordPress 3.0 is already doing the rounds. Blog Oh Blog has a nice summary of the changes and additions in the new version: most of the updates are fairly innocuous, perhaps the largest mention should go to the integration of WordPress-mu, for setting up multi-user blogs and networks.
However, the announcement that really put the cat amongst the pigeons has been that the core development team may now be promoting what were formally called canonical plugins, now known as core plugins following the unpublished results of a poll in December. It appears that whilst attempting to address a genuine issue, the very idea of having plugins that stand in the limelight with an official stamp of approval has incensed many community plugin developers.
Some really excellent debate has been held which has, amongst other things, revealed that the initial go ahead for core plugins will be very limited; just three plugins, including an old, out-of-date plugin, a chunk hived off from the core, and a newly developed plugin. Nevertheless, the potential for these core plugins to have wide-reaching effects on the plugin development pool, create stagnation in the community and a greater top-down hierarchy is something that in the eyes of many developers and enthusiasts, has not been addressed.
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:
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.
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. Continue Reading
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.
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?