Tweaks to user searching and management

A few improvements have been made to user searching and user management in WordPress 4.3 and the upcoming 4.4. Here’s an overview:

  • 4.3: Performing a search on the Users screen now searches the user’s username, email address, display name, nicename, and URL, instead of just their username and nicename. See #27304
  • 4.4: Performing a search on the Network Admin -> Users screen previously required the use of a * wildcard character at the beginning and/or end of the search term, otherwise the search required an exact match. This is no longer the case, so finding users on Multisite is no longer frustrating and inexplicably dysfunctional. This, combined with the changes in 4.3, means searching for a phrase such as “” now works as you would expect. See #32913
  • 4.4: It’s now possible to filter the Users screen by users who have no role (in addition to being able to filter the screen by individual roles), if there are such users. See #22993
  • 4.4: Users with multiple roles (it’s possible to programatically give a user multiple roles, although this isn’t possible via the UI) are now shown as having multiple roles on the Users screen. This helps avoid obfuscation of a user’s roles. If your plugin facilitates the assignment of multiple roles to an individual user, you should test it against trunk and look at using the new get_role_list filter introduced in [34963] if necessary. See #22959

Any other improvements you think could be made? Leave a comment.

#4-3, #4-4

4.3 Retrospective Results

I missed posting the 4.3 post mortem recap before I went on vacation, so without further ado:

We discussed the 4.3 release in Slack, where I asked for things that should be improved and things that went well, in order to get some feedback on how I did and helpful tips for future release leads (please find the Slack log here):

Should be improved:

  • Figure out some ways to get more testing and more eyes on betas and RCs.
  • Not having feature plugin complete (with core patch) before the merge window.
  • The menu customizer proposal could have been written differently in anticipation of community perception.
  • The people who are able to test term splitting properly are very limited. Not sure how to wrangle people for this kind of specialized testing.
  • there seemed to be a lack of movement at the end of the cycle.
  • Features like site icon should be done as a feature plugin.
  • The merge proposal could have been proof-read by someone from the core team.
  • Getting dev-notes written up earlier.
  • There were also not a lot of feature plugins ready for core at the start of 4.3.
  • Don’t think it’s really okay to be relaxing standards in the name of forcing something to fit a deadline.
  • We did a freeze/RC maaaaybe 24 hours before release that had significant changes in it, that did not feel good.
  • We completely changed features after beta 1.
  • I think in 4.2 we discovered that have a core mentor involved much earlier also helped get it to that “ready” place. Or closer to ready.
  • Find a way to increase participation for bug scrubs.

Went well:

  • passwords went really well.
  • We had a solid crop of guest committers that really made things go well for there project area.
  • Update to 4.3 went really smoothly over all as well.
  • We had some epic traction on Formatting component patches during this cycle. I’m a bit surprised how many tickets we closed with 4.3 because those are usually very problematic.
  • Touch and small screen usability improved significantly. Two of my top five issues were fixed outright and progress was made on a third.
  • I demoed the keyboard shortcuts in the editor to some people and they were like “DAMN, that’s amazing”.
  • i’m really happy about list table changes!
  • Shared taxonomy terms are dead.

I’m probably a little biased, but contrary to what the amount of bullet points in each section might suggest, I agree with @samuelsidler who said: “Almost everything went really smooth.” I’m proud of what we accomplished, and the download and update numbers speak for themselves. Thank you again for everyone who helped out during the release, let’s make 4.4 even better!

#4-3, #post-mortem #retrospective

WordPress 4.3 Post Mortem

I’d like to do a review of the WordPress 4.3 release cycle, talk about what went well, what didn’t, and ideally derive specific items that we can improve on.

Let’s do that in the #core channel on Slack on August 24 2015 20:00 UTC, the usual dev chat time.

#4-3, #post-mortem

Dev Chat Agenda for August 12

Here’s the agenda for today’s Dev Chat in the #core channel on Slack.

Time/Date: August 12 2015 20:00 UTC:

  1. RC Notes
  2. Component Updates
  3. Open Floor

#4-3, #agenda

WordPress 4.3 Field Notes

WordPress 4.3 includes improvements to existing features and brand new features for developers. Over the past few weeks, the core team has been posting here on make/core with a number of the developer changes in WordPress 4.3.

