Make WordPress Core

Updates from Helen Hou-Sandi Toggle Comment Threads | Keyboard Shortcuts

  • Helen Hou-Sandi 5:29 pm on September 17, 2015 Permalink |

    For those who don’t follow along with Make/Design and are interested in exploring some UI/UX ideas and projects, I just posted a few possibilities as a prompt of sorts. There are a number of needs, from strategy to interface design to front-end build to whatever back-end changes need to happen to support. None of those projects currently have active owners, so if you’re interested or if you have any ideas of your own, shout in the comments.

  • Helen Hou-Sandi 12:57 pm on August 28, 2015 Permalink |
    Tags: ,   

    And the other guest committer for 4.4 is… 

    Now that he’s back from holiday, please join me in welcoming @afercia as a guest committer for the 4.4 release cycle! Andrea (pronounced the proper Italian way) has been invaluable with the huge strides the accessibility of WordPress has taken over the past several releases, lending his experience with accessibility methods and software and tenacity in iterating on patches. He’s also contributed many patches outside of accessibility changes as he’s gotten to know various parts of core. We’ve had a hard time keeping up with all of his work in such an important area of web development, so it’s our pleasure to hand him a set of reins to keep it going.

    In core Trac, we have many components and a number of what we’ve come to call focuses. Focus areas include things such as accessibility, UI, and JavaScript, and span multiple components, if not all of them. Building up expertise and trust in a component or focus is critical to maintaining WordPress over time. Commit access is a wonderful thing, but even as committers, we rely heavily on the recommendations of component and focus maintainers to keep tickets and patches moving. Without them, we’d get a lot less done. Andrea is a shining example of how this flow can dramatically improve a specific area of WordPress in a relatively short period of time with continued plans for improvement, and we want to see more and more of this happening. If you’d like to get started with maintainership, please join us in the #core Slack channel and ask about it.

    Congratulations, @afercia!

  • Helen Hou-Sandi 7:00 pm on August 26, 2015 Permalink |
    Tags: ,   

    New committers for 4.4! 

    It’s that time again… Please join me in welcoming Tammie Lister (@karmatosed) as a guest committer for WordPress 4.4. There’s another committer to be announced, but we thought we’d wait until he’s back from vacation for a proper welcome.

    You may recognize Tammie from her role as an admin on the theme review team, and she’s also a theme developer extraordinaire at Automattic. Tammie will be heading up development of the new default theme, Twenty Sixteen.

    The lead developers review and appoint new committers to serve each release cycle, often to work on a particular component or feature. This guest commit access comes up for review after each release and can be renewed. Ella Van Dorpe, Konstantin Obenland, and Weston Ruter, all new committers at the beginning of the 4.3 cycle, have been renewed for 4.4.

    Over the last few cycles, both Aaron Jorbin and Jeremy Felt have been working through long-term plans, smashing through tickets, and improving the entire codebase, especially when it comes to tests and multisite. I’m happy to announce that both are now permanent committers. Please join me in congratulating everyone!

  • Helen Hou-Sandi 1:35 pm on August 20, 2015 Permalink |
    Tags: ,   

    8/20 UI Chat Agenda: 4.4 

    After a few weeks off from regular meetings while the final touches were put on 4.3, let’s have our weekly UI chat, today at 17:00 UTC. Inspired by @wonderboymusic‘s call for 4.4 wishlist items, let’s talk today about what our bigger projects are in the world of UI and UX, what our wishlist items are, and what we can reasonably target for 4.4.

    • chriscct7 5:47 pm on August 20, 2015 Permalink | Log in to Reply

      I think it’d be interesting to look at https://core.trac.wordpress.org/ticket/22959#comment:29 if someone’s interested in working on it

    • David Lingren 7:42 pm on August 20, 2015 Permalink | Log in to Reply

      I’d like to know the status of Ryan Boren’s “Retiring media-new.php” proposal (https://make.wordpress.org/flow/2015/01/29/retiring-media-new-php/).

      In addition to the browser uploader, media-new.php offers a number of hooks that allow plugin developers a way to extend its functions.

      My plugin, Media Library Assistant (https://wordpress.org/plugins/media-library-assistant/), adds a form below the drag-and-drop area on the Media/Upload New Media screen. The form allows users to set defaults for standard fields, taxonomy terms and custom fields that are applied to items as they are uploaded. It uses the ‘upload_post_params’ and ‘post-upload-ui’ hooks provided in media-new.php.

      I have not developed an alternative approach to this feature that works in the grid view or Media Manager Modal Window (MMMW). I have found it very difficult to extend grid view and MMMW, and I am concerned that a media-new.php replacement will have similar issues.

      I hope you will think through and meet the needs of plugin and theme developers in any media-new.php replacement effort. Thank you for your consideration.

      • Ryan Boren 5:05 pm on August 21, 2015 Permalink | Log in to Reply

        I replied over here. I updated that post with screenshots of media-new.php + MLA. At the moment, this is just a proposal I’ve been shopping around. It has some interest, but I don’t know if it will get developer time during 4.4

  • Helen Hou-Sandi 2:18 am on August 8, 2015 Permalink |
    Tags: , ,   

    List table changes in 4.3 

    List tables are a significant component of the WordPress admin, powering screens such as for posts, comments, and installed plugins. Its internals have not changed much since the introduction of WP_List_Table in 3.1, and visually has only significantly changed with the introduction of smaller screen responsive considerations in 3.8. In 4.3, we’ve improved list tables on both fronts, including API enhancements to support the front-end changes.

    Better small screen responsive mode

    In 3.8, list tables were made “responsive” by hiding columns as the viewport got narrower. While content truncation is a common responsive design approach, it is not a good one. Users who have a higher likelihood of being bandwidth limited, such as on phones, now have to load a second screen to see data that is potentially important for making what should be an initial decision as to what to do next. We also already have the data in markup going to waste, as well as an impossible-to-maintain set of CSS selectors hiding columns by name and then unhiding them in specific list tables. This strategy required developers to include custom CSS if using columns with the same names as core ones or if a custom column was more important than what core was showing by default.

    Now, we show all the data under a toggle, showing only the bulk selection checkbox (when available) and a designated primary column by default. Screen option settings are honored, though setting them is not actually available on smaller screens right now. Check out the demo below, and read on for more about API changes.

    4.3 List Tables Demo

    4.3 List Tables Demo

    Primary column and row actions

    We’ve done a lot of work to provide a fallback primary column for custom list tables, as without one defined, list tables will suddenly look empty. Developers are able to specify a primary column via the list_table_primary_column filter, which receives the screen ID as context. This primary column is also where row actions are placed.

    For example, if you’ve added a column for a slide image to a slide custom post type and would like for it to be the primary, it is now a matter of a simple filter. Previously, you would have needed to recreate the row actions in PHP and add custom CSS to ensure it did not disappear on smaller screens. As of 4.3, your code might look like:

    function wpdocs_slide_list_table_primary_column( $column, $screen ) {
    	if ( 'edit-slide' === $screen ) {
    		$column = 'slide';
    	return $column;
    add_filter( 'list_table_primary_column', 'wpdocs_slide_list_table_primary_column', 10, 2 );

    Note that primary columns should typically be the first column after the checkbox. From a user perspective, it is best to keep the placement of the most important identifier of an item and its actions consistent. Specifying other primary columns will work, but may result in some visual breakage in the small responsive view when a row is toggled open. We are tracking how that may be handled on #33308.

    Easier subclassing of WP_List_Table and other list tables

    While WP_List_Table was designed for internal usage and didn’t make many considerations for custom subclasses, we recognize that developers use them and that clean up would benefit both implementations and future maintenance. The internal WP_List_Table classes now all call ->single_row_columns() in ->single_row() properly, which makes subclassing them significantly easier. Previously, ->single_row() in each WP_List_Table subclass contained a giant switch statement. In most cases, this was unnecessary. By calling ->single_row_columns() when rendering a row, the class will look for a method on the class inheritance chain called ->column_{$name}. This allows us to break up the columns into discrete methods, and removes the need to override ->single_row_columns(). Thusly, if you subclass a List Table like WP_Posts_List_Table, you can override a specific column just by overriding the column method, i.e: ->column_title().

    Before: https://github.com/WordPress/WordPress/blob/4.2-branch/wp-admin/includes/class-wp-posts-list-table.php#L635
    After: https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/class-wp-posts-list-table.php#L997

    • nicholas_io 2:37 am on August 8, 2015 Permalink | Log in to Reply

      Great improvements! I liked a lot about the changes in WP_List_Table

      Codex is still marking WP_List_Table as private, shouldn’t we remove that warning?

      • Helen Hou-Sandi 3:43 am on August 13, 2015 Permalink | Log in to Reply

        No – it’s still in the inline docs and I think it should remain. I recognize that people are extending it, but that doesn’t mean I endorse it. It’s designed for internal usage with very little consideration for external usage, and I’d like to retain the right to some amount of breakage, though we’ll always limit that to things that don’t lock users out. There’s a lot of difficulty with changing the internals of it because of things developers are using it for that it is not made to do, and in many cases is overkill. Of course, developers will be all the more tempted to use it now that it’s capable of a better small screen view when implemented appropriately.

    • Martin Stehle 12:00 pm on August 8, 2015 Permalink | Log in to Reply

      Columns added by plugins are in the extended view, too. And I can remove the extra CSS for columns of my plugins in small displays. Fine! Thanks to the developers for that work.

    • kevinchappell 7:23 pm on August 8, 2015 Permalink | Log in to Reply

      Hats off to the WordPress core team. Really looking forward to this release, especially the improvements to `WP_List_Table` for sub-classing.

    • Ahmad Awais 11:45 pm on August 8, 2015 Permalink | Log in to Reply

      Makes a lot of sense to have them now!

    • Stephane Daury (stephdau) 4:17 pm on August 11, 2015 Permalink | Log in to Reply

      W00t. :)

    • Helen Hou-Sandi 3:50 am on August 13, 2015 Permalink | Log in to Reply

      Some more bugs were noted in list tables that have more overloads or no row actions in #33313. We’ll try to mitigate any visual data loss, but plugin authors really should update.

  • Helen Hou-Sandi 4:28 pm on June 4, 2015 Permalink
    Tags: ,   

    UI Chat Agenda, 6/4 

    Quick check ins on:

  • Helen Hou-Sandi 4:56 pm on May 28, 2015 Permalink
    Tags: ,   

    UI Chat Agenda, 5/28 

    Quick check ins on:

  • Helen Hou-Sandi 4:20 pm on May 21, 2015 Permalink
    Tags: , ,   

    UI Chat Agenda, May 21 

    Quick check ins on:

    Specific assignments for:

    • Screen-by-screen sweep
    • Trac gardening

    We’ll finish off with open floor / impromptu Trac scrub and see what, if anything, can get committed now.

  • Helen Hou-Sandi 6:37 pm on May 11, 2015 Permalink
    Tags: , , ,   

    Weekly core UI meetings for 4.3 

    Remember weekly UI chats? It’s been a couple years since they wound down, but I’d like to get them started again for at least the 4.3 cycle, as we have some efforts that are not specific to a given feature or component team. UI chats are also a great way for newer contributors to get involved, as there are often a number of smaller patches that can be made and committed quickly. We’ll hold meetings each Thursday, starting this Thursday, May 14, 2015 13:00 UTC-4 in the #design channel in Slack. Updates will be posted here on Make/Core.

    For this week, let’s touch on these points:

    • Better responsive list tables.
    • Getting rid of media-new.php.
    • Screen-by-screen sweep for low-hanging fruit on small screens and touch devices (e.g. inconsistent spacing or font sizes at a given media query point).
    • The state of the CSS roadmap.
    • Coverage for other working groups (passwords, network admin, editor, customizer, anything else?).
    • Bug gardening team (see the UI focus on Trac).
    • Open floor (sound off below ahead of time if you wish – remember that this is about admin UI).
  • Helen Hou-Sandi 4:45 am on April 23, 2015 Permalink
    Tags: ,   

    Spinners and dismissible admin notices in 4.2 

    There are two UI component changes in 4.2 aimed at better experiences moving forward that may affect plugin and theme authors. The first is the spinner element, which does come with a non-critical visual breaking change. The second is admin notices, which are an enhancement and do not affect current implementations.

    Core’s spinner is implemented using the .spinner class. Up until now, spinners have been hidden using display: none and then toggled using jQuery’s .show()/.hide() methods. While this works, it has two fundamental problems: it ties us to jQuery-specific helpers, and more importantly, does not reserve the space for the spinner when hidden, leading to elements moving around on the screen whenever the spinner would toggle. The more appropriate solution would be to use CSS’s visibility property, which does reserve the visual space, and control that visual behavior via a class so that any future changes to CSS are inherited by anybody using that component.

    To that end, to show a spinner, you should now add a class of .is-active to the spinner element, and remove that class when it’s no longer active. This state-communicating naming convention is a part of some of our longer-term goals when it comes to semantic markup, so also take note of that. The breakage here is that spinners will no longer show using jQuery’s .show() method, as all it does is set an inline CSS display property, and so you will need to account for that going forward. The best thing to do would be to update to toggling the class as noted, and if maintaining compatibility in the short term with older versions of WordPress is a concern, detect the version and inject CSS into admin_head that applies display: inline-block to .spinner.is-active. There are other methods for handling version compatibility as well, but this is likely to be the method that is most maintainable and easy to immediately understand. Work on this was handled in #22839.

    The second UI component that we’ve improved in a more visible manner is admin notices. Admin notices are often a source of confusion – if you publish a post and then refresh the edit screen, you’ll still get the notice that you’ve published the post, leading you to wonder if you’ve published it twice or what exactly is going on. They’re also distracting, takes up precious space, and can cause visual fatigue, leading to users ignoring notices that really do need their attention. So, we’ve done two things: one, we’ve made the vast majority of core notices user-dismissible (#31233), and two, we’ve also made sure those notices won’t come back when you refresh the page and have JavaScript on/working (#23367).

    Any notice can now be made dismissible by ensuring the it has the classes .notice and .is-dismissible (recognize that naming convention?). Core handles adding the close button and removing the notice for you. However, for the best possible user experience, you should ensure that those notices will not come back on a page refresh or when navigating to another page. There are two different paths for this. The first applies to notices that are added when a query arg is present in the URL, such as message=6. Core will now remove certain query args and use JS to replace the URL in the browser with that “cleaned up” version. By default, core handles 'message', 'settings-updated', 'saved', 'update', 'updated','activated', 'activate', 'deactivate', 'locked', 'deleted', 'trashed', 'untrashed', 'enabled', 'disabled', 'skipped', 'spammed', and 'unspammed'. To add (or remove) items to this array to accommodate your needs, use the removable_query_args filter.

    The second path, for notices that persist across different page loads, is to bind to the click event on the .notice-dismiss element in your own notice and trigger whatever it is your plugin may need to do to remember that the notice has been dismissed, such as storing a site or user option using Ajax. A note of caution that in an ideal scenario, core would eventually provide a framework for persistently dismissible notices that are not tied to query args, so be prepared for future changes if you choose to use this method.

    • NateWr 9:55 am on April 23, 2015 Permalink | Log in to Reply

      Thanks for posting! I almost missed this change. :)

    • Blue Liquid Designs 9:41 am on April 24, 2015 Permalink | Log in to Reply

      In supporting older WordPress versions with the new spinner modification wouldn’t you need to set `.spinner.is-active` to `visibility:visible`, not `display: inline-block;`?

    • Jonathan Bardo 6:37 pm on April 24, 2015 Permalink | Log in to Reply

      The lost notice connection spinner doesn’t show anymore. I think a css declaration is missing:

      #lost-connection-notice .spinner {
      visibility: visible;

    • Jonathan Bardo 7:11 pm on April 24, 2015 Permalink | Log in to Reply

      Note to those wanting to bind to .notice-dismiss: Since .notice-dismiss is dynamically added to the dom you will want to add your event like this:

      $(‘.notice.is-dismissible’).on(‘click’, ‘.notice-dismiss’, function(event){});

      If someone has a better suggestion, please advise.

    • Barry Kooij 3:18 pm on July 2, 2015 Permalink | Log in to Reply

      Thanks for writing this. Any update on the possible framework around dismissible notices?

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar