The Test Team helps manage testing and triage across the WordPress ecosystem. They focus on user testing of the editing experience and WordPress dashboard, replicating and documenting bug reports, and supporting a culture of review and triage across the project.
Please drop by any time in SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. with questions or to help out.
Started the call with an open question asking how folks are exploring adopting FSE features. This led to an initial discussion around theme.jsonJSONJSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. both in terms of what it unlocks and various pain points.
A few of us found it to be easier to compare their own theme.json files to TT1 Blocks’ theme.json rather than relying on documentation to figure out what might be going wrong.
Ideas were shared namely around improved documentation for theme.json combined with improved error messaging, especially since eventually the visual interface will only be used.
Some of the problems with theme.json feel similar to the usual functions.php experience and there was a desire for a “Something has gone wrong with theme.json, here’s what you should do” resource (even if just a personal post for now). For example, leaving out version number can make the experience very unpredictable.
Tammie noted it often feels like “playing rather than exploring” with theme.json because of how much one can do.
Marcus encouraged folks to use a syntax editor (ex: vscode) since it will alert you to json errors. In general though, folks wished it was more forgiving to hand write until we’re able to build directly in the editor.
Marcus likes the idea of splitting files up and allowing people to do whatever they want. “Here’s typography, here’s how I want headers to be, etc” and then share those individually amongst different themes.
We then switched topics to hear from Courtney what she sees on the training side. She noted that there’s likely a huge market that is not going to instantly switch and need to think about how do training for moving away from older methods.
We talked about having more “small chunk onramps”, particularly around having courses for blockBlockBlock 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. widgets and block navigation and how to adopt with more details.
Dave noted that both editing with block based UIUIUI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. and rendering with blocks is new when being able to edit the whole site. It’ll be an excellent thing if we can get folks comfortable/familiar with that concept without jumping into the site editor first via the widgets and navigation work.
We talked through how neat it would be from a training perspective to have various levels of adoption outlined so folks don’t have to dig in to know what might be best for them to try first. This could like similar to this approach in this GutenbergGutenbergThe 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/ Times post on Customizing WordPress Block Editor for Client Projects. Anne is going to explore this.
We then discussed what the Hello Dolly + underscores theme equivalent is in today’s world and whether less needs to be known now with block themes.
The topic of how to lock things down while still adopting features came up. There’s a balance to have between adding items for theme developers (keeping options open to foster creativity) and then eventually what the user experiences (likely need more guardrails/locked down options).
A few of us chatted about eventually wanting to have more conditionally logic with templates, similar to what can be done with PHPPHPPHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. now. For example, Anne shared that it would be lovely to have categories of posts with different templates so she could link to the WordPress categoryCategoryThe 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. with a different menu for speaking at events so personal posts are stripped out.
In the future, Anne talked about how neat it’ll be to run explorations or calls for testing around setting a timer for 10-15 minutes and seeing how far one can get in changing your site. This is where theme.json has such a greater safety net than the previous dangers of trying to edit the code of your site.
We ended chatting about how all of this is putting art direction in the hands of people so they can say proudly, “I didn’t do it but I did it with WordPress.” We all love patterns and agree that they are, in many ways, democratizing design.
Ideas for improvement
Better error messaging with theme.json.
Improved theme.json documentation, including how to disable features, lock items down, and using a syntax editor.
Resources for how to adopt features across varying levels of difficulty.
Learn WP courses for adopting block widgets and navigation (more “small chunk onramps”).
