WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: bugs Toggle Comment Threads | Keyboard Shortcuts

  • Denis de Bernardy 2:48 pm on January 23, 2010 Permalink
    Tags: bugs,   

    I’m inaugurating a new trac keyword, “bug-hunt”, and the bug hunt report, in order to keep track of of tickets that get posted/could get posted in this blog’s “bug hunt” posts.

    Updated: I’m inaugurating a new trac keyword, “featured”, and the featured bugs report, in order to keep track of of tickets that get posted/could get posted in this blog’s “featured bugs” posts.

    I’ll be tagging more tickets in due course. You’re most welcome to mark additional tickets as such, if you feel they qualify.

    For information, I try to stick to batches of tickets that loosely interfere or interact with one another. The batch of tickets should then meet the two or more of following criteria:

    • It is annoying when you run into the issue
    • It underscores an architectural problem
    • Fixing it can lead to performance optimizations

    Areas I plan to highlight in the future include: UUIDs, i18n post slugs, permalinks, rewrite rules, cache, private posts.

    Btw, I’d like to stress that the point in these blog posts is try to reverse the WP bug trend:

    Open WP bugs, props Hakre

    Thus, I’d like to revisit two of my last post’s tickets:

    1. #10779, on optimizing our unzip method. DD32 committed the fix, but marked it as still needing testing. Here’s how. Related ticket #10403 is still pending, but I feel it’s extremely minor compared to #10779.
    2. #10913, on optimizing the upgrade process, is still a major niggler imo. #10611 will probably seem cosmetic if #10913 gets fixed. Two possible solutions are highlighted in the ticket’s comments. It still needs a patch, and of course testing once one is around.

    We need your help on both, and on future tickets that will make it in these posts. Thanks for patching/testing.

     
    • Ryan 6:59 pm on January 23, 2010 Permalink | Log in to Reply

      It would be interesting to see the trend for enhancements/feature requests. Currently, 53% of open tickets are enhancements and feature requests.

    • DD32 10:54 pm on January 23, 2010 Permalink | Log in to Reply

      I’m wondering if ‘bug hunt’ is the correct term for these.
      Historically Bug Hunt days are testing a heap of bugs and/or patching them..
      The criteria hardly relates to what Bug Hunts used to be (not to speak of them in ast tense, but its been a little while). So i’m wondering if its going to confuse some people, Its not a bug hunt, its just tickets which you see as annoying, or a possible optimization – Many of the latter is not something most people can even attempt to look at.

      For a start, #10611 is neither a bug, nor does it have a patch, So whilst it’s a performance thing, Its not something that most people should be told to test..

      As for #10779 however, I need to know who its failing for, and what kind of server setup they have.

      I’d like to see Bug Hunts left to things that end-users can attack and test, and make sure works for them before being commited (Or testing the commited code still works for them)

      • Denis de Bernardy 3:44 pm on January 24, 2010 Permalink | Log in to Reply

        Fair enough. Would you find the keyword “featured-bug” more appropriate?

      • Denis de Bernardy 4:13 pm on January 24, 2010 Permalink | Log in to Reply

        I changed it to “featured”

        • Jane Wells 2:54 pm on January 25, 2010 Permalink | Log in to Reply

          The word Featured has a lot of connotations in terms of official endorsement and promotion (featured plugins, etc), which we currently already have in trac with the keyword “blessed.” If the point of the tag is that you are asking for the bug to be given a higher priority, a more appropriate tag would be “denis” or “please-look” or something that is more specific.

    • Andrew Ozz 12:23 pm on January 28, 2010 Permalink | Log in to Reply

      Looking at the chart above: there were a lot of fixed bugs/closed tickets for 2.8 and at the same time it had more problems than either 2.7 or 2.9. So it seems “more tickets closed” equals more problems at release.

      Going through the currently open tickets with patches marked as bugs, lots of them introduce some sort of architectural change (no matter how small) which eventually breaks something else. Even tickets marked as “tested, commit” have usually been tested only for the problem described in the current ticket and potentially introduce new bugs.

      In that terms I agree with DD32: a “bug hunt” should be a lot less of “patch a bug” and more of “test the patch for a known bug” and leave a comment on the ticket about what was tested and how. Having a list of patches to start with may work but generally most patches need this type of testing.

    • Matt 6:15 pm on January 28, 2010 Permalink | Log in to Reply

      Looking at the chart above: there were a lot of fixed bugs/closed tickets for 2.8 and at the same time it had more problems than either 2.7 or 2.9. So it seems “more tickets closed” equals more problems at release.

      I am in violent agreement with this comment.

      • hakre 6:34 pm on January 28, 2010 Permalink | Log in to Reply

        Take note, that the graph does not differ between actual bugs and features as Ryan already correctly pointed to. So Andrew Ozz sentence you violently agree with could be written this way as well:

        “So it seems “more features implemented” equals more problems at release.”

        Just to show the picture.

  • Denis de Bernardy 12:57 am on January 13, 2010 Permalink
    Tags: bugs,   

    So… Jane had asked me to come up with a post now and then that discusses bug squashing. Between the Health Check plugin, chewing on the best way to do this, and noting that our lead devs were quite busy already because of the merge and custom post types, I had yet to start.

    The opportunity comes courtesy of Matt’s latest wp-devel post. So here goes… If you’re wondering how you might be able to make the best of DD32′s new contributor status, here’s a selection of WordPress niggles that could use patches, second opinions, and of course lots of testing:

    1. #11588 is about actually showing a message to end users during core upgrades. There are occurrences where the host enables an output buffer automatically. When this happens, end users a greeted with a partially loaded screen that can seem to wait forever. Status: ideas submitted for force-flushing, and needs-patch.

    2. #10779 is a huge source of grief on overcrowded, low-end servers. Our unzip method is slow and resource hungry, and could use some optimizations. (See also #10403 on the same topic.) Status: needs-testing.

    3. Another possible optimizations for these same servers would be #10611. The idea would be to only upgrade the files that changed, when upgrading minor releases. Status: needs-patch.

    4. #10913 highlights the reason why failed upgrades are such a source of grief. When using the FTP transport, file stats don’t get cached, and so we end up needing to re-check the status of each of them constantly. On the slower servers, the optional clean up + unzip + upload + clean up procedure frequently fails because of it. The whole process could be optimized by caching $fs::is_file() and $fs::is_dir(). Status: needs-patch.

    5. #8830 loosely relates to the filesystem, but definitely seems to cause grief for users with an open_basedir restriction in effect. From the looks of it, a simple rtrim() call could fix wp_mkdir_p() on those system. Status: needs-testing.

    6. #10889 highlights inconsistent methods between the WP Filesystem methods. I’m 90% sure that it prevents the .maintenance file from being added on some sites. Status: commit?

    And that’ll be the last of today’s pick of crippling install/upgrade bugs. Please keep in mind that this is the first of a hopefully long series of posts. Feedback is welcome on the way it gets presented. Should it be more focused on less specific bugs, less focused but on more bugs, less focused on less bugs, or is it reasonably balanced as above?

    Next in line, I think, will be a post that discusses the use of UUIDs to fix a couple of tickets, along the lines of #11145. Now that we’ve MySQL 4.1.2, we might as well take advantage of them.

     
    • miqrogroove 1:34 am on January 13, 2010 Permalink | Log in to Reply

      I’m looking forward to your next post because there’s a reliable cure for remote upgrades: manual upgrades. On the other hand, bugs like #11145 are a disinsentive to upgrade at all. Fixing them also has the benefit of making patches that usually work on older versions. That’s just as important for those of us who absolutely cannot upgrade to the 2.9 branch until plugin authors catch up with the core devs.

    • miqrogroove 1:35 am on January 13, 2010 Permalink | Log in to Reply

      Good lord, what has happened to my avatar….

      • miqrogroove 2:48 am on January 13, 2010 Permalink | Log in to Reply

        Apparently wordpress.org, wordpress.com and gravatar.com were using 3 different e-mail addresses for me. I think it’s straight now. Back to sunny Robert again.

    • Ryan 7:29 am on January 13, 2010 Permalink | Log in to Reply

      This is entirely off-topic, but just wanted to mention that it’s awesome you guys are allowed to post on here. It’s making it a lot easier to track what’s going on behind the scenes at WordPress.org.

      • Matt 7:30 am on January 13, 2010 Permalink | Log in to Reply

        Happy to open this up more, if someone wants posting ability just ask, and link to your WP.org profile showing your Trac contributions.

    • Andrea_r 1:19 pm on January 13, 2010 Permalink | Log in to Reply

      This is actually presented quite nicely in a reasonable chunk of related items. I like it.

    • Ryan McCue 2:23 pm on January 13, 2010 Permalink | Log in to Reply

      I have to say, I love the line “FWIW, the suggested patch doesn’t flush hard enough.” :)

    • Jane Wells 3:18 pm on January 13, 2010 Permalink | Log in to Reply

      My only suggestion would be to limit it to no more than 3 per post, in order to keep it short enough that it feels like it will only take a minute to open them and respond. Thanks for doing this!

  • Mark Jaquith 4:36 pm on July 21, 2008 Permalink
    Tags: bugs, , ,   

    Permalinks with the structure /index.php/%postname%/ (or the same, without the trailing slash) now work. And now the tag/category bases are normalized to have no leading/trailing slash, so it’ll just be topics or tagged for example.

     
  • Mark Jaquith 5:04 am on April 24, 2008 Permalink
    Tags: , bugs   

    Nailed that lame bug that would redirect you to the preview URL after your first post save (but only sometimes).

     
    • Danny Novo 12:03 pm on April 24, 2008 Permalink | Log in to Reply

      Thank you! That was so irritating, and so hard to describe, too. Pesky. But now you say it is gone, and I am happy.

  • Mark Jaquith 9:16 pm on April 16, 2008 Permalink
    Tags: bugs, ,   

    With the help of AaronCampbell, the shortcode HTML issues have been fixed in a flexible way. Now add_shortcode() takes a third (optional) parameter that allows you to have your shortcode be expanded after wpautop() and texturize() are run. Default is before for compatibility with 2.5. For “block-level” shortcodes, you should probably make them run after. For “inline” shortcodes, you should probably make them run before.

    Update: We went a different way with this, for the time being. Now everything runs at 11, but shortcodes with a buffer line separating them from other content will be recognized as block level and won’t get paragraph-wrapped.

     
  • Ryan Boren 6:05 am on April 16, 2008 Permalink
    Tags: bugs,   

    Fixed an ugly bug that broke page links for setups that use PATH_INFO permalinks with %category% at the beginning of the permalink structure.

     
  • Mark Jaquith 4:03 am on April 3, 2008 Permalink
    Tags: , bugs, , , html,   

    Making good progress on shortcode (galleries included) parsing and handling. 2.5.1 will run after wpautop(), so shortcode plugin authors will be able to output block-level HTML without WordPress mangling it or wrapping your divs in paragraphs. The rabbit hole goes deeper, however, as the Visual Editor does funky stuff with extra whitespace in shortcodes.

     
  • Peter Westwood 9:39 pm on March 13, 2008 Permalink
    Tags: bugs,   

    fixing little bugs, commiting patches

     
  • Peter Westwood 3:17 pm on February 16, 2008 Permalink
    Tags: bugs,   

    trawling through tickets, applying patches, punting new features to 2.6

     
  • Ryan Boren 8:48 am on February 9, 2008 Permalink
    Tags: , bugs,   

    Ticket 5797 needs attention. AJAX link category creation.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel