I cooked up a patch that allows to setup…

I cooked up a patch that allows to setup a multisite installation on localhost, albeit only for subfolder installations.

A possibly related niggle that I ran into while installing a test site was #12459. If your database prefix is empty as well, you’ll need that patch as well.

The primary purpose of these two is, obviously, to allow developers to use the MS functionality without needing to constantly go back and forth with a server using SSH or FTP.

Please give both patches some testing so we can get both checked in before we’re in beta. Doing so will give the new MS functionality a lot more exposure to testers.

#featured-bugs

Taking advantage of UUIDs

Now that we require MySQL 4.1.2, we can look into using UUIDs in WordPress.

Universally unique identifiers are numbers that are unique in time and space. In the database world, they’re primarily used in order to work with data that is created in a decentralized manner. It allows to characterize a piece of data that isn’t stored in the database yet, to merge data from separate databases without needing to work around ID conflicts, etc.

The lack of genuine UUIDs introduces all sorts of quirks in the WP editor when we’re dealing with yet to be saved posts. #9471, #10456, #11145, #11990, and many more underscore the architectural problem that we’re facing. The media-related tickets exacerbate the issue.

Mark recently opened #11889 and suggested that we a) always create a new post when hitting the new post button, and b) have a garbage collector clean things up periodically. It is a solution, but I feel that using UUIDs — which were designed to deal with this kind of stuff — would be simpler.

Using them would mean pre-assigning a UUID to new posts, and placing it in a hidden field. Since this UUID characterizes our yet to be saved post, we can safely pass it around to an autosave handler, a media thickbox, etc., allowing to create the post on the fly when necessary.

Further down the stream, we introduce a slight change in our insert/update post handler: when saving a post whose ID is not assigned yet, we start by verifying if that post exists already — by querying the posts table’s post_guid field to know if that UUID exists.

#featured-bugs

I’m inaugurating a new trac keyword, “…

I’m inaugurating a new trac keyword, “bug-hunt”, and the bug hunt report, in order to keep track of of tickets that get posted/could get posted in this blog’s “bug hunt” posts.

Updated: I’m inaugurating a new trac keyword, “featured”, and the featured bugs report, in order to keep track of of tickets that get posted/could get posted in this blog’s “featured bugs” posts.

I’ll be tagging more tickets in due course. You’re most welcome to mark additional tickets as such, if you feel they qualify.

For information, I try to stick to batches of tickets that loosely interfere or interact with one another. The batch of tickets should then meet the two or more of following criteria:

  • It is annoying when you run into the issue
  • It underscores an architectural problem
  • Fixing it can lead to performance optimizations

Areas I plan to highlight in the future include: UUIDs, i18n post slugs, permalinks, rewrite rules, cache, private posts.

Btw, I’d like to stress that the point in these blog posts is try to reverse the WP bug trend:

Open WP bugs, props Hakre

Thus, I’d like to revisit two of my last post’s tickets:

  1. #10779, on optimizing our unzip method. DD32 committed the fix, but marked it as still needing testing. Here’s how. Related ticket #10403 is still pending, but I feel it’s extremely minor compared to #10779.
  2. #10913, on optimizing the upgrade process, is still a major niggler imo. #10611 will probably seem cosmetic if #10913 gets fixed. Two possible solutions are highlighted in the ticket’s comments. It still needs a patch, and of course testing once one is around.

We need your help on both, and on future tickets that will make it in these posts. Thanks for patching/testing.

#bugs, #featured-bugs

So… Jane had asked me to come up with …

So… Jane had asked me to come up with a post now and then that discusses bug squashing. Between the Health Check plugin, chewing on the best way to do this, and noting that our lead devs were quite busy already because of the merge and custom post types, I had yet to start.

The opportunity comes courtesy of Matt’s latest wp-devel post. So here goes… If you’re wondering how you might be able to make the best of DD32’s new contributor status, here’s a selection of WordPress niggles that could use patches, second opinions, and of course lots of testing:

1. #11588 is about actually showing a message to end users during core upgrades. There are occurrences where the host enables an output buffer automatically. When this happens, end users a greeted with a partially loaded screen that can seem to wait forever. Status: ideas submitted for force-flushing, and needs-patch.

2. #10779 is a huge source of grief on overcrowded, low-end servers. Our unzip method is slow and resource hungry, and could use some optimizations. (See also #10403 on the same topic.) Status: needs-testing.

3. Another possible optimizations for these same servers would be #10611. The idea would be to only upgrade the files that changed, when upgrading minor releases. Status: needs-patch.

4. #10913 highlights the reason why failed upgrades are such a source of grief. When using the FTP transport, file stats don’t get cached, and so we end up needing to re-check the status of each of them constantly. On the slower servers, the optional clean up + unzip + upload + clean up procedure frequently fails because of it. The whole process could be optimized by caching $fs::is_file() and $fs::is_dir(). Status: needs-patch.

5. #8830 loosely relates to the filesystem, but definitely seems to cause grief for users with an open_basedir restriction in effect. From the looks of it, a simple rtrim() call could fix wp_mkdir_p() on those system. Status: needs-testing.

6. #10889 highlights inconsistent methods between the WP Filesystem methods. I’m 90% sure that it prevents the .maintenance file from being added on some sites. Status: commit?

And that’ll be the last of today’s pick of crippling install/upgrade bugs. Please keep in mind that this is the first of a hopefully long series of posts. Feedback is welcome on the way it gets presented. Should it be more focused on less specific bugs, less focused but on more bugs, less focused on less bugs, or is it reasonably balanced as above?

Next in line, I think, will be a post that discusses the use of UUIDs to fix a couple of tickets, along the lines of #11145. Now that we’ve MySQL 4.1.2, we might as well take advantage of them.

#bugs, #featured-bugs