How Plugins Can Deliver Fine Grained Design Control in the FSE Gutenberg Era

There have always been a variety of ways for plugins to render content and provide options for integration with the front-end of WordPress sites. The most common has been to provide shortcodes. Another is to provide page templates and use locate_template() to enable themes to override these templates. In the FSE (Full Site Editing) era neither of these options will be considered good enough. I wanted to say they won’t be relevant, but it is likely many plugins, thousands of plugins in fact will continue to render content in outdated ways for many years. And having those options as fallbacks might even be considered a good practice in order to provide support for classic themes. How and when these changes happen in ecosystem is still a moving target, but FSE is rolling out soonish. FSE themes are already working fairly well in their experimental phase, and the simplicity of FSE theming is going to mean a very rapid transition in terms of theme support.

We can expect themes to be FSE compatible very quickly after FSE goes mainstream and is part of the WordPress core. In a period of likely less than 6-months, classic themes will start being viewed more as legacy themes, and all major theme makers will roll out their versions of FSE themes. The rollout for plugin makers will certainly be slower. A lot slower. Consider this, an FSE theme is actually a trimmed down, light-weight bundle of mostly Block Markup exported templates. It can be largely crafted through the Gutenberg editor. Yes there will still be challenges in making useful and versatile themes like managing font loading, providing styles and variations for dozens of core blocks… it will still take time, but the technical challenges are relatively modest. On the plugin side you have almost the opposite scenario. Companies that normally have little or no React development experience will now need to learn or recruit React developers with block building experience. They’ll need to master InspectorControls, developer attribute management approaches, and ultimately ship blocks that are ready for design control using the Gutenberg editor.

Plugin makers that are successful in providing a great UX experience for site editors are going to win big in the FSE era. Those that don’t, may find their once popular plugin falling quickly to the wayside. It’s going to be interesting to watch and see which companies excel at React development and are able to provide great blocks, versus those that falter and either ship poor quality blocks, or fail to provide enough level of design control.

I’ve used the term design control a few times in this article in an effort to articulate the “capability of site editors to control the output from plugins, both in terms of layout and style.”. In other words the ability to do what many already do in a page builder like Elementor. Control everything from backgrounds to padding and margin to motion controls, button styles etc.

FSE Design Control Level Ratings

Let’s try to quantify various levels of design control that plugins offer using a sliding scale.

  • Level 1 FSE Design Control – None, zilch, nada. No Gutenberg blocks offered at all. All content rendered via PHP/HTML mixed templates, PHP page templates or shortcodes, and/or other non-Gutenberg methods such as widgets.
  • Level 2 FSE Design Control – Plugin offers monolithic blocks that render entire pages or sections of pages. These blocks have minimal settings and offer less than 25% control over the various common styles options. They lack the ability to change layout of the content internally within the block. Nonetheless the existence of the block enables developers to style the block content with CSS, add variations of the block, potentially hook into and alter the rendering of the blocks. This level of FSE Design Control also means that the plugin doesn’t offer full coverage of blocks for all it’s rendered content.
  • Level 3 FSE Design Control – Plugin now offers complete coverage for it’s rendered content. All content it produces can be rendered with a Gutenberg block. Some of it’s blocks may still be monolithic, and some of the content in these large blocks cannot be individually styled. To qualify for this level however, the plugin should be providing a reasonably robust set of attributes per block such as spacing, typography, borders, backgrounds.
  • Level 4 FSE Design Control – Plugin has complete coverage of it’s rendered content and the blocks provided are polylithic (the opposite of monolithic). These small blocks tend to be grouped in families with a parent/child/grandchild structure. This enables child blocks in a structure to be eliminated if they are optional. It allows fine-grained design control over each individual part of a rendered layout. To qualify for this level the plugin blocks must also have consistent and thorough design controls provided by their attributes. The resulting level of design control should be over 90%, meaning that out of all common and even unusual design choices, over 90% of them can be achieved without any custom CSS using only the block attributes.
  • Level 5 FSE Design Control – At this level the already robust design controls found in the previous level are enhanced even further. We now begin to see conditional logic embedded into the blocks enabling them to appear or be hidden based on user roles and login status. We see a greater range of styles and variations provided to make design work even easier. We also see a very refined form of style inheritance that enables the user to start either with a lean style (core/raw styling), a moderate styling options focused on inheriting global styles, or a more opinionated design style offered as a nearly final design work needing only customizing by the site editor.
  • Level 6 FSE Design Control – The block can jump out of the page and make you breakfast.

How Saber Commerce is Structuring Blocks

In Saber Commerce we have plans to provide the very best possible FSE support. That means first achieving 100% block coverage for all the front-end rendering. Specifically that means the catalog, shop pages, single product pages, cart, checkout and customer portal. Our first area of focus has been the cart. SC’s block-based cart is being released soon and is already in the latter staging of alpha testing.

Cart Blocks for Saber Commerce

There are 9 Gutenberg blocks provided to build the Saber Commerce cart. This illustrates the power of the Gutenberg child block and InnerBlock system. A full reference list is shown below, and the indents represent the parent/child relationship between the blocks.

  • Cart Block. This is the main parent block which contains all the other cart blocks.
    • Cart Header Block. This is a block for holding content to appear above the Cart Table. It’s optional. For themes that don’t render the title of the page it might be used to display the cart title. For companies that have some legal requirements, this block along with the Cart Footer Block is a place to insert those legal statements, as well as any information about terms/conditions, currency, shipping restrictions etc.
    • Cart Table Block. This is the outer wrapper for the cart table where cart items are displayed. Providing the cart table as a separate block enables styling to be applied such as margins. Most of the time however, the table itself is not styled, and the core stylesheet provides only minimal styles for the table such as border-collapse.
    • Cart Table Header Block. This block provides the table header, defining the 4-columns rendered as table header tags (th). This is a block that is fun to style because the table header can have a big impact on the style of the overall cart. Background colors are popular to use here, as well as custom typography for the header items.
      • Cart Table Body Block. This block houses the cart item rows. The cart item rows are of course dynamic and are rendered according to what the user has in their cart. This block houses them, providing the tbody tag and enabling spacing and other styles to be applied across the table body.
        • Cart Item Row. The only block type allowed in the Cart Table Body Block is this child block named Cart Item Row. This is a dynamically generated block where each block represents 1 cart item. This is rendered as a standard table row (tr) with columns for each data element starting with the product. Notably the quantity field is rendered as an number input form field in order to allow the user to change the quantity.
      • Cart Table Footer Block. This block sits inside the table in a table footer tag (tfoot) and it’s purpose is to provide an Update Button and (optionally) a Use Coupon button. Potentially it might evolve to enable addition of other types of buttons, but that is what is supported currently. The update button is used to finalize a quantity change in the cart. The coupon button at the moment is not functional, because Saber Commerce products don’t yet have coupon functionality. Nonetheless the block already supports the button and ships it disabled for the time being until coupon functionality is added to Saber Commerce core.
  • Cart Totals Block. This block sits outside the Cart Table. We considered using the cart table footer for this block, but opted to make that the container for blocks instead. Having it outside the table also makes sense in that normally this is rendered a separately from the table in many designs, with separate alignment that may not match the main table columns. Our default core styles for this block make it a 50% width block that is pushed to the right, a common design choice which looks great with a background color and helps the user focus on the totals displayed. The Cart Totals Block is a dynamic block, fetching the current cart totals both on load and then updating them dynamically based on event triggers when the user updates quantities or removes items.
  • Cart Actions Block. This block is used to display the Checkout Button, as well as the Return to Shopping button. Core styling makes the Checkout Button prominent using a class btn-primary while Return to Shopping is displayed as secondary button using btn-secondary.
  • Cart Footer Block. Much like the Cart Header Block this is a section that is optional and it provides a place for inserting content. The Cart Footer Block would normally render below the Cart Actions, and it provides a place for notices, trust icons or legal statements.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *