This is the second post in the WordPress Bugnet series, in which I will list another five WordPress bugs that have not been fixed in recent versions of WordPress, along with their statuses and workarounds if available. Make sure you check out the first post, too!
By reading this series, you might be able to figure out if something’s wrong with your blogs, and hopefully, fix it without the need of a bugifx release from the WordPress team. In this article, you will find a post type bug, a post contents’ bugs, a redirection bug as well as two administration bugs.
1. Unexpected behaviour of the ‘Page’ post type
All pages on your site can be listed just like posts by simply adding a query variable.
To reproduce this, try adding
?post_type=page to the end of a URL, preferably right after the domain, and you will get an archive page of all your WordPress pages.
Is this really a bug, or is it just another extremely cool but hidden feature? Of course it is a bug, because the page post type has
'has_archive' => false, which basically means that there should be no archive page for this post type (“A very unexpected behaviour”, said Scribu).
Note that, however, the archive page will not show up if you don’t use WordPress’s internal post query, i.e. you use
query_posts() with your own arguments. So, if you browse to ?post_type=page, you will still see my normal homepage, but if you use Twenty Ten (not Eleven), you will see a nice archive page of WordPress pages.
The Causes: Misuse of
publicly_queryable when a post type is registered (some knowledge about
register_post_type is required).
Trac Ticket: http://core.trac.wordpress.org/ticket/17040 (status: has patch, fixed in 3.2)
2. Creating usernames with dots
An inconsistency in handling usernames with “.” between “Network Admin → Users → Add New” and “Site Admin → Users → Add New”.
You will need a Multi-site installation of WordPress to actually see this bug. If you try to add a new user in your normal site admin page, you will not be able to use dots in username, but this is entirely possible if you’re in the network admin page.
The Causes: This bug is caused by an inconsistency in the sanitization function used between normal and network admin page. In normal admin,
wpmu_validate_user_signup() function is used to validate user data, while in network admin, the script only checks for empty username and email.
Trac Ticket: http://core.trac.wordpress.org/ticket/17239 (status: has patch, fixed in 3.2)
3. Invisible form field text in Dark OS themes
Form field text is rendered invisible when you use a dark OS theme (such as HumanLogin theme included in Ubuntu).
If you use the above mentioned theme, for example, you will not be able to see the text you type into a lot of form fields (as shown in the screenshot below – provided by the bug reporter).
Invisible Input Text
The Causes: Some input fields have the CSS rule
background-color: #ffffff; hard-coded into them, so when the dark OS theme change the text color to white, the fields’ background color is still white, thus making the input text invisible.
Trac Ticket: http://core.trac.wordpress.org/ticket/11645 (status: no patch, need feedbacks)
4. Formatting functions and WordPress Shortcodes
WordPress’s formatting functions can mangle shortcodes with block-level HTML markups and special characters.
To tell the truth, this is a very old bug but up until now it still hasn’t been addressed, and I’m pretty sure that a lot of WordPress users have run into this bug at least once.
To reproduce, you can use this shortcode:
function bwp_copyright($atts, $content = '')
along with this text in your post’s contents:
Please cite this website if you copy any contents.
In case you do not want to; please "contact" us at ...
The output will look perfectly fine to the innocent eyes of your visitors, but perfectly messed up for some source-demanding ones:
Please cite this website if you copy any contents.<br />
In case you do not want to, please “contact” us at …<br />
wpautop() and other WordPress formatting functions is filtering the shortcodes’ contents, in an I-do-not-know-what’s-inside way. As suggested by the bug reporter, if the shortcode mechanism has some sorts of pre-filtering methods, i.e. let those formatting functions know how they should react to the contents of the shortcode, then the problem can be solved.
Workaround: If you have been following my blog for some time, you would know that I had already written an article about protecting shortcodes’ contents from wpautop and the likes. Check that out for a not-so-simple workaround.
Trac Ticket: http://core.trac.wordpress.org/ticket/12061 – This trac ticket only addresses the
wpautop() function, but I couldn’t find a better one. (status: no patch, no milestone set)
5. No 301 redirection for certain post permalinks
A 301 (Moved Permanently) redirection is not applied to some nice permalinks.
When you use certain kinds of pretty permalinks for your blog, including (but not limited to)
/%postname%/%post_id%, WordPress will not automatically redirect something like
http://example.com/100/post100-slug/ or something like
This behaviour can actually be reproduced by having more dashes (and probably other characters) between words in your permalinks. For example, if you have a post name like ‘this-is-a-slug’, a request to
http://example.com/2011/07/03/this-is-a----slug/ will not be redirected to
The bad thing is, this URL will have a 200 OK HTTP status, which can result in duplicate content.
The Causes: It seems that when WordPress parses a request, it does not check for these kinds of permalinks, and the
redirect_canonical() function also doesn’t seem to handle them either.
Workaround: Although this sounds like a pretty serious bug, you don’t have to worry about it because a
<link rel='canonical'> is still added to your page’s
<head> section, thus probably making your page duplicate-free for some popular search engines out there.
If you, however, still want to make sure that the post is redirected correctly, I suggest that you try a patch by dd32 in the first trac ticket below and see if it works for you. I did test that patch and it worked for me (using WordPress 3.1.3).
That’s it, guys! Have fun reproducing these bugs and trying all possible patches and workarounds, at your own risk ;).