A developer-centric call to test the theme’s JSON configuration – WP Tavern



Round # 8 of the Full Site Editing (FSE) Outreach Program started yesterday. Instead of the user-centric call to test user interface functionality, program manager Anne McCarthy asks volunteers to dive into the code. The new adventure is to test theme.json files.

The twist risks limiting the pool of regular volunteers. However, that could open it up to an audience that may have been left out of previous testing: theme developers.

Before we jump head first to the theme’s JSON files, we should probably all be on the same page.

I called theme.json the tipping point between the old WordPress and the new WordPress. When version 5.0 of the main platform launched in late 2018, it was a revolutionary step forward, but not on the surface. A new publisher is just a new publisher. Some will love it; others will hate it. And, it was more often awkward than not. For the most part, WordPress was still WordPress.

The core software had to undergo a major upheaval. New technologies not only democratized publishing in their own way, but they also brought that same concept to design.

The introduction of blocks was simply fundamental. The new editor was an imperfect tool, often giving the impression that the proverbial round peg was driven into a square hole.

The only way to live the initial vision of Project Gutenberg was to continue to bridge the gap between what the user sees in the admin and what is displayed on the front end. This is what the theme.json file is all about. It’s a translator that lets users, themes, and WordPress all speak the same language.

What does this mean exactly?

From a user’s point of view, he sees all kinds of controls to change his blocks. Color, font size, alignment, and other options are tools that allow them to customize their content.

Customize a profile card for my cat using blocking options.

There are serious limitations with what is possible in the current system. Theme authors can save a handful of options. Other than that, theme and block systems can make it look like they are pitted against each other for control.

This is where the theme.json come. It allows themes and WordPress to be on the same page, creating a standardized system that improves user experience.

This file which resides in the root folder of a theme gives the power to configure dozens of presets (e.g. color and font options), custom CSS properties, and default styles for blocks and HTML elements. .

It also gives users the power to turn specific features on or off. For example, developers can turn off the ability for users to set a custom font size but provide access to their perfect scale of choice that adapts to the vertical rhythm of the design.

However, it will go beyond just configuring blocks in the content editor. When the Global Style System is launched with the Site Editor in the future, users will customize many presets and override the default block styles. Because everyone speaks the same language, fewer conflicts arise.

As designer Tammie Lister pointed out in her post for Ephermeral Themes, Theme.json inspires, themes have been blocked. The software, the community, has put too much responsibility on the shoulders of the users over the years. They had to innovate and build the systems that should have come from WordPress. Not only did the main platform have to be overturned, but the design system deserved an overhaul.

“I’m very much aware that saying ‘first major theme-to-core process’ in years is quite a statement,” Lister wrote. “Theme.json for me, that’s it. I’m not saying that ignoring iterations and enhancements, WordPress is a project flowing with the energy of those. However, the themes were on life support stuck in a country as the rest of frontal development was moving forward. It was not for some to try to change that, especially when they did, the timing was not right and as it was not coming from the core, it was was always a more difficult change.

It’s time for a new era of frontal design. But, first, we have to test.

JSON test theme

Screenshot of a theme.json file in a code editor.
Real world theme.json file.

The further I went through this call for tests, the more I realized that this was not right for me. In the past two months I have already been working from theme.json drop off. I know most of the little quirks and see the gaps. The tips for working with this seem second nature to me.

I have done all the beginners and intermediate steps dozens and dozens of times. I have already submitted tickets for all the issues I have encountered. Or, someone else already beat me in the fist.

These steps in this series of tests need a fresh look. The best feedback will come from theme authors who will see the issues through a different pair of lenses. If you are in this group, there is no time like the present to test and give your opinion.

The advanced stage asks to recreate a classic theme using theme.json. It’s best to stick with something simple. Otherwise, you might consider a multi-week experiment. McCarthy recommends Twenty Twenty or Storefront. I’ve played this song before and danced too. My test project was an old theme that I gutted and turned into a block theme.

There is a fundamental question that I keep coming back to. This is because theme authors must work from a JSON file.

I understand the “why” behind using JSON. It is a universal format that can be changed from JavaScript to PHP. Third-party APIs can figure this out.

However, I am currently sitting on over 900 lines of code in my theme.json. I’ve heard from a few other theme authors who have done extensive work with similar numbers. I expect him to only grow taller.

The “number of rows” is not necessarily a measure where a specific total is a point of division between “good” or “bad”. The problem is that comments are not allowed in JSON files. One of the cornerstones of solid development is documenting code. Skipping the documentation for a few dozen lines isn’t that bad. However, when you go over 900 things can get out of hand.

Also, at some point you start to want to divide the songs into their own groups. This amount of code requires better organization.

The thing that is missing right now is a PHP layer for theme authors to use. Remember that JSON is a universal format. It is easy to convert PHP to JSON and vice versa. Building this layer for theme authors would accomplish two things:

  1. They can organize what will probably be thousands of lines of code.
  2. The transition to the new system will be easier.

This last point is probably the most important. PHP has been the language of theming for as long as theming exists. Developers know this and use it at ease, and WordPress should meet them in the middle. If we fill in any gaps, this is the one that needs to be filled before other configuration possibilities are added and theme.json files turn into cumbersome 5,000-line giants.


Leave A Reply

Your email address will not be published.