WordPress BugNet – Part One

WordPress BugNet – Part One

Welcome to another series on BetterWP.net where you can find some cool bugs that are either dreadful or hilarious or both at the same time. Each article will consist of five to ten bugs with their descriptions, statuses and possibly their temporary solutions if no patch is available.

This series is intended to help make WordPress bugs become friendlier to users and encourage people to learn more about bugs so they might be able to figure out what’s happening on their blogs. This very first part of the series will bring you five recent bugs that affect some post fields, comment form, taxonomy archives and back-end administration.

1. Using just one password for posts

Password-protected post exposes other protected posts with same password. To reproduce this behaviour, all you have to do is to create two posts with the same password and then successfully access one of them with that password. The other post will be visible to you after that even though you haven’t typed the password for that post at all.

The Causes: WordPress doesn’t handle post-specific password, which means posts with the same password are all visible if one got accessed successfully. This line of code in wp-pass.php proves that just right:

As you can see there is no post ID specified in the password cookie, thus allowing access to all posts with same passwords after one-time successful password input. In my opinion this might be an intended behaviour implemented by WordPress developers rather than an actual bug. It would be better, however, if we have an option to specify whether a password should be used locally (on a per post basis) or globally (on a per input basis).

2. is_tax() is not multi-taxonomy aware

is_tax() only returns true for the first taxonomy. With the ability to use query_posts()1 for multiple taxonomies in WordPress 3.12 you might expect is_tax()3 to adapt the changes made to 3.1 too but it simply doesn’t. For example if you browse to an archive page that lists posts from two taxonomies: ‘author’ and ‘publisher’ using:

author=philip-kotler&publisher=prentice-hall

is_tax('publisher', 'prentice-hall') (the second taxonomy) will return false.

3. Widget ID conflict

Some widgets use hard-coded IDs for HTML mark-ups. The outcome of this is rather obvious: If you want to have two search boxes on one page for example (one inline and one in your sidebar), your website will contain elements with duplicate IDs.

You will then not be able to validate your website with those duplicate IDs around or even worse you might be unable to do some Javascript work based on IDs. If you have ever used the search or calendar widget (or their template functions get_search_form()4 or get_calendar()5 ) you would notice this issue right way.

4. Add a new Category in Add Post screen

‘Uncategorized’ shows up when adding a duplicate category in Post screen. This is a rather minor bug but is worth a look if you often use the ajax ‘Add New Category’button on an ‘Add New Post’ (or ‘Edit Post’) screen. There’s a screenshot taken from the WordPress’s core trac that might help you understand the bug better:

Mysterious 'Uncategorized' category shows up

and to reproduce the bug in details:

The bug is simple to reproduce. Just try to create a category that already exists or something like C, C#, C+, C! etc. (they have to be parent categories). “Uncategorized” is constantly appearing, but nothing is really created (try to click one of those “Uncategorized” and all of them are chosen) and refreshing the page makes them disappear.

5. Extra comment fields not displayed

Logged-in users will not see extra comment fields. If you use the comment_form() function6 introduced in WordPress 3.0.0 you will notice that when you add extra meta fields using the argument comment_notes_before, those fields will never show up for logged-in users.

As stated in comment_form()’s documentation6comment_notes_before is used for users who has not logged in only, so this might not be a bug at all but rather an inconsistency because comment_notes_after can be shown to both types of users. Also noted by a core WordPress developer named westi that all comment_notes are generated for logged out users only

The Causes: The source of this issue can be found easily in wp-includes/comment-template.php: