New Comment Blocks Coming With WordPress 6.0 – WP Tavern

WordPress 6.0 will attempt to tackle comment lists via the blocking system. This is an area that has lagged behind other features, which received most of the work in previous releases.

Last week, JuanMa Garrido called for volunteers to test the new blocks via the Make WordPress Test blog. Contributors are welcome to leave comments in the comments or create new issues through the Gutenberg GitHub repository.

Post comment lists have undergone some changes over time. Prior to WordPress 2.7, theme authors used a PHP foreach call to loop over an array of comment objects directly in their theme comments.php model. It was a simple basic HTML system and a few template tags scattered throughout. This worked fine until nested responses were introduced. There was a mad scramble from developers and users to update themes to use the new wp_list_comments() a function.

Fast forward to the era of block templates and the site editor. Again, the comments changed, but that was only on the surface. The Post Comments block was just a wrapper for the existing implementation. Any block theme author has had to use custom PHP filters to modify the comment list output, and users have generally been unlucky outside of a few design checks.

WordPress 6.0 will almost come full circle. Comment output returns to models via the block system. PHP filters are no longer needed to move the layout. And users can make changes through the site editor.

Granted, I hadn’t spent much time working with comment-related blocks until today. For the most part, I avoided them altogether as I was waiting for the set of blocks that should land with WordPress 6.0.

The latest version of the Gutenberg plugin embeds a whole suite of comment-specific blocks. The comment request loop and comment template should work the same as their post counterparts. The set includes several metadata-related blocks for comment author, date, reply link, and edit link. There are a few new ones for pagination, and the next Avatar block will also work in the comment template.

I opened my active theme’s single post template and deleted the old post comments block. Next, I inserted the new feedback request loop:

Default feedback query loop block output.

I was surprised that there were no opinionated styles—a good surprise. However, since the default output included most possible blocks that a theme or user would use, I would have liked to see them wrapped in one of the layout-related blocks like Columns or Row, providing a simple structure .

It didn’t take long to move a few pieces around and get a layout I liked. I got the dreaded “Aww Snap!” message once, losing all my work when the editor crashed. I couldn’t reproduce the problem, but I nervously pressed the save button every two minutes from then on.

Other than the random editor crash, everything was fine. However, I was only scratching the basics at the time. With those out of the way, I wanted to know if the new blocks would offer the tools that theme authors and users could use in real-world projects.

The first issue I encountered was the missing comment ID in the front-end output. This is necessary for the user’s browser to return to their comment after submitting one through the form. I also suspect this is necessary for the comment reply JavaScript to work when you click on the reply link.

Front-end output does not show the comment classes of the comment_class() a function. This leaves no way for theme authors to directly target comments based on data such as their depth, type, status, etc. for the moment. This is a regression from previous comment list solutions in WordPress.

There also doesn’t seem to be a “Comments Title” block, which would output something like “X reply(s) to post title” above the list.

Most of these issues should be trivial to deal with in the kernel. These are what I would consider basic requirements for a working comment list. However, there is one issue that will likely take more than one release cycle to materialize.

There is no concept of nesting in current design tools. Each reply to a parent comment receives a small padding bump to the left. Other than that, all nested levels get the same design treatment as their parent, each in its own little box. Some designs are currently not possible through the interface, such as giving a single wire a background color.

Something as simple as the following cannot be done with design tools:

A CSS-based customization of the Comments Query Loop block on the front-end that gives nested comments a slightly lighter color than their parents.  Children's comments are also packed in their parents' box.
Design tools do not support nested customizations.

And that’s just a run-of-the-mill comment list design. Don’t expect to do anything more advanced without custom CSS.

There are no tools built around the hierarchy. WordPress’ blocking system didn’t handle similar scenarios well. Just try something complex remotely with the navigation block, for example, to see its shortcomings. However, this is a much more complicated scenario than a nested list of comments.

This is not a problem with the block system itself. Design tools haven’t caught up yet, and presenting such intricacies in an easy-to-use interface is no walk in the park.

As of Gutenberg 12.9, the Comments Query Loop block looks like a regression from a theme design perspective. It’s not as flexible as the current method or as it was all those years ago when comments were issued via a simple foreach loop, some HTML and some template tags.

Although it may be limited, it still allows end users who wish to modify the design of their comment list. It’s a welcome improvement, and I’m excited about how the kernel can build on it in future releases.

Comments are closed.