WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from November, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • Mike Schroder 10:29 am on March 13, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Last Week in WordPress Core 

    Hi there! Welcome to Last Week in WordPress Core for the week of March 3–9. By now, you’ve heard that WordPress 3.9 Beta 1 is available! Thank you for your hard work this last week. Now we’re done adding new enhancements, and on to bugs. Your help is appreciated as we continue to test and squash bugs on the way to a stable RC.

    There are a couple important things that landed on Monday that are not covered in this post, but shipped in beta. Namely, please test the Theme Install screen refresh and the ability to crop headers from within the Customizer.

    Admin:

    • Widgets: Add widget management to the customizer. This brings in the Widget Customizer plugin. [27419] #27112
    • Admin Menu: Introduce a .dashicons-before CSS class and use it in the admin menu. Lets you use a Dashicon before an element without copying the entire .dashicons styling to your :before styling. [27418] [27425] [27444] [27482] #26630
    • Editor: Show “View Post” for any post the author can read. This expands it to private posts and matches the logic in the toolbar. [27483] #27059

    Media:

    • First pass at bringing the Image Editor into the media modal. Please test me! [27445] #21811
    • First pass adding a loading indicator to the Media Library. [27438] #24859
    • Allow $crop in add_image_size() and set_post_thumbnail_size() to receive crop anchors (top, left, right, bottom, center). [27472] #19393.
    • Add subtitle support to Video editing in the Media Modal. [27481] #27016
    • Do not output default gallery styles if the theme has opted into HTML5 galleries. [27396] #27045; see #26697
    • Add a class attribute to the caption shortcode to allow additional classes to be specified. [27404] #25295
    • Add playlist_styles and wp_playlist_scripts filters to allow users to roll their own playlist themes. [27486] #26631 & [27488] #26631

    TinyMCE:

    • Update TinyMCE to 4.0.18. [27387] #24067
    • Add TinyMCE placeholders for audio and video shortcodes and provide a UI to both edit shortcode attributes and replace the src media file in an audio or video shortcode. Also, a flurry of improvements and fixes to them, visible in the full changelog. [27411] #27016
    • Add a Ctrl+K shortcut to open the linking dialog, which is the “de-facto standard”. [27449] #27305
    • Add the <hr> plugin and button to the toolbar. [27428] #27159
    • With drag-and-drop uploading, support multiple editor instances, limit to IE10+, and other small fixes. [27378] [27372] [27464] #19845
    • When parsing a caption shortcode, recreate missing width attributes using the image tag’s width. [27426] #23103
    • Restore the “link” button state to disabled by default and enabled when text or image is selected. Remove the (recently added) default link plugin; not needed. [27447] #27309

    Templates:

    • Add has-post-thumbnail as a post class. [27429] #18804
    • Rename the new page_templates filter to theme_page_templates, and pass it a post object for proper context. [27470] [27471] #13265
    • Introduce get_the_permalink() as an alias for get_permalink(). This better aligns it with other the_* and get_the_* function pairs. [27409] #24164
    • Let get_the_date() accept a post object. [27380] #13771
    • Add the ability to short-circuit wp_nav_menu() via the pre_wp_nav_menu hook. [27386] #23627
    • Better plural handling for labels in wp_generate_tag_cloud() / wp_tag_cloud(). [27376] #27262, see #7989, #14424

    Multisite:

    • Incremental improvements and bug fixes with the multisite load process. Please test your networks! [27406] [27439] [27407] #27003
    • Fix bulk activation of network-only plugins. [27413] #26487

    Query:

    • Add has_password and post_password query variables to WP_Query. has_password true means posts with passwords, false means posts without. post_password can query for posts with a particular password. [27395] #20308
    • Allow a posts_per_rss query variable to be set to override the posts_per_rss option. [27456] [27455] #25380
    • Allow get_page_by_path() and get_page_by_title() to accept an array of post types. [27423] #24763

    Internals:

    • Allow for custom authentication handlers for all requests. Turn the logic used by wp_get_current_user() into a determine_current_user filter. [27484] #26706
    • Allow the role attribute in kses for all elements. [27388] #24098
    • Add a pre_set_theme_mod_$name filter to set_theme_mod(), modeled after pre_update_option_$option in update_option(). [27393] [27402] #14721.
    • Improve HHVM compatibility by eliminating some of our last remaining create_function() calls and making OBJECT a case sensitive constant. [27373] [27374] [27465] #14424 [27377] #27231
    • Pass $reassign parameter to delete_user and deleted_user actions. [27462] [27466] #23057
    • Bail early from shortcode functions if no delimiter is present. It’s the little things; performance results on-ticket. [27394] #23855
    • Update PHPMailer to 5.2.7 from 5.2.4. Includes two trivial modifications for WordPress (no impact to plugin developers); see the commit message. [27385] #25560
    • Use SSL when linking to WordPress.org. [27469] #27115

    For the complete list of commits to trunk, check out the log on Trac. Interested in joining in? Write or test a patch for 3.9.

    Thanks to @adamsilverstein, @akeda, @avryl, @bassgang, @bigdawggi, @bobbravo2, @bpetty, @bradt, @celloexpressions, @coffee2code, @danielbachhuber, @dd32, @DJPaul, @DrewAPicture, @empireoflight, @ericlewis, @ericmann, @frank-klein, @gcorne, @genkisan, @gradyetc, @hakre, @Hanni, @Jayjdk, @jenmylo, @johnregan3, @jorbin, @JoshuaAbenazer, @kadamwhite, @kasparsd, @Kopepasah, @kovshenin, @kpdesign, @lpointet, @markjaquith, @mcadwell, @melchoyce, @michael-arestad, @mikecorkum, @mordauk, @nacin, @obenland, @Otto42, @pavelevap, @Rarst, @rhyswynne, @ricardocorreia, @rmccue, @robmiller, @seanchayes, @SergeyBiryukov, @shaunandrews, @simonwheatley, @sirzooro, @tanner-m, @TobiasBg, @tomauger, @topher1kenobe, @topquarky, @toszcze, @westonruter, @wokamoto, @wonderboymusic, @zbtirrell, and @zodiac1978 for their efforts this week!

     
  • Andrew Nacin 5:31 pm on January 10, 2014 Permalink | Log in to leave a Comment
    Tags: reporting,   

    Brainstorming ticket reports 

    One thing I’d like to work on is improve our reports on Trac with the hope we can better manage the ticket queues. We currently have about 50 reports on Trac. Many of them were created in a push 5-6 years ago to build reports around keywords. A number of others are one-offs created in the last few years for specific use cases. In reality, few of these are ever used on a day-to-day basis.

    I checked the access logs to get an idea of the most popular reports. Besides the first six reports (my favorite “home base” is report 6), they are report 16 (“Needs Patch”), report 18 (“Blockers for Releases”), and report 21 (“Latest Tickets”).

    What I’d like to do is brainstorm all sorts of new reports we should have. How can we make what we have better? I’ll then go to work about implementing them. Dream big — if the data’s there, I’ll figure out the gnarly SQL required. We can also think about how we can improve columns, grouping, ordering, etc. If you have a concept for a report but aren’t sure how we’d query for those tickets, toss the idea out there and maybe someone will add to it.

    I’l probably design a new /report screen so it’s not just a list ordered by something random like when the report was created, and so we can highlight important reports, group similar reports together, and put less emphasis on some of the more specialized ones.

    Here are some half-baked ideas, to start us off:

    • Open tickets without a response. Find all tickets where no one has commented, or where only the reporter has commented. This would create a punchlist of tickets to review. (Ideally, the report should always be empty.) The ability to group or filter this by component would be helpful, for contributors who specialize in and want to take responsibility for different areas.
    • Report of “dead” tickets. Tickets that haven’t been modified in four years are ripe for action and/or closure. We should empty a report of this nature, then reduce it to 3.5 years, then 3 years, etc.
    • Good first bugs. A report of all tickets marked as a good first bug. (None yet, as the keyword is new.) Next steps: How can we best identify these kinds of tickets?
    • Report of “untriaged” tickets. Our milestones have gotten out of hand, which is something we should discuss. Tickets should immediately leave “Awaiting Review” once they’ve been initially reviewed, but then not forgotten about if they are shifted to “Future Release”. Let’s figure out metrics for what makes a ticket “untriaged”. We could create a simple UI to filter by component for a report like this. We currently have Tickets Awaiting Review which groups tickets by the “Version” they were reported against — maybe this is a good start.

    What’s your idea?

     
    • Helen Hou-Sandi 5:35 pm on January 10, 2014 Permalink | Log in to Reply

      Candidates for closure. Not 100% sure what this would look like beyond the “close” keyword (perhaps semi-related to “dead” tickets?), but could be a good report, especially for those getting into Trac gardening. Dreaming big!

      • Andrew Nacin 5:39 pm on January 10, 2014 Permalink | Log in to Reply

        I’m not sure what this would look like either, hence this exercise. :-) Closing out tickets that shouldn’t be open any longer is always a fine idea! The keywords “close”, “2nd-opinion”, “reporter-feedback” are all good for this. Some kind of combination of Needs Reporter Feedback / Steps To Reproduce and Suggesting Close / Needs 2nd Opinion (that’s close to 200 tickets right there).

        Not sure what else — yeah, I’d say it’s related to “dead” tickets. Once “Awaiting Review” is under control again, it could be used to identify the oldest tickets still awaiting review.

    • Andrew Nacin 5:35 pm on January 10, 2014 Permalink | Log in to Reply

      An “intelligent” report on a component. For a particular component, group and order tickets in a way that helps keep the component well-maintained. The first group would be “slated for the next release,” for example. Other groups could include “Tickets awaiting review”, “Tickets more than X years old”, “Tickets needing feedback,” “Tickets with patches,” and (if they don’t fit into another group) “Major bugs,” “Minor bugs,” and “Enhancements.” The report should probably also try to render the component’s ticket graph at the top so we can see changes over time.

      A report like this could be a prime home base for a contributor wanting to clean up and be responsible for a component. What other groups would make sense?

      • Jeremy Felt 6:04 pm on January 10, 2014 Permalink | Log in to Reply

        Somewhat out of scope… is there a way to relate a ticket to other components. When a major effort is taken in Administration, then a report of ‘Multisite tickets that could be affected’ would be interesting.

    • Morgan Estes 5:56 pm on January 10, 2014 Permalink | Log in to Reply

      Not sure what to call it, but something for patches submitted for a release but not responded to by the time of the release freeze. I have a couple like this that I’m unsure of the status (realizing that just because it’s submitted doesn’t mean it’s used), and are in Awaiting Review.

    • Jeremy Felt 5:58 pm on January 10, 2014 Permalink | Log in to Reply

      Along the same lines of dead tickets, I wonder if there’s use in a view of all tickets reported against a version X releases old. These should be ripe for verification as they may have been resolved unknowingly along the way.

    • Andrew Nacin 6:00 pm on January 10, 2014 Permalink | Log in to Reply

      A report of tickets that have a patch uploaded to them no one has replied to yet. We’d do this by finding the most recent patch upload for a ticket, then seeing if there were any comments (by someone other than the uploader) that had been posted after.

    • Jeremy Felt 6:02 pm on January 10, 2014 Permalink | Log in to Reply

      Last modified might take care of this, but “Open tickets without a response in 30 days” or “Open tickets without a response in 2 releases”

      • Andrew Nacin 6:08 pm on January 10, 2014 Permalink | Log in to Reply

        The report of “dead” tickets mostly covers this, I think. But taking it further: perhaps “without a response” are the operative words here. Response from whom? How about open tickets where the last person to reply is the reporter? That tells me they are waiting for a reply from someone else.

        • Jeremy Felt 6:10 pm on January 10, 2014 Permalink | Log in to Reply

          Not sure if we can get fancy with roles, but “without response from a lead developer” or “…from active component person” or “…from bug gardener” or “…from committer” could all be interesting.

          • Andrew Nacin 6:15 pm on January 10, 2014 Permalink | Log in to Reply

            I was just thinking about that. Tickets without a response from any of X individuals is interesting. Of course, Sergey and I mostly cover the spread on that. :-) Maybe tickets where the last person to comment is not one of those people.

            We could probably come up with a way to do this on a per-component basis (so, all multisite tickets Jeremy has never looked at).

    • Andrew Nacin 6:05 pm on January 10, 2014 Permalink | Log in to Reply

      I think there are some good opportunities to highlight “extremes”. For example: Which open tickets have the most comments?

      The most votes isn’t that useful of a metric yet (and also, because it’s mostly just long-standing tickets like post relationships), but what about comparing/contrasting votes and comments? It’s really interesting to see a really long ticket that has almost no interest. #22692 has 67 comments yet just one vote, which tells me it’s a bit of an edge case and a time suck. Compare that with 68 comments but 31 votes on #19393.

      High number of attachments is interesting. So could a ratio of comments to attachments? Dunno. Lots of possibilities here.

    • Drew Jaynes 6:28 pm on January 10, 2014 Permalink | Log in to Reply

      From a docs perspective, it would be lovely to have a report that gathers needs-docs, needs-codex, and docs-feedback together. Right now we have:

      • Report 12 (needs-unit-tests/needs-docs)
      • Report 36 (needs-codex)
      • Report 37 (needs-unit-tests)

      Seems like that would also free up the needs-unit-tests duplication between reports 12 and 37.

      • Andrew Nacin 6:52 pm on January 10, 2014 Permalink | Log in to Reply

        Should needs-docs, needs-codex, and docs-feedback all be different groups on this report? What would they be called? “Needs Inline Documentation”, “Needs Codex Documentation”, “Needs Feedback on Documentation”?

        • Drew Jaynes 7:04 pm on January 10, 2014 Permalink | Log in to Reply

          I’d probably group them separately, yes. And ouch on the verbosity, but I guess that’s probably necessary — we can’t expect everyone to understand Docs == Documentation ;)

          It just occurred to me that there also might be room for including tickets on the Text Changes component. Though text changes kind of serve a different master, it’s all documentation in one form or another in the end.

    • Nick Halsey 6:42 pm on January 10, 2014 Permalink | Log in to Reply

      For Twenty Thirteen and Fourteen development we used a verbose custom query along the lines of https://core.trac.wordpress.org/query?status=accepted&status=assigned&status=new&status=reopened&status=reviewing&component=Bundled+Theme&summary=~Fourteen&group=milestone&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone&order=priority (try searching the #wordpress-themes logs for it, it changed a few times too).

      It would be cool if we could create a report that achieves the same effect, allowing us to select a particular bundled theme’s open tickets.

      • Andrew Nacin 6:50 pm on January 10, 2014 Permalink | Log in to Reply

        I wish I had heard about this. We could have made it a saved report with just a few clicks. :-)

      • Robert Dall 6:53 pm on January 10, 2014 Permalink | Log in to Reply

        Nick beat me to the punch on this suggestion. But a total +1 on that.

        We could name it:

        “Current Default Theme Development”

        Or something like that…

    • Eric Andrew Lewis 6:49 pm on January 10, 2014 Permalink | Log in to Reply

      Some reports are also not 100% accurate, because tickets require a human-touch to change keywords. Sorry to go a bit tangential to this topic, but I’d like to suggest we improve report integrity by adding some automation here. There are a few ways we could approach this, I’ll just give one that’s been on my mind for a while, and I’m sure others’.

      Automated patch cleanliness testing, which could automatically toggle ‘has-patch’ // ‘needs-refresh’ keywords via a bot.

      • Andrew Nacin 6:51 pm on January 10, 2014 Permalink | Log in to Reply

        This is doable! We could have a bot go through and apply the latest patch on a ticket. If it doesn’t apply, we could add needs-refresh. Any other ideas along these lines?

        • Jeremy Felt 6:55 pm on January 10, 2014 Permalink | Log in to Reply

          We could have a bot go through and apply the latest patch on a ticket. If it doesn’t apply, we could add needs-refresh.

          +1withmany0s

        • Andrew Nacin 6:56 pm on January 10, 2014 Permalink | Log in to Reply

          If we did this, I feel we’d have this bot do a few other things too. So, apply the patch and run unit tests, for example. (This would need to be sandboxed. Even applying and reverting patches would need to be done carefully.)

          • Helen Hou-Sandi 6:59 pm on January 10, 2014 Permalink | Log in to Reply

            Was going to suggest running unit tests post-patch. +1 to that.

            • Andrew Nacin 7:02 pm on January 10, 2014 Permalink

              I imagine it would not be too difficult to integrate Travis CI into all of this. @bpetty?

            • Bryan Petty 7:15 pm on January 10, 2014 Permalink

              We could potentially trigger patch builds by scripting up automated pull requests. It’d be a bit of work, but I’m pretty sure this would be easier to do from Jenkins CI. @kurtpayne still has a Jenkins CI setup running, it’s a little out of date (I don’t think he’s actually updated it to use the develop repo still), but he probably has a better idea of how we could automate it.

              http://jenkins.kpayne.co:8080/

            • Bryan Petty 7:18 pm on January 10, 2014 Permalink

              Another option might be to setup a copy of Gerrit working off a git mirror.

            • Bryan Petty 7:29 pm on January 10, 2014 Permalink

              For what it’s worth, MediaWiki uses a combination of both Jenkins and Gerrit, and uses Jenkins bot to make several different checks to automatically sign-off patches in Gerrit. Maybe in our case, just Jenkins + Trac is good.

              Good checks to make can include:

              • PHP lint check
              • CodeSniffer with WP rules (this can be iffy though where existing code base isn’t already entirely compliant).
              • Unit tests
        • Morgan Estes 6:57 pm on January 10, 2014 Permalink | Log in to Reply

          That’s excellent! I’ve wondered how needs-refresh gets applied, and this would be a good addition to the “has anyone seen this yet?” status.

          How would it handle multiple patches in a ticket that deals with multiple fixes for a solution?

          • Andrew Nacin 7:02 pm on January 10, 2014 Permalink | Log in to Reply

            It wouldn’t be able to handle multiple patches, because it wouldn’t know the difference between an old patch (that is stale and has been updated) versus an alternate patch. I think that’s OK, this is definitely better than not having it at all.

        • Helen Hou-Sandi 6:57 pm on January 10, 2014 Permalink | Log in to Reply

          Automatically adding has-patch and triggering the notification for that would be good, since uploading attachments doesn’t. Would probably have to be a little smart about what’s a patch vs. not, but could be cool. False positives would be better than missed patches, in any case.

          • Andrew Nacin 7:22 pm on January 10, 2014 Permalink | Log in to Reply

            It could look around for *.patch or *.diff uploaded and have been there for at least an hour. (If the person is going to comment, we can assume it’d be within an hour.) Then we can check if the report has has-patch. If it doesn’t, we can have a bot post a comment and add has-patch.

            Even if the person has commented, it’s possible they didn’t add has-patch. We could still add the comment in that case. That said, it’s possible their comment is to say “Ignore my patch, that won’t work.” How do you differentiate between a user who didn’t add has-patch accidentally, and a user who didn’t add it on purpose?

            So, new approach. Two different angles. One, a bot that goes around and adds has-patch if the user hasn’t commented with an hour. Two, some JS that looks to see if a patch was recently uploaded by the current user. If it has, it Clippy-prompts the user, letting them know to post a comment and add has-patch.

            Or, we could provide feedback after uploading a patch that tells you to post a comment and add has-patch to the ticket.

            “Hey, you’ve uploaded a patch! Be sure to *add a comment to the ticket*.” And that link will not only take them to the new comment form, but it’ll automatically add the has-patch keyword for them.

        • Mike Schroder 12:52 am on January 11, 2014 Permalink | Log in to Reply

          I really like this idea.

    • Andrew Nacin 6:59 pm on January 10, 2014 Permalink | Log in to Reply

      Needs unit tests. Some contributors may just like writing unit tests. We used to say that a ticket would receive needs-unit-tests until they got committed. But now that tests and src are in the same repository, tests in most cases should be committed with the code they are testing. This is good, but means we need to tweak things a bit.

      So what we could do is this:

      • needs-unit-tests is added to an open ticket. This adds it to a report.
      • Someone writes unit tests. The keyword is removed, and it falls off the report. At some point, the tests are committed with the patch on the ticket, and things are good to go.

      And for closed tickets:

      • A ticket is closed, but it could still benefit from unit tests, so the needs-unit-tests keyword is added. This adds it to the same report, under a separate section probably.
      • Someone writes the unit tests. The keyword is replaced with “has-unit-tests”, and it is moved to another section on the same report saying “Tests Ready for Commit” (which would only list closed tickets with has-unit-tests).
      • Once committed, the has-unit-tests keyword is then removed.
    • John Blackbourn 7:44 pm on January 10, 2014 Permalink | Log in to Reply

      Plugin candidates. Open feature requests which have some comments or CCs but no patch or only stale patches. Candidates for someone to build the feature request as a plugin. Might also give us a chance to close the unwanted ones.

    • John Blackbourn 7:51 pm on January 10, 2014 Permalink | Log in to Reply

      Needs dealing with. Open tickets reported against versions more than two versions old that are marked as high or highest priority, or major/critical/blocker severity. Basically these need dealing with.

    • Aaron Jorbin 9:27 pm on January 10, 2014 Permalink | Log in to Reply

      Kind of off the wall, but I would love a report that scanned all patches to see if they add new JavaScript unit tests so that it was easy to review all potential JS Unit tests.

    • Kurt Payne 2:36 am on January 11, 2014 Permalink | Log in to Reply

      Responding to @Bryan Petty … I haven’t kept jenkins up to date. I do, however, have some scripts that may prove usefulf for this. The idea is this:

      • Create a clean development chroot
      • Check out wordpress, create a database, etc.
      • Apply the patch to the source
      • Run the unit tests
      • Display the output
      • Destroy the chroot

      It still takes a few mins to do, but it’s a very good way to get basic feedback on patches like “does it apply cleanly? does it break unit tests?” Let me know if you want to see. It has not been updated with the latest (3.7) svn layout.

      • Bryan Petty 6:25 am on January 11, 2014 Permalink | Log in to Reply

        As far as that goes, it’s way easier than it used to be with two checkouts, and I did get that all written for our Travis CI config. I just figured you’re much more familiar with Jenkins than I am, and might know how to best configure the build configs, and how to trigger Jenkins on Trac patch uploads. :)

        But I can certainly look into it myself too when I have the time.

    • Kurt Payne 7:16 pm on January 11, 2014 Permalink | Log in to Reply

      @bpetty I can help with Jenkins, sure.

      Travis is probably the best way to go for just unit tests.

      Jenkins is going to be more flexible for things like static analysis tools, customizing reports, integrating with other tools (e.g. Sonar is a popular dashboard), triggering downstream builds, potentially scaling by adding build slaves and potentially adding selenium tests (if wordpress ever has them).

      With regards to the “test the patches” script above … we can talk more offline about it … the important question is: Do we want something that automatically tests patches?

    • Sam Sidler 8:17 pm on January 14, 2014 Permalink | Log in to Reply

      A bit late to the party, but I’ve read through all the comments here and it seems like we have a bunch of good reports already that are hard to find. I think we should redo the Reports page to group together specific reports and make it easier to do specific component queries.

      The specific reports in each section might not be quite right in this mockup, but basically this is what I’m thinking: http://i.imgur.com/R7uNrJo.png

      (Even merged needs-docs, needs-codex, and docs-feedback together for a “Needs Docs Team” report.)

      For certain reports that are a combination of reports (like the Needs Docs Team report), we could easily list out what it includes underneath along with links to those specific reports.

      I’d also want to consider adding a “Open tickets by keyword” option on the right side, similar to the component one.

      All of this should be pretty easy to implement, it’s just a matter of deciding how much we want to round the corners of the boxes. ;)

  • shaunandrews 7:25 pm on November 4, 2013 Permalink
    Tags: ,   

    Widgets Area Chooser – 3.8 Proposal 

    Placing widgets with drag-and-drop can be tedious and annoying — especially if you have lots of sidebars on which to drop widgets. The Widgets team has been working on a few solutions (for this problem, and more), including redesigning the wp-admin widgets interface and adding the ability to manage widgets from within the customizer. These projects are still ongoing, and not ready for 3.8. However, along the way we’ve found a few incremental changes which improve the overall experience of working with widgets. Some of these improvements have made their way into MP6. Others involve more functional changes which don’t belong in MP6. This plugin is one of those improvements.

    The Widgets Area Chooser is available at: http://wordpress.org/plugins/widget-area-chooser/

    The Problem
    Dragging widgets from the available widgets in the top-left, to a sidebar “below the fold” is hard. Almost impossible. Dragging widgets on a touch screen device is also difficult.

    The Solution
    Clicking (or tapping) on an available widget brings up a list of available sidebars that you can place the widget in to — its pretty simple, and works great on touch devices.

    Accessibility
    There’s also the accessibility problems that drag-and-drop introduces, which necessitates the need for the separate (and often neglected) Accessibility Mode. This plugin provides a much easier way for those with screen readers to add new widgets without having to drag-and-drop. In fact, this could be the first step towards removing the need for an Accessibility Mode for widgets.

    Demonstration
    Here’s what the chooser looks like:

    Here’s a quick video of the plugin in action:

    Please let us know what you think!

     
    • william.deangelis 7:37 pm on November 4, 2013 Permalink | Log in to Reply

      Not bad. I assume that on mobile each of those two panels would be its own screen? If that’s the case then I say wicked. Go for it!

    • Jeff Behnke 8:20 pm on November 4, 2013 Permalink | Log in to Reply

      I like it. Solves the problems that need solving in the widget admin.

    • Bryan Petty 8:20 pm on November 4, 2013 Permalink | Log in to Reply

      Just wanted to say that I’m excited that you’re working on this @shaunandrews, and it’s coming along nicely.

      I’m still curious how well this UI handles with 3-5 widget areas, and maybe 50+ available widgets, and what happens with the stored/saved widget settings, but this really is a great start.

      • shaunandrews 1:43 am on November 5, 2013 Permalink | Log in to Reply

        Hey Bryan, thanks for the kind words — I’m super excited to be working on this!

        I think you may be getting the Widgets Area Chooser (WAC) plugin confused with the general layout updates as part of MP6 and the separate widgets project. This post is focused solely on the WAC plugin, which lets you click-to-add a new widget.

    • and0r1995 8:25 pm on November 4, 2013 Permalink | Log in to Reply

      I don’t know, I like the idea and stuff, but I personally prefer the drag and drop, Although when there are a lot of widget areas it’s a bit annoying.

    • Marcus 8:36 pm on November 4, 2013 Permalink | Log in to Reply

      I like this, already an improvement, nicely done!

      Aside from @bpetty ‘s point, another (minor) idea/tweak also is for UX just clicking on the area to place a widget instead of click area > add widget will save a click for non-default widget areas. The cancel button should probably still remain.

      • shaunandrews 1:47 am on November 5, 2013 Permalink | Log in to Reply

        …just clicking on the area to place a widget…

        I thought about that initially, primarily because it was one less new UI element to show on the screen — the widget areas are already there, just let the user click on them to add the selected widget. This caused two problems:
        1) It wasn’t immediately obvious what to click.
        2) It didn’t really solve the problem of the widget area being off the screen.

        If you have an idea on how to make this all better, please don’t hesitate to sketch it out and/or attend our chat on Monday at 20:00 UTC. Your thoughts and feedback is greatly appreciated. Thanks!

        • Luke McDonald 6:25 pm on November 8, 2013 Permalink | Log in to Reply

          My initial thought when trying this out for the first time was I would click on the widget area I wanted and the widget would be added to that area. I was testing on a theme that had 7 or 8 widget locations, which is why I didn’t see the “Add Widget” button below the chooser list.

          That said, for me it was *obvious* what to click, and I think it would be for many others too. It seems this functionality should replicate that of a select menu or your typical drop-down menu. In both cases, once you select an item, an action takes place.

          If it’s not immediately obvious for users the first time, it will be the next time they do it. I think after someone knows how it works, it would be preferred not to have to make an extra click or even scroll down to the “Add widget” button in cases where there are many widget areas.

    • mbootsman 9:17 pm on November 4, 2013 Permalink | Log in to Reply

      Major UI improvement. Thanks for developing this!

      • shaunandrews 1:49 am on November 5, 2013 Permalink | Log in to Reply

        Thanks for trying it — hope you like it. Please let me know if you find any problems, or have any suggestions for improvements.

    • Dan Milward 2:59 am on November 5, 2013 Permalink | Log in to Reply

      Awesome work man. I don’t know why but on one of my test sites the list of available widgets is on the right hand side of the screen instead of the left hand side of the screen. Its pretty weird.

      Also I hope the menus screen gets a similar overhaul.

      • shaunandrews 3:16 am on November 5, 2013 Permalink | Log in to Reply

        Perhaps you’re using an older version of MP6? Can you provide version details for WordPress, MP6, and the Widgets Area Chooser plugin? Also, what browser and OS? A screenshot would go a long ways as well.

    • Grant Palin 5:17 am on November 5, 2013 Permalink | Log in to Reply

      I like it. I’ve found the drag and drop setup a bit finicky before, and the click, click, click seems a usability improvement, especially when multiple widget areas are involved. Plus the UI fits nicely with the MP6 theme.

    • HerrLlama 11:19 am on November 6, 2013 Permalink | Log in to Reply

      I don’t like it. The UI is nice tough, but the usability is … well how could I say it neat? … a piece of crap. Now I drag and drop the widget on the wanted position in the wanted widget area. With this “improvment” I have to click on the widget, then I have to choose the area and than click I have to click the add button. But after all that I have to drag and drop the widget on the right position. Seriously, that makes it more complicate than it could be.

      • shaunandrews 2:51 pm on November 6, 2013 Permalink | Log in to Reply

        You can still drag-and-drop widgets in to place. You don’t have to click.

        • HerrLlama 3:57 pm on November 6, 2013 Permalink | Log in to Reply

          Yes, I already read this, but your proposal is a way more to confuse the users. WordPress itself said that they wanted to implement decisions, not options. It would help if we don’t work on the frontend for the widgets and create an API (e.g. add_widget_to_sidebar( $widget_type, $sidebar ) or stuff like that) which actually works.

          I agree, that the UI needs some improvements, but there are plenty of different screens of editing things (tags, posts, menus, widgets, options, etc) which also confuses the users. I think we should focus on a consistent backend before we implement new things. If not, I think that is a major problem of WordPress. Have you ever been to a Typo3 backend? Everything looks like it is in one pour.

          And also: Sorry for beeing rude, but I’m german ;)

      • Helen Hou-Sandi 3:20 pm on November 6, 2013 Permalink | Log in to Reply

        As @shaunandrews noted, this does not replace drag and drop; it provides an alternate method for those who can’t or don’t want to drag and drop for whatever reason. Also, you are being rude, and that is unnecessary.

      • Matt Thomas 6:19 pm on November 7, 2013 Permalink | Log in to Reply

        I would recommend re-reading the original proposal. Managing widgets is currently not possible on a mobile device because drag-and-drop is the only supported method of adding or removing widgets.

      • PeterRKnight 4:17 am on November 8, 2013 Permalink | Log in to Reply

        drag and dropping a position vertically is easy (on desktop), the issue with the current widgets screen that this improvement solves is about making it much easier to add widgets to widget areas without having to do acrobatics. Try dragging and dropping a widget on a screen that requires scrolling because there’s so many widgets and so many widget areas. This however is a major usability improvement for desktop as well as mobile.

    • bfintal 2:08 pm on November 11, 2013 Permalink | Log in to Reply

      I like it. This would solve the drag and drop problem in mobile versions also.

      This is just me, but a method of duplicating a widget would be helpful.

      • shaunandrews 2:46 pm on November 11, 2013 Permalink | Log in to Reply

        Yup, part of the goal with this was to improve the experience of adding widgets on mobile.

        This is just me, but a method of duplicating a widget would be helpful.

        This isn’t the first time I’ve heard this request, so you are not alone. :)

      • Weston Ruter 6:20 pm on November 11, 2013 Permalink | Log in to Reply

        Regarding duplicating a widget, there is this Duplicate Widget plugin and there is the Clone Widgets plugin. The former does a shallow-copy/symlink/reference for the widget, and the latter seems to do a clone or deep copy of the widget. Which use case are you interested in? Do these plugins do what you want?

  • George Stephanis 5:11 pm on October 23, 2013 Permalink
    Tags: , , ,   

    Omnisearch / Global Admin Search, Final Pitch 

    Plugin: http://wordpress.org/plugins/omnisearch/
    Diff: https://cloudup.com/cC6IbXxoHXN

    Previous posts:

    http://make.wordpress.org/core/2013/08/14/present-your-3-8-feature-idea-at-tomorrows-meeting/#comment-9948

    http://make.wordpress.org/core/2013/08/30/omnisearch/

    http://make.wordpress.org/core/2013/10/08/omnisearch-user-testing/

    IRC chats in #wordpress-core-plugins:

    http://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-08-30&sort=asc#m21304

    http://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-09-12&sort=asc#m23506

    http://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-09-19&sort=asc#m24911

    http://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-09-26&sort=asc#m25942

    http://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-10-10&sort=asc#m27386

    We were a small, but scrappy group. It was mostly myself, @japh, and @lessbloat.

    Omnisearch currently adds three ways to search.

    • A Dashboard Widget:
      Omnisearch Dashboard Widget
    • An admin page under the Dashboard:
      Omnisearch Admin Page
    • And as a search box on  the adminbar — when you’re on the admin side of the site:
      Omnisearch Admin Bar

    All three turn up the same results page:

    Omnisearch Results Page

    And all is happy with the world.

    We were trying to solve the proliferation of different search forms for different data structures in the admin.  When trying to find content, it’s inconvenient and difficult to always navigate to the right data structure and then search it — especially if you’re unsure if something was in a comment or a post (all too frequent in p2s)– and you just want to pull in all relevant results.

    Other things we’d considered were potentially adding an Alfred-like pop-up modal where you could enter omnisearches, and see results from the menus on the page that happen to match — very much like WP Butler’s current functionality.  We opted not to add it in this pass, though, figuring better to keep a slimmer implementation.

    Our user testing confirmed that this was a definite win.  In fact, the user even remarked that there should be a centralized search when we had them running through the initial steps where they were to search each data structure independently, before activating Omnisearch and seeing how that compared.

    We’re eager to hear any feedback on code, methods, or even name.  I’ve had some people mention that they’d prefer it have a less ‘marketing’ name, and more of a generalized “Global Admin Search”.  I prefer Omnisearch for brevity, but would love to hear some discussion on the pros and cons of whether it would be better to use a more general name.

     
    • Andrew Nacin 6:43 pm on October 23, 2013 Permalink | Log in to Reply

      My suggestions on UI: The search tool in the toolbar is very likely sufficient placement for this. Drop the dashboard widget and the menu item. Add a “Search everywhere” link to each individual search results page in the admin, next to “Search results for “%s”. There’s no reason to force this onto people — just let it be naturally discovered in times of need.

      If no results are found for a section, it may be okay to omit that section entirely, rather than showing an empty table and taking up 100+ vertical pixels. If no results are found at all, it could just be a simple single line of feedback, rather than scrolling through a bunch of empty tables.

      Is the “Search Pages” button/link helpful? They see all of the results here (presumably with pagination). Maybe clicking the name of the section should take them to that particular page (with the search conducted) to allow for filtering and such. Otherwise, it seems like clutter.

      I see that plugins is searchable, along with posts, pages, and media. What about themes? Custom post types? Taxonomies? Settings? Importers? Admin screens & keywords? Etc. (A lot of this came up with @markjaquith was kicking around this exact idea a year or two ago.)

      My suggestions on naming: simply call it “search”. When discussing it in code, call it an admin search or the dashboard search or whatever. “omnisearch” sounds like (and, in Jetpack, is) a gimmicky product name. There’s no need for a tagline. “Search” is a pretty natural and common feature; let it speak for itself.

      Will note that comments are also searched on P2s. Would be more interested in hearing additional use cases for this. I think a lot of it comes down to increasing uses of custom post types. As of right now, since it only supports posts/pages/comments/media/plugins, it’s not really “everywhere” yet.

      I think the feature implementation is pretty close for core — certainly could be smoothed out over the course of a merge.

      • George Stephanis 7:25 pm on October 23, 2013 Permalink | Log in to Reply

        My suggestions on UI: The search tool in the toolbar is very likely sufficient placement for this. Drop the dashboard widget and the menu item. Add a “Search everywhere” link to each individual search results page in the admin, next to “Search results for “%s”. There’s no reason to force this onto people — just let it be naturally discovered in times of need.

        Good call. Depending on how DASH goes, if it ever migrates to a fixed column of static stuff like in this older mockup, it may be worth including this there as a search field. The primary reason for all the avenues was to have them available, then pare them down in the merge.

        Agreed on sacking the widget and probably the menu item. I’m not sure if it would make more sense to have the menu item there if you’re on that page at the time, but hide it if you’re not? Or if that would be confusing from a UX perspective.

        If no results are found for a section, it may be okay to omit that section entirely, rather than showing an empty table and taking up 100+ vertical pixels. If no results are found at all, it could just be a simple single line of feedback, rather than scrolling through a bunch of empty tables.

        I’d prefer the line of feedback, it might play nicer with results sections that load in results after dom.ready via js for latency reasons.

        Is the “Search Pages” button/link helpful? They see all of the results here (presumably with pagination). Maybe clicking the name of the section should take them to that particular page (with the search conducted) to allow for filtering and such. Otherwise, it seems like clutter.

        Actually, just to keep it short, it only displays the first five results (adjustable via a filter) (and possibly would be wise to have customizable in Screen Options). To dig deeper into a given section they need to click the link for that specific section. This also avoids a large degree of confusion as to results page refreshes when paginating — which list table is it paginating? They all use the same query argument!

        A potential down-the-road enhancement would be to enable pagination via js on specific tables, but for the moment, it’s just capped at five.

        I see that plugins is searchable, along with posts, pages, and media. What about themes? Custom post types? Taxonomies? Settings? Importers? Admin screens & keywords? Etc. (A lot of this came up with @markjaquith was kicking around this exact idea a year or two ago.)

        Themes could be, I excluded it initially, as it seemed to me to be a much more infrequent task.

        Custom post types aren’t included by default, as they can have such disparate data structures, that forcing them into a single custom list table may not end well. They’re easy to include, though, like so: https://gist.github.com/georgestephanis/6926206

        Taxonomies, settings, and importers are all feasible, this is just the baseline that was felt to be most useful to the most people, while still keeping the UI reasonably simple. We could always offer them, but have them hidden by default in Screen Options. If that’s the consensus, I’ll add them in.

        My suggestions on naming: simply call it “search”. When discussing it in code, call it an admin search or the dashboard search or whatever. “omnisearch” sounds like (and, in Jetpack, is) a gimmicky product name. There’s no need for a tagline. “Search” is a pretty natural and common feature; let it speak for itself.

        Maybe Global Search then. There’s so many searches in the admin already, that a ‘Search’ label without context could be more confusing than helpful.

        • Raam Dev 7:32 pm on October 23, 2013 Permalink | Log in to Reply

          Maybe Global Search then. There’s so many searches in the admin already, that a ‘Search’ label without context could be more confusing than helpful.

          I also vote for ‘Search’. Putting ‘Search’ on the Dashboard tab provides the necessary context and helps indicate that we’re not searching any one particular section but rather the whole site.

    • Sam Sidler 6:48 pm on October 23, 2013 Permalink | Log in to Reply

      A few questions:

      • What was the rational for putting Omnisearch under “Dashboard” in the admin? Not saying it’s the wrong place, just curious if other places might make more sense, especially since it’s permanently located on the top right of the admin interface.
      • Why only show the search box when you’re on the admin side? Other than “Edit Post”, it would be the only thing that changes between admin side and not.
      • Related: Why show the entire box instead of just a search icon? Whoops, I realized I misunderstood this. :)
      • Does this search custom post types? I’d take off the “search everything” tagline if it doesn’t search literally everything.

      Otherwise than those questions, looks like good work. I’m on the side of Omnisearch being a bit too gimmicky, but would love to hear what others think.

      • George Stephanis 7:32 pm on October 23, 2013 Permalink | Log in to Reply

        RE: under Dashboard in the admin, it’s legacy that I worked up initially. In Jetpack, it’s under the Jetpack menu item, but when merging it into WPCOM, I didn’t have that available, and put it under Dashboard. I’m not particularly attached to it, and would be happy to drop it from the menu as mentioned above.

        RE: why only the admin side, that was because the search in the admin bar is already there on the front-end, and I didn’t want to change that form’s behavior. If other folks would rather have adminbar search be Omnisearch at all times, I’m fine with that as well — we’d just need a fallback or capability check if logged out users had it displayed to them.

        RE: CPTs: It can, I had just intentionally left them off initially due to the disparate data structures they can represent, with the bulk of it potentially in postmeta — I wasn’t sure how well it would search them, and if displaying them in the list table would look in any way reasonable or representative of what they’re storing.

        • Sam Sidler 7:53 pm on October 23, 2013 Permalink | Log in to Reply

          RE: why only the admin side, that was because the search in the admin bar is already there on the front-end, and I didn’t want to change that form’s behavior. If other folks would rather have adminbar search be Omnisearch at all times, I’m fine with that as well — we’d just need a fallback or capability check if logged out users had it displayed to them.

          It feels like strange behavior for the search icon in the admin bar to have two different behaviors, depending on the view. I’d be interested to see what user testing would say on that. Easy enough to change anyway.

          RE: CPTs: It can, I had just intentionally left them off initially due to the disparate data structures they can represent, with the bulk of it potentially in postmeta — I wasn’t sure how well it would search them, and if displaying them in the list table would look in any way reasonable or representative of what they’re storing.

          I think they should get included, but you said above (and showed!) that it’s not hard to add. Perhaps we can wait for feedback post-merge.

    • Bryan Petty 7:20 pm on October 23, 2013 Permalink | Log in to Reply

      As far as the admin bar search goes, what are your thoughts about the fact that there is already currently a search bar on the admin when browsing the frontend on a site, which pulls up the regular search results page on the frontend. I know you’ve stuck with keeping the search on the frontend the same as it is now, but do you think that behavior should change for an admin/editor/author? How might that be affected by roles and capabilities?

      @sams Does your theme you tested with this not have search?

      Also, not just “gimmicky”, but I think calling it “Omnisearch” instead of just “search” is actually detrimental once it’s considered the official built-in search functionality (as opposed to begin able to identify it as an add-on provided by Jetpack).

      Also, I get this fatal with the plugin (with *multisite* WP trunk):
      “Fatal error: Call to undefined function wp_is_mobile() in /home/bryan/Projects/wordpress/src/wp-content/plugins/omnisearch/omnisearch-core.php on line 14″

    • memuller 5:11 pm on October 24, 2013 Permalink | Log in to Reply

      About the name, I think just “search”, as nacin suggested, might work.
      @georgestephanis, while I agree that it may be confusing given the presence of many “search” functionalities, I believe that’s an issue with the other search functionalities, not with this one. Since this search will be the de-facto admin search – that is, it will be enough in most cases – it makes sense for its name to be just “search”. The “global” here is unnecessary – the name “search” should be reserved to the most general and useful case possible, and this plugin is that case. Aditionaly, “global” implies the existence of more types of search – which is the case, but the user does not need to be exposed to that confusion so early.

      The issue, them, is to make sure that all other search functionalities are named differently; that all instances of “[custom post name] search” or “theme search” are always named in such way as to make clear that they are more limited in scope or functionality.

      Omnisearch is inadequate for the same reasons – the name won’t be a selling point for this feature, so a descriptive, simple name wins. That name would – for example – be a pain to I18N teams.

      Otherwise, this is awesome – it will greatly help finding stuff in huge sites; and the API for including custom posts is looking good. I really hope to see this on 3.8.

    • George Stephanis 9:01 pm on October 24, 2013 Permalink | Log in to Reply

      Okay, got two changesets in just now.

      http://plugins.trac.wordpress.org/changeset/793194/omnisearch
      http://plugins.trac.wordpress.org/changeset/793196/omnisearch

      To-accomplish yet, based on feedback from above:

      • Drop the table output from empty result sets.
      • Add in the links to “search globally for %s” to the end of the normal archive tables when a search has been performed.
      • ???

      Current version is 0.9, installable from http://wordpress.org/plugins/omnisearch/

    • Gregory Cornelius 7:35 pm on October 27, 2013 Permalink | Log in to Reply

      Nice work.

      I wasn’t exactly sold on the idea initially, but seeing the search a bit more tightly integrated with the admin UI instead of just hanging out under Dashboard, its potential is starting to emerge. UX-wise I sorta wish that the results were more unified and less of a direct reflection of the data schemas. Perhaps, all post-like content could be combined into a single group in a manner not unlike how search results are handled in the Link modal in the visual editor. It would also be nice if the results could be re-ordered by clicking the table headings or maybe even experiment with removing the headings.

      Thinking about the search field, I wonder if some sort of autosuggestion of results built from matches on post titles across post types with a “Show All Results” link at the top of the list. This would make the dashboard feel a lot more responsive for power users that are used to using search tools like Spotlight, Alfred, Quicksilver, or even the new Window 8 thingy. Eventually, I could even imagine the results including the results from the content of the various admin screens, especially the settings. It would be kind of neat if searching “Disable comments” included a link to the Discussion Settings.

      Maybe the search bar could also be integrated into the new DASH dashboard if/when that component is integrated. And, as the tool becomes more refined and useful, I think it would be nice if the field somehow became a bit more prominent in the admin bar. At the very least, it would be nice if the animation to open the field was a lot faster.

    • George Stephanis 8:37 pm on October 27, 2013 Permalink | Log in to Reply

      Just upped the plugin again. Posts/Pages are now decended from the WP_Posts_List_Table class, which lets a lot of stuff like custom columns and displaying taxonomies work out of the box. I’m about to auto-include custom post types as well, if their UI is exposed in the admin.

      Also switched it so it displays a blurb, instead of an empty table, if there’s no results. Also skips the link to search that data type in more depth if there was no results.

    • sandeepbagchi 7:48 am on October 31, 2013 Permalink | Log in to Reply

      Is it possible to add filters for searching?
      Date Search: “Search To And Search From”
      Search In Category: dropdown with multiple selection
      Search In Posts or Search In Pages or Search In Available Custom Post Types (drop down with multiple selection)

      After taking all the inputs a query can be formed to refine the search?

    • Sarah Gooding 8:02 pm on November 11, 2013 Permalink | Log in to Reply

      Is it possible to include an auto-suggest while typing and load results via AJAX instead of whisking the user away onto another page – similar to how it’s done in the http://wpjarvis.com plugin (see demo on that page)? This seems like a more elegant implementation. I understand that there’s a lot of data to show in the results but if there was any way to make it more compact I think the experience would be improved. Of course, I may be missing a lot of the complexity involved here…

  • Andrew Nacin 6:58 pm on September 10, 2012 Permalink
    Tags:   

    Trac updates and a design refresh 

    Every few months we make a few improvements to Trac. Given how many hours so many of us spend on there, even the smallest changes can make a big difference. Today, a few new changes were deployed.

    The first thing you’ll notice is a design refresh, from @helenyhou and @ocean90. It cools down the colors a bit and places more of our own mark on it (more WP-like, less Trac-y). They also added responsiveness for mobile devices, and made some adjustments to improve readability. See #18211. If you notice any bugs or quirks, please leave a comment there.

    From @iammattthomas, the WordPress logo is now HiDPI.

    If you’re a bug gardener (i.e. you can change milestones, etc.), you can now change the resolution of a closed ticket. This should make @sergeybiryukov happy — no more re-open to re-close.

    Over the last few weeks I’ve given more than a dozen people bug gardener status. We’d like to empower the people we know and trust to make decisions, while making Trac simpler for others.

    For those who aren’t bug gardeners, we’re trying to make it as easy and streamlined as possible for you to create and contribute to tickets. @bpetty has been studying our workflow and recommending changes. One of those is we’ve hidden the ability to change ownership of a ticket (accept/assign/reviewing). A big issue with ownership is it sometimes discourages others from contributing. I hope this change can free us up to using that field for tracking responsibility and accountability.

    Non-gardeners can also no longer label tickets a “task”. Also, once the Version field is set, a user can’t update the field to a newer version, only an older one. (As @sergeybiryukov says, “version number indicates when the bug was initially introduced/reported.” It’s the earliest known affected version for a bug, or the earliest applicable version for an enhancement.)

    And finally, if you add the “has-patch” keyword to a ticket, “needs-patch” will automatically be removed, and vice versa. (It’s the little things.)

    I hope you enjoy this round of changes. If you have any further suggestions, please share in the comments.

    Bonus. A few weeks ago, we added a ticket graph, inspired by jQuery and using their plugin as a base. I hope to add some more functionality to this in the future. For now, a few of us are using it to study trends and come up with some new ideas for how we can best maintain the ticket queues.

     
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