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.