I’m starting to get a pretty good handle on what WordPress 1.3 will be offering, both from the code and forum discussions. I also found a link in the support forum for a WordPress 1.3 release wiki, which details the individual changes.
(From the wiki software used, I wonder if the WordPress documentation wiki is being moved to MediaWiki – the same wiki software used for Wikipedia. We can only hope.)
I’ve discovered some of these changes with the work I did for Doug, am doing for Steve right this moment (you can see the actual transform taking place here, as I migrate the HTML table layout to pure CSS), Tim (if he doesn’t lose his heart to Tinderbox), and might be doing for Loren (if he has a mind for this direction, now that he knows I’m not disappearing at the end of the month).
One big change, and one I adore, is pagination. With this, search results and archives are now paginated to list twenty or so entries at a time, with navigation automatially handled to go back and forth in the list. If you’ve ever searched my site on say, ‘flower’, my but you’ll kill both your and my bandwidth. Pagination will eliminate this problem.
The developers are also providing a Dashboard, I think for an overall linking mechanism to the site and the features, but it’s still under development–right now there’s nothing in the page. and you’re redirected to new posts. They’ve also packaging themes into their own subdirectory, and you can install and switch between themes just by coping the files into the directory and clicking a button in the administration pages. This will be good if you like to play around with your site a lot.
Architecturally, for the tweakers, the individual global values that you used to access in code previously have been added to a general object, but the old global values are maintained for backwards compatibility, at least for one release. The organization of the pages has changed, with a new header and footer page, which should help make the pages a little cleaner to work with. Recently when I talked about keeping your weblog tool independent, I mentioned about a split between the content of the page before the posts, the post listings, and the content after the posts. This is mirrored in the WP page split between wp-header.php, index.php, and wp-footer.php. I like it.
There’s also been function changes, and I’m still exploring what these are. From what I read, existing functions will be supported in a deprecated state for at least one software release. Good for those who have tweaked their pages.
Multiple blog support isn’t there, but an interesting announcement was made last week for what sounds like might be a parallel branch of development called WordPress MU. This isn’t a ‘fork’ in the code (i.e. a new and separate development based on original code) as much as it is a ‘wrapper’ around WordPress, from what I’ve read. The announcement about it says that it provides both Smarty template support and multi-user/multi-weblog support–in hosted environments.
The multi-user/multi-weblog capability should make WordPress more attractive for those who need a classroom solution to weblog hosting – a tool that can be used to create many weblogs for many different people, but administered from one spot.
As for the use of the Smarty template system, I am curious if this can be dropped into a regular installation of WordPress, for those who would prefer Smarty over the embedded function calls. If so, this would make a nice option to those who are uncomfortable messing with PHP code directly. Where before a person did the following:
<?php the_date(‘’,'<h2>’,'</h2>’); ?>
They would, instead, use a Smarty template tag such as the following that would resolve to the function call:
<h2>{$smarty.now|date_format:”%Y-%m-%d”}</h2>
The sidebar is also split off into a separate file. This does concern me a bit from a design perspective as this tends to enforce a specific type of weblog look, the two column look.
As an aside from a discussion of WordPress 1.3, when Movable Type announced it was providing a dynamic PHP-based wrapper around Movable Type, I thought that the company would take core bits WordPress and modify these to point to their own database so that WordPress plugins and templates would work with the Movable Type database. With this, though users would have lost the Perl plugins for MT, they would have gained the PHP-based WordPress plugins. At least, those plugins that deal with parameterized data, only.
This wouldn’t be all that complicated either. Smarty could have been used to transform tags for the traditional MT users; while others could have used the WordPress embedded function calls (and themes) if they wished. Licensing wouldn’t have to be an issue because MT could continue to license the MT ‘engine’ with associate Perl code, and GPL’d the code for the PHP wrapper. They would gain friends from the open source community, while the supported, proprietary, corporate Perl code would still be there for corporate types who get nervous around the word ‘open’.
And wouldn’t this have been an interesting way to mix proprietary and GPL code?