During last week’s multisiteMultisite Multisite is a WordPress feature which allows users to create a network of sites on a single WordPress installation. Available since WordPress version 3.0, Multisite is a continuation of WPMU or WordPress Multiuser project. WordPress MultiUser project was discontinued and its features were included into WordPress core.https://codex.wordpress.org/Create_A_Network. meeting the need for a new design pattern related to list tables was expressed. The intended functionality would require some kind of advanced bulk actions and row actions that would provide a second step to choose one or more related objects from a dropdown.

Before describing the requirements in more detail, the actual use-cases from the discussion are outlined:

• Network Admin > Plugins list table: It should be possible to bulk-select plugins, then choose a new bulk action “Activate on site/s…” and then select one or more sites from a dropdown/autocomplete field on which to activate the initially selected plugins. In the same manner a row action “Activate on site/s…” should exist with a similar way of then selecting the site/s to activate the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party on.
• Network Admin > Themes list table: This would need a similar functionality like what has been described for plugins above, with both a bulk and a row action called “Enable for site/s…”.
• Network Admin > Users list table: It should be possible to bulk-select users, then choose a new bulk action “Add to site/s…” and then select one or more sites from a dropdown/autocomplete field to which to add the initially selected users. A similar row action should be added as well.

While all these use-cases are about selecting related sites, the new design pattern should by no means be restricted to that. Such a pattern could benefit many other list tables in WP Admin as well. Some of the use-cases could be (without any intention to actually implement them though):

• Posts list table: It could be possible to bulk-select posts, then choose a new bulk action “Set taxonomies…” and then select one or more taxonomies from a dropdown/autocomplete field to set these taxonomies for the initially selected posts. A similar row action could exist too. The functionality is technically already available through QuickEdit, so this example would not be useful in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., but in general it still makes a valid use-case.
• Posts list table: It could be possible to bulk-select posts, then choose a new bulk action “Set post format…” and then select the post format from a dropdown/autocomplete field to set the initially selected posts to. A similar row action could exist too.
• Users list table: It could be possible to bulk-select users, then choose a new bulk action “Assign role…” and then select the role from a dropdown to assign this role to the initially selected users. A similar row action could exist too.

The initial thought during the multisite discussion was to have some kind of popover open when an advanced bulk action is selected or an advanced row action is clicked. This popover would contain the dropdown/autocomplete field to select the context for the action to perform. However, this is likely not to be the optimal approach here. Another approach would be to dynamically include the dropdown/autocomplete field on the right side of the actual bulk actions selection, which is what Advanced Bulk Actions does, a plugin that was recently created. This plugin could possibly serve as inspiration, however it does not currently provide an autocomplete functionality which would be required due to the possibly high amount of items selectable. Furthermore the autocomplete does make for a good example of REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. usage in WP Admin.

The three images below indicate the desired functionality in three steps, here following the second approach described, for the third example mentioned above (Network Admin > Users list table):

1. A bulk action that requires context (indicated by three dots) is selected.

2. A contextual autocomplete field appears.

3. One or more sites can be selected before hitting the Apply button.

The goal for this new design pattern should be to be able to define any kind of object-to-object relationship (whether one-to-one, one-to-many, many-to-one or many-to-many) from a list table, by assigning one or more objects from the list table to one or more related objects of any type, which would be defined per individual bulk / row action.

While functionality like this could be included in an interface similar to QuickEdit for posts, it appears that having dedicated bulk and row actions might be more specific and fitting for such a use-case. This will still need to be discussed in detail though.

We would like to ask the design team for their feedback so that we can implement advanced contextual bulk actions in a proper way with the best possible user experience.

#core, #design