Last Week @kellychoffman and I shared some concepts that explored how we might introduce some of the powerful site editing features in the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 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 to WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

To briefly recap, the first concept brought template, style, and content editing together under a single “Editor” menu item in the Appearance section of the main navigation. The second concept kept these features separate, and leaned more on existing wp-admin views to access some of them.

In this post I am sharing a stress-test that I’ve performed on both concepts, to see how they handle complex plugins that add custom post types. For this test I used WooCommerce and focussed on it’s product post type. The aim here is to further distill each approach and hopefully find consensus around which one to pursue for 5.9.

Since styles are a feature that transcends content and template, I’ll be focussing on editing the latter. I’ll demonstrate the hypothetical flows to edit individual products, and to edit the template that is used to display those products. 

For the purpose of this test we’ll assume that WooCommerce fully supports blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. templates and the block editor.

TLDR: Due to the “Separate” concept leaning more on existing wp-admin list views it will require less work to implement, and less effort for plugin developers to adopt. It will also be less disruptive to existing user flows when working with custom post types.

“Combined” concept

In this concept clicking “Editor” in the Appearance menu takes you to a view where you’re able to edit the homepage of your site. From here clicking the W menu will open the navigation where you will see a new “Products” section has been added. Clicking this takes you to a product list view inside the Editor:

Clicking a product will take you to the editor view for that product, where you are able to modify the product data, the product template, and elements like the site headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. and footer all at the same time.

To then go and edit the product template on its own, you once again open the W menu, navigate to templates and find the two new templates that WooCommerce added: “Single Product” and “Product Archive”. Clicking “Single Product” takes you to a view where you’re able to edit that template.

---

“Separate” concept

In this concept product management is accessed in the same way it always has been – at the top level of the wp-admin navigation. Even the list view behaves the same. However, opening a product takes you to an editor view where you’re able to toggle the visibility of the entire layout in order to visually edit other product data, or even elements of the underlying template.

Of course in an example like this – where the post type in question is so visually reliant on the template – it may make sense for WooCommerce to make the layout visible as a default for product editing. Or perhaps even force it to be permanently visible by removing the option to toggle the layout visibility. This is a detail we should consider making available to plugin authors during implementation if we choose this concept.

On that note, there’s a balance to be struck around where we draw the lines between content and template editing, so we should explore contextually locking certain blocks. For example: here it should be trivial to change the featured imageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. source, but moving it around or changing the dimensions should be either one step removed, or alert the user that they are making a template-level change.

To explicitly edit the product template you exit the edit-product view and navigate to Appearance > Templates. Just like in the last concept, here you’d find the two new templates added by the WooCommerce plugin, and you are able to go and edit one by clicking on it. As in the current post editing experience, clicking the W button simply takes you back to the Template list.

Observations

The thing that stands out most to me is the duplication that occurs in the “Combined” concept. There are effectively two places for users to manage post types – either via the existing top level “Posts” and “Products” menus they’re familiar with, or via the new Editor menu. This increases the workload on plugin authors as they need to consider both potential workflows and it also places additional cognitive load on the end user since they will need to actively choose an interface each time they want to manage things like posts and products.

Any flows accessed from list views such as trashTrash Trash in WordPress is like the Recycle Bin on your PC or Trash in your Macintosh computer. Users with the proper permission level (administrators and editors) have the ability to delete a post, page, and/or comments. When you delete the item, it is moved to the trash folder where it will remain for 30 days. management and bulk editing may also end up being duplicated.

All of this will be compounded when you add more plugins/post types, and given that different plugin authors would adopt these new features at different paces, the user experience could grow increasingly inconsistent.

Another consideration is the many plugins that currently extend the existing list views. With the duplication of those views in the “Combined” approach, many of those plugins would need to be updated to support both versions. APIs can probably do much of the heavy lifting here, but ultimately this would slow down adoption of these new features as it will take plugin authors time to adapt. Users may also prefer to stick to their “tried and true” methods. Those that choose to embrace the new views could find themselves in an awkward spot if the one plugin they rely on doesn’t support them yet.

The “Separate” concept addresses each of these shortfalls by simply relying on the existing post type list views in wp-admin. The flows in which users manage all post types remain the same, and whether they get a richer block-based editing experience is solely down to whether or not the plugin has chosen to adopt these new technologies. It gives us the time to concentrate on updating the list views in isolation at a later date. Due to this, I tend to lean more towards this approach as it feels like a much smaller step with arguably equal impact, but I’m keen to hear more thoughts and feedback from y’all.

What’s next

After digesting feedback we’ll hopefully agree on how to move forwards for 5.9. From there we can open a tracking issue on githubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ to work through the necessary outstanding issues and explore finer design details.