revjim.net

The Wordpress vulnerabilities "previously mentioned":http://revjim.net/item/10136/ have been corrected in the new version 1.2.1. "Go get it":http://wordpress.org/download/.

With that in mind, and my desire to start quick blogging daily journal type entries again, I decided to give it a shot. I was hoping the new improvements over B2/Cafelog made by the Wordpress team were enough to make the code usable for me.

Let me start by saying that I am quite impressed. The code is *much* cleaner and easier to read than it ever was with cafelog. These guys have really put in some effort, and it's certainly worth praise. Unfortunately, I can't use it as it is. Let me rephrase that, I can use it as it is, if I use it in a fashion that one of the Wordpress developers has previously acknowledged that someone might use it in. Unfortunately, my goals and desires rarely fit the bill of "commonplace". The saddest thing is, the code is *almost* there. With a little bit of shuffling, moving, and adapting, and *NO* breakage of existing templates it could easily be modified to be more usable… or rather, reusable. I haven't looked into the plugin architecture enough to know if plugins would have to be rewritten or not.

The changes are quite simple in statement, and just as simple in design: objectify everything. The only difficult part is difficult simply because it's time consuming. I'd be willing to make most of the changes myself, if Wordpress would be willing to accept them. I don't want to hack away at the code for my use, if I'm only going to have to *rehack* the next time Wordpress is updated. With that, you lose all the benefit of using someone elses code and that lands me in the same spot I'm in now with bBlog.

The important (to the user) part of the code, the template functions, would stay the same because a static method in one or more classes could be used to gather data from the most recently created instance of that object. And since, in current WP usage, only one instance would need to be created, there wouldn't be an issue there. After these changes pave the way for other features and such that users might desire to use, they might be required to use an object oriented version of the template functions. My belief would be that a system like Smarty or PHPSavant would make this easier to maintain (since it's already written… reuse is *good*), but, it could be done in a custom object as well. As long as the object name was something short and sweet (i.e. $d) you could easily get away with template code that looked like "the title of this entry is title() ?>", which is almost as clean as it is now. I still like the idea of using Smarty or PHPSavant more, though: less work, less maintanence.

In order to allow existing templates to remain entirely unchanged, "wp-blog-header.php" would be modified to use the new classes and would export whatever global variables were needed. Of course, only legacy installations would use "wp-blog-header.php" any longer. New users or new templates would be encouraged to be done the "new" way.

These changes immediately bring all sorts of new features to the "very easy to implement" status. Things like customzied URLs without ".htaccess", multiple templates per entry (for printable look and feel, etc), different templates for each category, and, with the right drop-in template engine, the ability to use one Wordpress installation to serve as a public LiveJournal-like area for any user to blog in.

It's just something to think about.

Of course, like I said, none of this really matters if these changes aren't accepted into Wordpress proper.