Divi WordPress Them — the smartest and most flexible WordPress theme

Back to Top

WordPress BugNet – Part Two

Previous Post:

WordPress BugNet – Part Two

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

White text in white background

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:

  1. add_shortcode('copyright', bwp_copyright);
  2. function bwp_copyright($atts, $content = '')
  3. {
  4.     return "<div>$content</div>";
  5. }
add_shortcode('copyright', bwp_copyright);
function bwp_copyright($atts, $content = '')
{
	return "<div>$content</div>";
}

along with this text in your post’s contents:

[copyright]
Please cite this website if you copy any contents.
In case you do not want to; please "contact" us at ...
[/copyright]

The output will look perfectly fine to the innocent eyes of your visitors, but perfectly messed up for some source-demanding ones:

  1. <div><br />
  2. Please cite this website if you copy any contents.<br />
  3. In case you do not want to, please &#8220;contact&#8221; us at &#8230;<br />
  4. </div>
<div><br />
Please cite this website if you copy any contents.<br />
In case you do not want to, please &#8220;contact&#8221; us at &#8230;<br />
</div>

The Causes: 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) /%post_id%/%postname%/, /%postname%/%post_id%, WordPress will not automatically redirect something like http://example.com/100/ to http://example.com/100/post100-slug/ or something like http://example.com/post100-slug to http://example.com/post100-slug/100.

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 http://example.com/2011/07/03/this-is-a-slug/.

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

Trac Ticket:

That’s it, guys! Have fun reproducing these bugs and trying all possible patches and workarounds, at your own risk ;).

Print Article Trackback Trackback to this Article   Subscribe to Comments RSS Subscribe to Comments RSS

One Opinion for WordPress BugNet – Part Two (1 Trackback)

  1. - Immobiliare Roma

    [...] WordPress BugNet – Part Two – Better WordPress betterwp.net/268-wordpress-bugs-20… - Stati Uniti - Traduci questa pagina [...]

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: