From WordPress to Wordform

I feel a strong urge to work on code, I’m not sure why. Perhaps it’s because code is something I can wrap my hands around…and throttle the heck out of it.

Note if you’re not a tech, much of the following is still going to be of interest if you use or plan to use WordPress. Including some gotchas.

Since I’m basing Wordform as a fork of 1.3, I’ve been looking carefully through the 1.3 code changes in the CVS repository. That’s the beauty of open source projects that post their files in a publicly accessible directory – you can reverse engineer the code, while it’s still being developed. And since I’m used to deducing functionality from code in process (which is how I wrote most of those 14 or so computer books I was involved in), I can see the directions the tool is taking. I’m finding some interesting stuff out for those of you using WordPress or moving to WordPress 1.3.

For instance, it looks like by default ,Wordpress does not provide a link in the sidebar for RSS 1.0 or Atom; it only provides links to RSS 2.0. I can’t help thinking a better option would be to provide all the links to the popular syndication feeds, and then let the people delete as needed. It’s easier for non-techs to remove an option, than it is to add an option.

It does have Atom, as well as RSS 2.0 and .92 as options in the header for autodiscovery. I would think that it’s time to drop .92 and put RSS 1.0 in, instead. But that’s just me.

Of course, you’ve probably heard about the new WordPress split of the original index.php page into multiple pages consisting of wp-footer.php, wp-sidebar.php, and so on. There’s an interesting caveat to this, in that the application looks for a user-defined page, such as sidebar.php. Only if this isn’t found, is the wp-sidebar.php page used, instead.

This is a good design decision. By doing this, when you update your WP files, you’re not overwriting your customized work. But my goodness there is a lot of files, now. I would think a better approach would be to put the default WordPress sidebar, footer, etc into a separate sub-directory–to beging to clean out the home directory. This is going to be even more critical if people choose to have different category and archive and individual pages.

There’s also a new template/theme system. I know that people can use functions to hide and show pieces of data based on a single page request versus multiple, and so on – but this isn’t intuitive for the non-tech. It would seem that the WP developers agree with me, because the new template system now defaults in favor of category, archive, date, and author individual pages and so on in the template directory if they exist–rather than feed all requests through index.php

In other words, if you’re using a custom template, such as I am at Kitchen, which is based on Gemini, and you create separate pages for individual, category, and so on entries, the system now defaults to these without you having to screw around in .htaccess.

So, for Burningbird now, I have a category.php, archives.php, individual.php, insert.php, and fulltext.php custom pages. I could create a template theme directory, call it ‘burningbird’ and drop these files into it (after first updating to 1.3 code), and I would no longer have to worry about adjusting the .htaccess entries for these items, like I do now.

Better, if I decide to impulsively switch to another theme and style, I could do so just by dropping that themes/template files on to my server, push a button on the admin page, and off I go with a completely different look and set of pages, with no code changes.

Yes, yes, you’re nodding your heads at this. You like this. Trust me, you do.

There is a slight, teeny performance hit by doing redirection in code rather than in the .htaccess. But I believe it would be negligible. Agree? Disagree?

The blog header file, which you’re not supposed to touch, has been cleaned up enormously. Now I just have to find all the bits of the code that are no longer in the file, because I have modified it.

Ouch, though! The developers are splitting DIV open and close tags across files – opening in one file, closing in another. This is going to bite people in the butt when the start to customize the pages to their look and feel.

The main index page is, of course, cleaned up considerably since much of the content for it has been split off. A basic page would have:

-Include the blog header file (for all the data query and redirection, should not change)
-Include the header file (for CSS and autolinks and that sort of thing – HEAD stuff)
-The actual post loop is kept in index.php
-Include comments template file
-A call to a function to do the NEXT and PREVIOUS post links
-Include the footer file, which includes the sidebar

The NEXT and PREVIOUS link thing is when you have more than 20 posts (or whatever count you set, in admin I believe), from a category list or archive or search, you get the next and previous links that allow you to ‘page’ through the results. Yes, this is very tasty, you’ll want this.

