Get it All
Together

Took me basically all day to get this done, but as of this moment, HolisticNetworking.net is now powered by the newly-fused WordPress 3.0 installation. Whereas previous versions of WordPress were branched into WPMU and WordPress classic versions, the new version brings it all back together (very Holistic, actually!) into a single installation.

I’m going to confess that vanity made me resist this new version: WPMU was the advanced version of WordPress that made me feel cool. But given the way in which I generally use WordPress MU on this site, the new synthesized version of WordPress is probably a better choice anyway.

On a technical basis, one of the things that concerned me most was how the association between the various blogs would differ with this new installation and whether carefully-built plugins that deliver the front-page content would end up broken as a result of the upgrade. I’m not sure whether the new version introduces new methods of access, but certainly the old ways have been maintained and the transition has been fairly straight-forward as we’ve come to expect from the great folks at Automattic.

So the question now is: how does this affect my WordPress MU Function List? Are these functions still relevant and should I create an entirely different page for new stuff? I must confess that I’ve been out of the WordPress game and only just barely paying attention to the Hackers list, so perhaps tomorrow is a good day to correct that laziness on the WP front!

Another task for the near future is yet another redesign of the front page. My “Fluidity” experiment was a good one and worthwhile. But now that I’ve had a chance to see what the front page looks like on a high-resolution wide-screen monitor, it’s clear that the experiment should be brought to its swift conclusion. My blue and white pipes theme will doubtless be maintained, but I’d like to return to a fixed-width design. All in good time!!

It’s one of those bad habits we find hard to break as WordPress enthusiasts: installing plugins and then forgetting about them. This is especially true when you’ve installed them through the WordPress admin panels and then deactivated them because you decided you didn’t like them.

Well, now I’m getting very close to done with the new theme for DFE and I’ve got to go through all these plugins to find out what I’m keeping and what I’m not. You have to be very careful that the plugins you’re using do not conflict with one another or with template functions, and this new template is also going to be introducing a number of new functions and plugins both.

Because I’ve found that it just makes more sense to keep some things as template functions. I’ve not really bothered to play around with template functions because I’ve always seen the template as a display-only set of code. Indeed it is, but if there is additional processing to be done on display that isn’t needed anywhere else, WordPress provides the function file to deal with this. It’s not entirely MVC, but then, what is? Perfect systems don’t always work in an imperfect world.

Like eliminating unused plugins, moving display-altering functions to the template is about making things more efficient. If WordPress forces your server to spend time it doesn’t need to reading plugin files you’re not using, you take a hit on your performance. If you have functions which only operate on the display level, but which are contained in plugins, then each time any admin page is run, the plugin has to be turned on despite the fact that it will never be used. We’d like to avoid this, if at all possible.

On the other hand, adding huge volumes of code to your functions.php file has a similar effect: every time the front-end of your website is launched, you bog your system down with code. So, you need to balance what you use in the functions.php file and what you use as a plugin very carefully and make sure you’re using the most efficient code possible.

I just thought I’d write a note about the new Favorite Actions bar in the new version of WordPress. This seems to have been designed as a way to mollify the concerns of the people who used to like the old layout of the administration areas better. But it’s a handy little shortcut to important things and of course, there’s a natural tendency as a plugin developer to want to utilize this space for your own plugin.

In fact, I was looking up how to do this very thing when I happened upon this page. The author cautions, quite rightly, that using this shortcut bar too much will end up clogging the thing and making it useless.

So, it seems to me that the responsible solution for plugin developers who want to make use of this new space would be to make it an option of your plugin which is always disabled by default. Doing so would allow your plugin users to make their own choices about which options to include in the favourites and which to leave as standard options. It is, after all, called a “favorite” actions bar.

In fact, I am hoping that future iterations of the WordPress core will include options to make this bar genuinely customizable according to your own preferences. The combination of a customizable favorites list and optional inclusion of plugin functions would represent the best of all possible worlds for this easily abused space.