When I post the Wordform files for download, I’ll provide details of the conversion from WordPress 1.5 to Wordform, but I thought I would provide an overview of the changes, upfront.
First, my decision to make such extensive modifications to WordPress that I decided to fork the code isn’t an indication that I think WordPress is a ‘bad’ tool, or is based on ‘bad’ coding. On the contrary: with this new release, I consider WordPress 1.5 to be one of the best weblogging tools on the market. The new themes design is absolutely brilliant, the user interface is intuitive and easy to use, and the code has been cleaned up very nicely–the developers can be justifiably proud of what they’ve delivered with this release. When the first bug release of the product is available for download, (1.5.1) I can, without hesitation, recommend this tool to any weblogger.
However, my views of what I want from a weblogging tool have been diverging from the WordPress developers for some time; luckily, since WordPress is GPL and I’m also a coder, I can do something about it.
Many of the changes I made to the code to take this tool from WordPress to Wordform are ‘under the covers’. For instance, I pulled all database queries into a separate file so that if I want to make changes to the underlying database I can easily without having to go through individual files looking to see what has broken. Of course, if I add or remove fields, I will have to change code, but in many cases, this additional separation of application and data can mean that even a significant change, such as multi-weblog support, can be made with relatively little impact on the application.
Other changes I made are very apparant to the user. For instance, I pulled all trackback and pingback code. Yup, every last bit of it, including dropping the table columns from the database. The more I looked at pingback and trackback, the more I didn’t like either: the former because it’s nothing more than referrer linking, and the latter because it’s too vulnerable to abuse. Instead of trackback and pingbacks, I’m incorporting the concept of ‘tagbacks’ into the tool, specifically as a focus for either a discussion thread, or as a multi-threaded topic. (More on this in a later post.)
(One side benefit of removing pingback and trackback is that the tool is very fast now. It was fast before I made the change; afterwards, updates and new posts are instantaneous. In addition, I think not having to manage these within the code has also simplified much of it, and simpler code (or more focused code), is easier to maintain.)
Another change I made was to the new WordPress Desktop. Instead of scraping in the WordPress Development weblog and Planet WordPress syndication feeds, I’ve incorporated a page that uses Feed on Feeds, a server-based aggregator that works somewhat like Bloglines. Feed on Feeds is just one of the external applications that can be installed with Wordform, and it allows you to subscribe to various sites. Then, when you access the Wordform Desktop (which has been renamed to “Bam-in-a-Can!”, for no other reason than it’s such a cheerful phrase), you’ll see the updated feeds from all your subscribed sites.
I pulled all implementations of ‘nofollow’ from the tool. I was going to detail how to do this for WordPress users; unfortunately, though, if you want to use WordPress as a tool, you’ll actually have to modify the tool libraries to remove this attribute, not just modify the tool templates. I’m reluctant to provide a ‘how to’ on this, as this will make the tool incompatible with future releases. If you want this information, you’ll need to send me an email.
I also added an option to turn on or off the enclosure functionality. Right now, if you link an MP3 in your post in WordPress, it’s automatically added as a syndication feed podcast. I’d rather give people the option whether to list this as an enclosure or not in their feeds.
I pulled in-page preview from the edit page, and added preview as an option for the main template. With this you can preview a post ‘in context’ –within the page design. I also added spell checking to the edit page, and am pulling the Quicktags in favor of a more sophisticated designer bar (which can be switched out for the existing Quicktags if you prefer the older design bar).
Some other major architectural changes:
- Creating a page literally creates a hard page, which can be individually moved. If .htaccess is writable, the page is linked to a virtual directory location; otherwise, you have to move it.
- I pulled private posts. The one time I’ve seen this, I didn’t like it. Here you have a weblog with this big “PRIVATE POST” blob in the middle of the page, taunting the readers with what they could not access–the plebians. I figure if a person wants private posts, they should think about having a private weblog. And again, this change nicely simplified the code — the old fewer moving parts, less breakage thing.
- I’m incorporating the concept of Wordform Application Modules (WAM) into the underlying tool architecture. These are full featured applications, wrapped to work with Wordform, as compared with plugins, which are bits of code written specifically for Wordform (or I should say, WordPress, as I’m keeping the plugin architecture the same so that Wordform can use most WordPress plugins). The Feed of Feeds implementation in the Bam-in-a-Can page is a example of a WAM.
- Comment and post status are pulled from the database and populated in a dropdown box. This allows application module and plug-in developers to add new statuses. I used this myself to add comment moderation on a post-by-post basis.
There are other new changes that I’m still working on, and hope to roll out with the first beta release of the product, some time next week or so.
I did incorporate my old comment management system in Wordform, and pulled the existing WordPress whitelisting functionality. I’m not crazy about whitelisting, and I don’t like blacklisting. What I’m doing is providing an option that allows a person to turn off comments older than a certain date. However, the comment itself isn’t turned off until the first comment that post received after this date. That comment is moderated and than the post is turned off. This allows the weblog user to see if the comment is spam, and if it isn’t, to make a decision whether they want to turn comments back on with that post.
I’ve also added in my old throttle, which will keep a person from being crapflooded; and am enhancing the manageability of the pages that display comments and posts — providing NEXT and PREVIOUS page functionality so a person can page through results. People can also search for comments and posts based on dates and post or comment IDs.
The post-comment editing functionality can take multiple tool backends, so you can use this with WordPress, Textpattern, Movable Type or other weblogging tool. In addition, I have a comments.php file that will work with both Wordform and WordPress, and which will enable spell checking, live preview, and post-comment editing.
While this is all going on, I’m also keeping an eye on the WordPress codebase, to incorporate relevant fixes to functions in Wordform, as they occur. And I have a couple of patches for the WordPress folks that I need to drop into the WordPress bug system, soon as I have a spare moment.
I’ll say one thing with all this effort: if you need help with your WordPress weblog, I’m your woman: I’ll probably know the code almost as well as the developers when I release Wordform 1.0a.