The comments code isn’t much changed, though I read at the 1.3 wiki about using a weighted means throttle to keep from being crapflooded with hundreds of comment spam. Hmm, will have to see. I like mine, and it works nicely. As for the rest of the code, I’ll be replacing much in the comments because I support per-post moderation, and the WordPress developers just won’t buy into this. This was one major architectural difference between the WP team and myself.

Moving on, looks like they’ve worked on and hopefully fixed the trackback and pingback problems.

In the admin files, they’ve done a lot of splitting here, too. From the wiki, it looks like 1.3 may be opening up for administrative customizations. Curious how this will work. They have removed the geo stuff from the administrative pages, and it’s being moved to a plug-in. Now this is a goodness. Most people don’t use the geo stuff, and cluttering up the admin pages with stuff that could be a plug-in is an improvement.

Still nothing on that mysterious Dashboard page. Will this end up being a placeholder for future expansion? Something dropped in at the last moment, to have people going ‘ooo’ and ‘aaaah’?

Over into the wp-includes, the engine of the tool, I found the following CVS check in comment attached to a file: Don’t forget to strip. So, don’t forget to strip when you use WordPress.

There’s a lot of clean-up in the code, and I’m really pleased to see functions that are going to be deprecated commented with the fact. What deprecated means is that the function isn’t going to be used in future versions, and is just included now so that people have at least one release in order to adjust to the function being dropped. With this, hopefully your 1.2 customizations won’t break in 1.3 (though they will in 1.4 if you don’t clean your own code up).

There’s a new class called ‘retrospam_mgr’, which I assume is focused on ‘death to all spam’ efforts.

All in all, there’s a goodly amount of cleanup and separation of data access from processing, and processing from presentation – a good three-tier split in the code. This will make it really easy to modify the code.

I am going to yank that damn convert_smilies function. Smilies are evil.

Going over to the hackers archive, I can see that there’s discussion about allowing person to replace the comment checking functionality with their own, which is a good idea – for technologists. But then, I could create a function to do my automatic moderation on posts over a week old, and you could just plop the code into your installation, and get the same functionality without having to touch code. So the idea is a win/win. I wonder if they’ll go this route.

There’s a new ’static’ page option in 1.3, which allows you to create pages such as an about page and so on that fall outside of the normal chronological flow. I used my insert post status for this, and to me, this makes more sense. In other words, don’t duplicate the same form, provide more statuses.

Anyway, this shows in the version of 1.3 we’re using at Kitchen, but doesn’t work in the version of code we have (which is a couple of weeks old).

A great deal of discussion about multiple blog support and how this is necessary for it to be considered a true CMS. I am curious – why do people think that a CMS is a multiple blog setup? There are things one can do by author and by category that could support much of the CMS functionality. So, why do people want multiple blogs, and how would they use them? I know how I used them, but I don’t think this is the same as how other people use them.

Ut oh, there’s the enclosure thing. For non-technical people, podcasting.

The two options listed, if I’m reading the mailing list entries correctly, are to provide a field, just like with trackback, that adds the enclosure to the RSS feed. Or to skim the HTML and pull out links to media automatically. (See options in thread). It looks like the decision was to automatically wrap all URLs within the post as enclosures in RSS.

Hmmm. Can’t be reading that right. I’ll have to grab the nightly and test this one, and write about it individually. This one makes no sense.

I would still need my modifications, including my anti-spam mods, my individual comment moderation, my post statuses, full text, comment editing, like comment preview, and full page preview for the editor.

For new stuff – well, I want to take a shot at adding in some more meta capability, including the Poetry Finder. I’ve always felt that the only want something like this could work, is if it gets added on to other tools. This will give me a chance to find out. The key is, being able to add sophisticated meta data such as what would be needed for Poetry Finder, but allow a person to specify their own vocabulary and map it to the data. Or choose not to have it at all.

However, you all don’t care about what I plan to do, only when I’ve done it. In the meantime, I hope this little code review of WP 1.3 has been of interest.