Category: Weblogging

I am in the midst of converting Wordform’s architecture into supporting multiple weblogs. The procedure I worked out, over coffee at Border’s, is the following:

Pull the SQL statements out of all the application files and incorporate them into one file. The reason for this is to help me identify all of the SQL bits the application is using, and make sure none are missed. This also makes it easier to make changes to the underlying SQL in the future — as all of the database accesses will be in one spot.

Update the database. I’m adding blog identifier to most of the tables, but I’m also splitting the options table into a weblog information table and an options table, and adding some foreign key relationships. At this time, I’m using a default weblog identifier until the program pieces are in place to add weblogs.

Modify the program to set a default blog identifier, and then adjust all the functions accordingly.

Once the backend components are in place, I’ll front end pieces. The first will be to add a section to pick a weblog from an existing list, or choose to create a weblog in the what used to be Dashboard. Picking an existing weblog will set the globally accessible weblog identifier within the administration tool.

Creating a new weblog is a bit tricky with PHP, because the application doesn’t have general write permissions. A new .htaccess file, index.php, and word-contents subdirectory need to be created in the new location of the weblog. Either the create weblog routine will provide the how-tos, or more likely, have the person make the subdirectory writeable temporarily.

Other than the tricky bits, the rest of the weblog creation is simple — just data collection.

The base installation of Wordform is very simple, meeting the needs of most users. The multiple weblog capability is being added to the code, but the actual front-end pieces are being create as a Wordform extension — pages that can be dropped into the tool’s administrative interface. The capability for this also requires several backend code changes.

First, the post status and comment status are being pulled in from the database, to make these adjustable via extension or plugin. Next, the menu data that runs the top navigation tags for the application is also being pulled in from a database, again so these can be easily updated with administration extensions. Finally, the former dashboard is being modified in a couple of different ways.

First, the list of extensions is displayed, with an option to uninstall each. (Unlike plugins, administration extensions can be installed or unintalled, but can’t be turned on and off). Next, the main area of the page is dynamic, just like the weblog posts themselves. With this, extension developers can create content for this area for hooking their extension in as needed. For instance, with the multi-weblog extension, the extension will add code to list the weblogs, allowing the person to select from the list. This list will be filtered to just those who have been given access to the weblog.

The multiple weblog extension itself will consist of a couple of files that are copied to the administration subdirectory, and loading one page that makes the appropriate database updates. Refreshing the admin site in the browser will then show the new extension in place, with all the appropriate backend goodies in place to use it.

My plan is to have these bits in place by New Years and then release a first cut of the code. All of this should be sufficient enough to make Wordform a unique product by that time.

Recovered from the Wayback Machine.

In my comments, Eric Wallace asked about multi-weblog support. I can answer him, with a few caveats, that yes, the first alpha release of Wordform will have multi-weblog support. The caveats are that this support, in addition to multi-user support, will be added as formalized extensions to the base product.

Much of the work I’m doing in the administrative pages is to make much of the interface dynamic, so that I, or another developer, can extend the options available within the tool itself — not just within the weblog pages shown to the public. By doing this, the base Wordform release will be very simple and easy to use and hopefully will meet the needs of 95% of the weblogging user base.

Now, for the other 5% of webloggers who want to get down and funky, well, they have some interesting possibilities available to them, as time goes by; including three extensions, called Administrative Extensions that will release with Wordform 1a.

The first Administrative Extension is multi-user support, and this will add in the User management page, in addition to a drop down in the edit page allowing an administrator to pick which user to write as. For the non-administrative users, they will only be able to post as themselves.

To meet this functionality, the Profile page will be pulled out of the Users page, so that everyone can manage their own profile, regardless of Extension installed. In the Users Management page, though, those with administrative permissions will be able to assign Profile types to users, as well as define what accessibility each profile will have.

The User Management page will also allow the administrators to assign individuals to specific weblogs, which leads to the next major extension: multi-weblog support.

The developers of WordPress had added blog number to tables in 1.2 (correction: I don’t find these, so will need to add), but hadn’t implemented multi-weblog support, because this is not an easy change and I can respect this, having to struggle with solutions myself. Specifically one problem with PHP is that you have to set directories to write by the world to add files, and this isn’t necessarily secure.

I’ve thought about this one for a long time, and the implementation I’m going to support is something a little different–matching Movable Type’s way of doing business more than WordPress.

If you install the Multi-Weblog Administrative Extension, an administrator gets an option to create a new weblog. This weblog will be added to the database system, and you’ll be asked for specific URLs of the home page, archive structure, and so on — just as with permalinks options page now. You’ll be given a second of permalink entries for an .htaccess file for the new weblog, but you won’t add them to the existing .htaccess file for the initial weblog installation; you’ll add them to the .htaccess file at the new location.

(There will probably be one more file that needs to be copied to the new location. Hopefully no more.)

The new location will act as a separate weblog, but it will be run on the same Wordform installation.

So I have a weblog at practicalrdf.info and one at weblog.burningbird.net. The practicalrdf.info site is a subdomain installed in /home/shelley/www/rdf, and weblog is installed in home/shelley/www/weblog. I install Wordform at weblog.burningbird.net (in /home/shelley/www/weblog) and generate permalink entries for the .htaccess file at weblog.burningbird.net.

When I add the second weblog at practicalrdf.info, I’ll generate a second set of .htaccess rules for this new weblog, which will be added to the .htaccess file at practicalrdf.info (at /home/shelley/www/rdf). These rules will, among other things, define which weblog number the pages belong in, and will also handle redirects for comments, trackback and so on, because the application files for all of these are still back at weblog.burningbird.net.

Both weblogs will be in the same database tables, separated by weblog number, very similar to how Movable Type works now.

From the Command Central page, you select the weblog you want to work in, just like Movable Type, and everything is filtered to that specific weblog. Again, just like Movable Type. The only difference is that there won’t be static pages at the site for the archives.

The basic installation of Wordform will be adjusted to pass weblog number, regardless of whether this extension is installed, so that it can be dropped in with minimum impact. This is the most major change I’m making when moving WordPress to Wordform.

Each weblog will be able to create its own separate wp-content subdirectory, to handle separate photo uploads and plug-ins and themes. However, activation of plug-in and themes is separate for each weblog.

The last Administrative Extension released with Wordform 1.a, is the primary influence for me to fork WordPress, and that’s the Metadata Extension. I want to cover this, very carefully, in a separate post, but for now, briefly, the Metadata extension allows developers to define a new RDF triples based meta-vocabulary, which can then be added to the installation–just as you add a plug-in. The developers will include, as part of the extension, an easy to use form for the weblogger to add data.

As a person adds a new post, they’ll have the option to add the metadata for one, two, or a dozen vocabularies, based on a dropdown box available from the edit page. They could add poetry metadata (’bird’ is used as metaphor for ‘freedom’ in this poem, named ‘ ‘, discussed in this weblog post with URI of _____); podcast metadata; photo metadata; metadata for recipes; geography — any vocabulary that is defined as a ‘metadata’ extension within the Wordform accepted format.

Just like with the feeds now, you can access a page like http://wordform.org/2004/12/comment-spam-prevention-in-wordform/rdf, and get the RDF/XML for all the vocabularies with data defined by the weblogger. Or you can pass in http://wordform.org/2004/12/comment-spam-prevention-in-wordform/rdf/poetry, just to ge the RDF/XML for the Poetry vocabulary defined for the post.

Before the developers assume this is a way for me to sell my RDF book, tools will be provided to make this easy to do for the developers (i.e. they won’t have to ‘learn’ RDF–they should, but they won’t ‘have to’). I’ll also be using RAP (the RDF API for PHP) to manage all the RDF bits.

I have been promising both threadneedle and Poetry Finder for close to three years now. Finally I have the vehicle to deliver on my promises.

More on metadata extensions in Wordform later this next week.