We had two copies of the edit link form that were only trivially different.  One lived in link-add.php and the other in link-manager.php.  These two copies are now consolidated in edit-link-form.php.  Knock about 200 lines off our TLOC.

I moved most of the link management code into functions. Here’s what we have:

• get_link() – Fetches a link object from the DB
• get_link_to_edit() – Fetches link object and formats fields for editing
• add_link() – Creates a new link from form POST data
• edit_link() – Updates an existing link with data from POST
• wp_insert_link() – Creates a new link in the DB
• wp_update_link() – Updates an existing link in the DB
• wp_delete_link() – Deletes a link from the DB

The code to change visibilty and set attributes for all links in a category needs to be broken out as well.

Link categories need a similar treatment.

How are the new rewrite rules in 1.6 working for everyone? We’ve been running with them for months now and haven’t received any bugs about them for some time.

1.6 adds a minimal set of rewrite rules to htaccess. These rules pass on the rewrite duty to WP itself. Here’s an example of what they look like:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php

This is a nice, compact set of rules that has the advantage of not requiring updates whenever a page is added. htaccess needs to be writable only when it is first populated.  WordPress handles rewrite and 404 duties.

For those who want the low-low-down on WordPress development, I’ll be blogging about the gory day-to-day details over at my wordpress.com site. I’ll stick punch lists, running commentary on commits, and development head-scratching over there while continuing with the higher level WP Commit Digests here at boren.nu. I also intend to outline some areas of the code that need to be cleaned up or reviewed so that those interested in helping with some of the smaller development chores can take on some tasks that will help them get their feet wet in the WP core.

• Add API for link and link category insert/update/delete
• Give some love to wp-mail.php
• Give some love to wp-links-opml.php
• Convert functions in admin-db.php to cap system
• Move some DB functions from admin-functions.php to admin-db.php
• Streamline public facing include path
• Add DB rev?
• Audit DB upgrade from 1.5.x
• Importers, Importers, Importers

Last week was primarily bugfix week. I went through Trac clearing out bug reports and applying patches.

The big commit of the week was Andy’s One-click blogger importer. Very nice. While he was working on Blogger, I tackled the RSS importer. As we rework the importers, we’re finding places where we need to add API to make creating and manipulating posts, categories, authors, and other elements easier. Importers should not have to make direct queries or do any heavy lifting. As a result of the importer rework, we have introduced about a dozen new API calls and eliminated quite a bit of messy duplication. The user system has especially benefitted. Check out this changeset. Consolidating and deleting code feels good.

There is still a lot of importer work to do. I would like to be able to point the RSS importer at a feed URI and have it slurp everything into WP, for example. We’re getting there.

That’s it for this week.

The latest round of commits includes a couple of nice admin UI changes as well as the usual bug fixes and code cleanups.

First we have some cool AJAX list manipulation courtesy of Michael Adams. When you delete a post, comment, or category from a list, the entry fades from the list and disappears. No page reload is necessary, making deletes much quicker. If you have a wordpress.com blog you can see this in action. Go delete something.

Matt cleaned up the profile page, making it much easier to read. The layout of the profile page always bothered me a bit. I’m glad to see it get some love.

After a long discussion on the hackers list about posting being too slow due to ping and enclosure processing, Owen resolved the matter by queueing up ping processing for later handling so that post creation doesn’t have to wait around for pings to finish. Creating new posts that need to ping should be much quicker now.

I applied a bunch of patches folks had kindly submitted and updated xmlrpc.php to use the latest capabilities methods. Nothing exciting. Hey, someone has to do the not-at-all-sexy, no-AJAX-involved dirty work.

That’s all for this week.