WordPress 4.3 ships in just a week and a half. Prepare your themes, plugins, and apps for the changes above and comment on those posts with any questions, comments, or feedback.

#4-3, #dev-notes

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


#4-3, #dev-notes, #list-tables

Dev Chat Agenda for August 5

Here’s the agenda for today’s Dev Chat in the #core channel on Slack.

This will be a rather short meeting I assume. We’ll be discussing code freeze, RC3, and a timeline for the last two weeks of this release.

Time/Date: August 5 2015 20:00 UTC:

  1. RC Notes
  2. Component Updates
  3. Open Floor

#4-3, #agenda

Editor Enhancements in 4.3

Text Patterns

We added a small set of text patterns, or text shortcuts if you will. These will hopefully keep you focussed better on your writing and save you some time. 🙂

Typing *  or -  will automatically give you a proper HTML list right away. Same for 1.  or  1) , but then ordered. Not your intention? Pressing backspace will undo this change. You can also use the undo button, ctrl/cmd+z or esc.

Starting your paragraph with two to six number signs # will convert that paragraph to a heading. Similarly the greater-than symbol > will convert the paragraph to a blockquote.

We’re planning to add some more next release, and a way for plugins to extend this.

Here’s a demo video @boren made.

Inline Link Toolbar

This toolbar will show up when you put your cursor in a link. You’ll now be able to see a short version of the URL without having to open the link modal all the time. Clicking it will open the page that it links to in a new browser tab. If you wanted to do this before, you had to open the link modal and copy paste the URL in a new browser tab yourself.

It also comes with an edit and remove button. We hope to move the editing experience inline next release as well.

Inline link toolbar

#4-3, #dev-notes, #editor

Headings in Admin screens change in WordPress 4.3

Are you a theme, plugin or framework developer for WordPress? Take note: the heading structure in the Admin screens will change in WordPress 4.3.

From H2 to H1

Currently, in WordPress 4.2 and before, the main heading in admin screens is an <h2>. However, if you want to have a correct, semantic heading structure, a page should an <h1>, but only one, which describes what the page is about.

People using assistive technology use the <h1> to identify a page and quickly know where they are. Further, proper HTML5 dictates that an <h1> should be the initial heading.

Therefore, in WordPress 4.3 the headings of all admin screens have been changed from <h2> to <h1> (see #31650).

Related CSS changes

If your theme or plugin still uses <h2> for admin screens, don’t worry; styles for <h2> are still supported in the admin CSS so that, visually, nothing changes during the update to 4.3. However, a new class was introduced to properly style <h1>s, page-title-action. Here’s an example of the new class in use:

<h1>Posts <a href="[..]/wp-admin/post-new.php" class="page-title-action">Add New</a></h1>

The old class .wrap .add-new-h2 is still supported but has been labeled deprecated. It has been replaced by: .wrap .page-title-action.

More changes ahead

After the release of WordPress 4.3, the accessibility team will continue making changes to heading so that they are semantically correct. Current <h3>s will become <h2>s, <h4>s will become <h3>s, and so on.

Check your code

Does your plugin, theme, or framework have admin screens? Check the heading structure. Change the main heading from an <h2> into an <h1>. If you’re feeling generous, check the rest of your heading structure to ensure it’s semantic.

Making these semantic changes will ensure your plugin or theme is in sync with WordPress and that people using a screen reader can understand your admin screens better.

If you have any questions, ask them in the comment section below, or contact the WordPress accessibility team in the #accessibility channel in WordPress Slack.

#4-3, #dev-notes

get_transient() is now more strict in 4.3

WordPress 4.3 includes a change to get_transient(). As reported in #23881 and #30380, get_transient() had a check for get_option( $transient_timeout ) < time().

Because get_option() can return false and false is always < time() 😖, get_transient() could delete transient timeout options in an unexpected way or cause two more unnecessary queries.

WordPress 4.3 now checks the return value first before comparing with the current time. This means that WordPress will no longer delete broken transients via get_transient() if you have only deleted the timeout option. See [33110].

If you have to delete a transient manually, please make sure that you’re deleting _transient_timeout_$transient and '_transient_' . $transient. (Hint: Transients can be stored in an external object cache too.)

See also: the Transients API Codex page.

#4-3, #dev-notes, #options-meta