Anne McCarthy announced Round #13 of the ESF Awareness Program March 31. This call for test concerns the creation of an author template via the site editor. Several of the new features used in this round were only added in Gutenberg 12.9 last week.
The call asks volunteers to test and provide feedback on features related to the full site edition before they land in WordPress. Anyone can participate and the deadline is April 21.
For this series of tests, I used the Archeo block theme. It’s a recent favorite, and I’ve been working with it since I first reviewed it.
Here is a screenshot of my final author template design:
I read the test instructions and forged my own path. I still managed to cover everything except block locking. I had already tested it extensively with the launch of Gutenberg 12.9 and wanted to focus on the other features.
Other than the user experience issues noted below, everything went well. No editor crashes. No problem saving. And the front-end matched what I saw in the editor.
Creating an author template
The most immediate issue with creating a new author template is that it lacked default blocks. Where were, at least, the header and the footer?
The empty model would make sense if I was building something from scratch. However, this is not a project from scratch. It was built from a theme with existing archive.html and index.html files, ancestors in the template hierarchy.
Since the author template is just a more specific version of the archive template, it should be a copy of its “parent” in the hierarchy.
Users will most likely want to make changes rather than starting from scratch. Using an ancestor template as a base means they are less likely to deviate unnecessarily from the existing layout, especially with more complex designs.
The second set of actions I took was to go back to the Templates panel, open the archive template, copy all the content and paste it into the new author template.
It’s – albeit a bit irritating – quite easy to do, at least from a developer’s perspective. However, this is a huge boulder sitting in the middle of a user’s path to success.
For the design, I fell back on the always reliable Cover block. I snagged an image that worked with the style of the theme. Next, I placed the Avatar, Archive Title, and Post Author Biography blocks in two columns.
I spent some time thinking about the idea of featured images for authors, categories, and tags. Would it be great if the cover block background was displayed contextually based on the current author? Unfortunately, such functionality does not exist.
I was surprised that the Avatar and Post Author Bio blocks worked. I tested them both inside the query loop and outside of it. When an author has published articles, both blocks appear as they should.
However, if the author has not published any articles, the avatar reverts to the site default and the biography disappears. I haven’t done a deep dive into the code, but I’m guessing they’re taking over the global from WordPress $post variable, that’s why it works in the first scenario.
This limitation means that the block system is still not up to par with what is currently possible with classic PHP-based themes. Avatar, Post Author Biography and similar blocks should rely on the queried author variable as a fallback when displaying an author archive.
Part of this FSE test suite used Gutenberg 12.9’s new No Results block. This is a conditional block that appears when there are no messages to display. WordPress creates “author views” for every user on the site, whether or not they have written articles. The No Results block will probably be the most useful in this context.
Working with the block seemed strange at first. Where are you going? After the publication model? Before?
Turns out you can actually paste it anywhere inside the query loop’s parent block. I even tested before and after paging. Basically it works.
The user interface left something to be desired. It simply reads:
Add text or blocks that will display when a query returns no results.
Aside from the glaring grammatical error, displaying the message is needed, but I expected it to look more like the Group block. After all, it’s basically a container for other blocks, and WordPress already has an existing UI for that.
It was also strange to visually change a conditionally displayed feature. There should be an indicator that its contents can or cannot be displayed on the front-end. I don’t know of any precedent for such a block in WordPress core, but we should look at other projects and how they handle this.
the Block visibility plugin from Nick Diego could be a plugin to borrow. It adds an overlay, border and icon for the context blocks:
In the end, I decided to copy McCarthy’s original post from his test and paste it into the No Results block. Then I took things a step further and put a query loop inside – yes, a query loop inside a query loop.
This worked without a problem:
Overall, the No Results block is a welcome addition to the topic blocks toolset. I would like to see the UI fleshed out a bit. Theme authors will probably start using it more when 6.0 arrives, and I might see users inadvertently trying to remove it, thinking it’s part of the default release. This would make it a candidate for block-level locking.
