The upgrade to MediaWiki 1.4 continues to struggle, as implementation of new features is aborted and bugs in previously working features remain to be fixed. A number of fixes were in the works, as developer Brion Vibber announced the experimental release of a fourth beta version early Saturday prior to the final public release, but some problems still persist.

The ability to mark edits on Recentchanges as being checked by a reader, a long-awaited feature that would reduce the redundancy involved in RC patrol, was shut off again Thursday after developer Tim Starling enabled it for a trial run. In the few days that it was available, users checking the diff of a change could mark it as "patrolled" by clicking a link on the diff page. Unpatrolled changes showed up with bright exclamation marks on Recentchanges and were highlighted in yellow on Newpages.

As it turned out, a number of people struggled to figure out the new feature and wondered whether it would really work out. Quite a few observed that hardly anybody seemed to be actually using it.

Additionally, the way the system was set up, a change could only be patrolled once, and users could even patrol their own edits. In fact, there was no way to know who had checked an edit or evaluate whether the patrollers were themselves trustworthy.

Starling criticized it as a flawed feature and said, "I'd rather write my own from scratch." Pcb21 was more hopeful but commented, "I think the little exclamation marks are going to have to appear on watchlists too before this will really take off." But in spite of the potential to help improve Wikipedia's review processes, the feature was deactivated again, and will presumably get an overhaul before we see it in action again.

Running some statistics after the experiment shut down, developer Jamesday determined that fewer than one percent of all edits had been marked as patrolled. Newpages, which contains a substantial amount of Wikipedia's garden-variety vandalism, was patrolled somewhat more often at eight percent, but this reporter's experience suggests that the real amount of patrolling done on Newpages is significantly higher. As might be expected, anon edits were checked with greater frequency than those of logged-in users.

Meanwhile, automated logs of activity such as uploads and deletions have undergone a conversion to act more like page and contribution histories, although some functionality was missing. More seriously, however, the software change has broken the blocking feature—or, as it might be more appropriate to say, the unblocking feature.

This bug or collection of bugs has several manifestations, the most serious of which is that when an admin sets a block to expire at a given time, the block nevertheless does not expire. Instead, the user account or IP address stays blocked until it is unblocked manually.

The problem is compounded by the confusing situation on the block log and list of active blocks, neither of which is displaying properly. The block log fails to indicate when any of the blocks are supposed to expire, making it of little use in determining which blocks are ready to be undone.

Expiration times are available by checking the list of currently active blocks, but due to an additional malfunction, the list has to be used carefully so as not to make mistakes. A number of blocks are deliberately set indefinitely, with no expiration time, but the list, which used to indicate these properly no longer does so. Instead, at various times it has shown indefinite blocks as expiring either at the precise time the list is being viewed by the reader, or at the time the block was initially implemented. Thus, an admin going through the list to reverse expired blocks must sort through this incorrect information to avoid undoing a valid block.

The developers are aware of these problems, but due to other issues connected with the software upgrade, as well as the basic work needed to simply keep the site operational, haven't been able to fix them as yet.