I received a comment recently tipping me off to a bug in my Virtual Multiblog system for WordPress. In certain cases, the system will show one particular blog no matter which address you go to.
If you’re having this problem and you’re using the $vusers[] list, try changing the order of the $vusers[] list. This alone may fix things.
I’ll try to get a “real” fix out soon (probably this weekend). A new version should be coming out anyway within days. 
I just uploaded the new version 2.2 of my JavaScript Pull-Quotes plugin for WordPress.
Improvements:
…plus the usual regimen of minor code improvements here and there.
In recent changes to WordPress code, users are more than ever able to customize folder and file locations. [Edit: Refers to WordPress 2.6] The wp-config.php file can now be located one directory up from the one containing WordPress. The wp-content folder can be moved arbitrarily, as can (separately) the plugins folder. What’s a poor plugin author to do in keeping track of these ever-moving targets?
When those last two folders are moved, it is done by defining specific constants: WP_CONTENT_DIR and WP_CONTENT_URL for the wp-content folder, and WP_PLUGIN_DIR and WP_PLUGIN_URL for the plugins folder. In plugins it’s best to use these, except that they are not defined in a default setup, and don’t exist in earlier versions of WordPress.
The solution, fortunately, is simple: Check if they are already defined. If they’re not, then the folders are in the default locations and you can define them accordingly. Then just use the constants as normal. Here’s the code; just drop this somewhere in the beginning of your plugin:
if ( ! defined( 'WP_CONTENT_URL' ) )
define( 'WP_CONTENT_URL', get_option( 'siteurl' ) . '/wp-content' );
if ( ! defined( 'WP_CONTENT_DIR' ) )
define( 'WP_CONTENT_DIR', ABSPATH . 'wp-content' );
if ( ! defined( 'WP_PLUGIN_URL' ) )
define( 'WP_PLUGIN_URL', WP_CONTENT_URL. '/plugins' );
if ( ! defined( 'WP_PLUGIN_DIR' ) )
define( 'WP_PLUGIN_DIR', WP_CONTENT_DIR . '/plugins' );There are a couple things to note:
PLUGINDIR constant at all. It is both obsolete and problematic. Use WP_PLUGIN_DIR instead.WP_PLUGIN_DIR as something like dirname(dirname(__FILE__)). Don’t. First, it’s inefficient, as it unnecessarily calls dirname() twice. Second, I’ve seen (albeit unusual) situations where it caused problems*.So. Not so complicated after all — it’s just one of those rote things that’s helpful to know. Use those four constants and you shouldn’t go wrong finding the right paths in WordPress.
Just trying out Google’s new browser, Chrome. The admin back end for WordPress (that is, the page I’m working on as I type this) is blazingly fast running on Chrome. Faster than Firefox, IE or Safari — as in: No Contest.
Google set out with a specific goal: to create a browser that is designed to run mature, full featured web applications; and at first blush, it appears that they have entirely succeeded. I haven’t even tried it on Google’s own applications, such as their online word processor.
The design of this browser is quite different from other browsers, especially under the hood. I’ll probably keep Firefox for general browsing, but I will almost certainly use this for “application” use, from blogging to online banking.
Bravo.
(…and get that Mac version released!)
One of the most common questions I get regarding the Virtual Multiblog system for WordPress comes from people wanting to have multiple blogs running on the same theme, but with a different header for each blog. It can be done, and it’s fairly easy to do. Once you have it set up, you could use it to call any distinct file on a per-blog basis — a different CSS file, or a different footer perhaps.
I’ve never been too active about showing this to people, because the function required to do it is not one I consider completely stable — I din’t want to show people how to do it only to have it break the next time I update the VMB system. In response to the requests, however, I am adding a function to the upcoming release (currently in private beta). You can have that ability right now, in a way that should not cause problems with later updates — just add a short function to your existing vmb-functions.php file.
Read More
In the course of working on WordPress, and plugins and such for WordPress, I frequently find myself at a loss to remember the name of constants provided by the system. Hey, isn’t there a constant for such-and-such directory?
I did a bit of grepping and parsing just now, and in the hopes that it might be of use to my fellow WordPress hackers, here is my list of every defined CONSTANT in the latest WordPress 2.7-bleeding setup.
Read More
If you’ve been using WordPress for any amount of time, you’ve probably come across a plugin that asks you to add something to your template. The instructions will say something like:
Insert the following into your theme files where you want the plugin’s widget to appear:
<?php my_plugin_widget() ?>
The slightly more intelligent instructions will understand that the plugin might be deactivated, and suggest you wrap the function in an if() that checks for its existence:
<?php
if ( function_exists( 'my_plugin_widget' ) ) {
my_plugin_widget();
}
?>In your own plugins, you can streamline this for the end user by wrapping your function in a custom add_action. How? It’s incredibly easy. Just add an add_action() to your plugin file, like so:
add_action( 'show_my_plugin_widget', 'my_plugin_widget' );
function my_plugin_widget() {
...
}Now your users can use one straightforward line in their templates.
<?php do_action('show_my_plugin_widget'); ?>One short line of code. No worrying about deactivated plugins. A small extra effort on your end can save your end users some frustration down the road.
Next Time: Cold Fusion! (article may be delayed by technical feasibility)
Previously: Use Classes in your WordPress plugins to increase code portability and reduce name conflicts
There’s a new version of the Quiz plugin (a.k.a. “Comment Quiz”). The plugin requires commenters to answer a question before the comment is posted.
Significant improvements in 1.1, including a native meta box in the edit post/page screen, and the ability to have more than one acceptable answers to a question.
