Back to Top

WordPress BugNet – Part One

Previous Post:

WordPress BugNet – Part One

Welcome to another series on 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:

// 10 days
setcookie('wp-postpass_' . COOKIEHASH, $_POST['post_password'], time() + 864000, COOKIEPATH);

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).

Trac Ticket: (status: has patch, no milestone set)

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:


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

The Cause: is_tax() still relies on get_queried_object():

function is_tax( $taxonomy = '', $term = '' ) {
	global $wp_query, $wp_taxonomies;

	$queried_object = $wp_query->get_queried_object();

Our $queried_object here only contains data for the first taxonomy.

Possible Solution: Use a WordPress plugin named Query Multiple Taxonomies in addition with one of its functions: qmt_get_query(), as stated here: ... ag-problem.

Trac Ticket: (status: no patch)

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.

Trac Ticket: (status: no patch – no solution yet)

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

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.

linuxologos – Comment on the ticket

Trac Ticket: (status: has patch)

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 documentation6 comment_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:

<?php if ( is_user_logged_in() ) : ?>
	<?php echo apply_filters( 'comment_form_logged_in', $args['logged_in_as'], $commenter, $user_identity ); ?>
	<?php do_action( 'comment_form_logged_in_after', $commenter, $user_identity ); ?>
<?php else : ?>
	<?php echo $args['comment_notes_before']; ?>
	do_action( 'comment_form_before_fields' );
	foreach ( (array) $args['fields'] as $name => $field ) {
		echo apply_filters( "comment_form_field_{$name}", $field ) . "\n";
	do_action( 'comment_form_after_fields' );
<?php endif; ?>

Don’t try to move the highlighted line though, you might break other thing if you did.

Trac Ticket: (related: #14510) (status: no patch)

Feel free to post any feedbacks and questions, I appreciate them!


  1. ... uery_posts []
  2. []
  3. []
  4. ... earch_form []
  5. ... t_calendar []
  6. ... mment_form [] []

Take Social Sharing to
the Next Level with Monarch!

Take Social Sharing to the Next Level with Monarch!
Print Article Trackback Trackback to this Article   Subscribe to Comments RSS Subscribe to Comments RSS

2 Opinions for WordPress BugNet – Part One (1 Trackback)

  1. User's Gravatar
    jerry January 23, 2012 at 10:41 pm – Permalink

    Oh, the ID issue on some of the widgets really annoyed me! Thanks for finally clearing that one out.

  1. WordPress BugNet - Part Two - Better WordPress

    [...] of WordPress, along with their statuses and workarounds if available. Make sure you check out the first post, [...]

Speak Up Your Mind!

An asterisk (*) indicates a required field and must be filled.

  • Web page and e-mail addresses turn into links automatically.
  • Wrap codes in: <code lang=""></code> or <pre lang="" extra="">
  • Lines and paragraphs break automatically.

Next Post: