Development challenges with WP blocks and Gutenberg

The interview

If you can only pick three challenges in block development, which would you like to highlight?

The first things that come to my mind are unfiltered HTML capability, the Navigation block and Global Styles.

Before we dive in deeper, can you shortly explain what Unfiltered HTML Capability is?

The Unfiltered HTML Capability in WordPress allows users to directly insert HTML code into posts and pages. This powerful feature is primarily limited to administrators and super administrators for good reasons. The primary challenge with unfiltered HTML is the inherent security risks it poses. The platform filters these capabilities based on the user, impacting what elements and attributes different user groups can save and edit. Which is a good thing.

When users without permissions try to include specific HTML elements or attributes, these can be stripped away upon saving the content, often without any warning to the user. This silent removal can cause confusion, disrupt page layouts, and break the site’s accessibility, particularly with elements like ARIA labels or data attributes which are vital yet inaccessible to standard users.

How does that affect block development?

For developers, these constraints mean a significant increase in workload. Each block created requires a meticulous release of necessary HTML attributes and elements. This not only adds to the complexity of development but also increases the risk of errors. The situation is further complicated by often inadequate documentation, making the development process more challenging and error-prone. These challenges are particularly pronounced in scenarios involving complex user roles or advanced authorization structures.

Consider the case of a user management plugin, where users have the autonomy to create and manage their roles. Here, the challenges of unfiltered HTML become especially evident. Inadequate configuration can result in users being unable to edit or save pages effectively. They find themselves confronted with an error message stating “This block contains unexpected or invalid content. Attempt Block Recovery”.

This leads to a significant increase in troubleshooting efforts and ongoing maintenance, burdening both users and developers.

Can you give us an example?

A compelling example of this is the restriction around input fields. As I mentioned earlier, WordPress, for security reasons, limits certain user groups, like the default editor group, from saving input fields. This is because input fields can potentially contain harmful strings, posing a security risk to the WordPress installation.

For us, this presented a notable obstacle, especially when developing custom blocks for our form builder, which inherently requires input fields. The security measures, while essential, proved to be a significant hindrance in block development.

The problem became clear when testing under different user roles. The system, while saving a post, would filter out elements that the user role was not permitted to save. This led to forms becoming non-functional and data being lost, all without any error message or warning to the user.
Solving this required extensive research into WordPress’s underlying security filters. Our team dug through piles of documentation and source code to understand and circumvent these restrictions, all while maintaining the security integrity of the site.

The second challenge you mentioned is the Navigation block

Oh yes! A particularly challenging aspect of working with WordPress blocks was improving the functionality of the navigation block. That’s not just us saying so. It’s generally recognized as one of the most essential yet challenging blocks to work with. The Navigation Block has long been a topic of discussion in the developer community. Known for its complexities and limitations, it’s been a point of frustration for many. However, recent developments and additions have significantly improved its functionality and usability! WordPress developers have made notable strides in enhancing its user experience, especially over the past six months.

A key improvement is the introduction of different tabs such as ‘Settings’ and ‘Design’. These additions allow for a more intuitive understanding and manipulation of the navigation structure, significantly enhancing the ability to structure and customize navigation menus.

But… Despite these enhancements, a significant gap remained in the realm of styling and design options. Developers could include buttons in the navigation block but were limited in terms of detailed customization. Standard design features like thick borders below navigation items, hover effects, or the ability to alter the appearance of secondary and tertiary items were lacking. This limitation was a major hurdle in achieving diverse and creative designs.

How does Greyd.Suite address the shortcomings of the Navigation block?

To address these shortcomings, we’ve introduced comprehensive design options for the entire menu. You can now apply a default style to all menu links. For instance, you can set a thick black three-pixel border below each element, adjust padding, and change background colors on hover. This level of customization provides a clearer indication of user interaction, such as hover or focus states.

Further, we’ve expanded the customization options at the individual element level. Beyond just transforming an element into a button, developers can now apply unique styles to each element. This includes different borders, labels, or other stylistic modifications, offering greater flexibility in design.

One of our most significant additions is the implementation of active styles. This feature enables developers to create distinct hover and active states for each menu item, both on a menu-wide and individual element basis. This enhancement greatly elevates the potential of the Navigation Block, allowing for more dynamic and engaging user experiences.

On to the third challenge: global styles. What challenges do you face there?

What is challenging is that no one can directly influence the Global Styles interface of WordPress. While the classic PHP-based development of WordPress allowed extensive customization, the block-based development significantly reduced this flexibility. This change, though it streamlined user experience, poses a challenge for developers seeking to offer more comprehensive design options, such as hover styles for buttons or configurations for input fields.

Our solution involved creating a custom plugin called Greyd.Styles to augment the global styles, an approach that, while effective, is not ideal as in user experience. But it gives users of Greyd.Suite the means to implement these essential visual distinctions.

What do you do to stay informed?

Some of our favorite resources are WP Tavern, articles on the developers section of WordPress.org, especially the ones from Justin Tadlock and the WordPress.org forum to stay informed. A podcast we follow closely is the one hosted by Birgit Pauli-Haack, called the Gutenberg Changelog. You can find it on the Gutenberg Times website.

What are you most proud of, looking back to all the work you have done?

We’re proud of modernizing our code structure to be compatible with both block themes and classic themes. Our focus is on efficiency, scalability, site speed, and sustainability. We aim to stay close to WordPress core, using its native features, ensuring our customers always benefit from the latest developments.