I listened to an interview with WordPress developers Matt Mullenweg and Donncha O’Caoimh. It reminded me that I hadn’t checked out WordPress 2.0 yet.
I downloaded the code using the Subversion command:
svn export http://svn.automattic.com/wordpress/trunk/
This gave me a copy of the code without the Subversion source code control files. I then uploaded it to my server to WordPress Two and had a look around. Asymptomatic has a good review of what’s changed, including a true data abstraction layer, which should make for a more robust product.
From a user’s point of view, the administrative interface is vastly improved, with a much better organized, as well as more attractive design. This is the Post Edit page and as you can see most of the post options have now been placed behind DHTML-based buttons, which can be clicked to expose or hide the specific option. As the page also shows, photo uploads can be handled directly for the post and, though it doesn’t show in the snapshot, in-page preview actually uses an iframe and loads the user’s stylesheet, so you get a chance to see the post ‘live’. You can also use an Ajaxian option to add new categories, on the fly, as you add a post. The Edit page also has a WYSIWYG editor, which you can turn on or off in options.
The theme selection page also has some new features, such as seeing an image of each theme available for use in the page. However, a new option allows the theme designer to attach a functions.php file to their theme, providing options to allow the users to customize the existing theme. In the Default theme, this allows the user to change the header and font colors.
All in all, WordPress 2.0 is a major improvement over 1.5. Enough that if you’re thinking of moving to a self-hosted weblog rather than a centralized hosted solution, now is the time to give this possibility serious thought.
After this first, quick look, I have only two suggestions for the WordPress development team. The first is remove the section listing those posts currently in draft above the page where the post is developed. It takes page real estate, and you’re repeating what’s already available in the Manage page. The second change I would recommend would be to make the WYSIWYG editing interface plugin-abled so that any number of good WYSIWYG editors can be wrapped and released as editing plugins. I did this with Wordform, and it gives the users an option in the one area they can be most picky: the editor.
(I believe the Desktop can be replaced with a plugin, but if not, this would be another suggestion.)
One thing I do differently, and something for the developers to consider, is a separate preview of the page. I did this with Wordform, using the same files that are used for the main page, but with a preview option. Right now, with the page previewing in the edit page, if the entry has several photos, this could slow the page down when loading and saving after edits. Also, even when you load the stylesheet, viewing the preview in an iframe is not the same as actually viewing it exactly as it would look when published. Still, this is a preference–there are folks who would probably prefer the in-page preview.
I’ll be getting a fresh export and updating the code once a week or so until the beta is released. I’ll cover different aspects of the tool with each release, as well as discuss what I would do to alter the base tool with plugins and administrative extensions.
If you’re interested in playing with the new interface, send me an email and I’ll set you up a test account — if you’re not too scary, or have a name like “Joe Spam” or something.