In a classic theme, templates are PHP files where we can use WordPress’ predefined functions and our own together to get, manipulate, and show data. In a block theme, templates are HTML files, so we can not add PHP functions.
For example, dynamically adding the current year to the footer of a classic theme is a straightforward process.
- We locate the template we want to edit, in this case:
footer.php - We look for the text showing the year:
© 2019 Company - Change the number written in text for a fragment of PHP:
© <?php echo date("Y"); ?> Company
It is ready. From now on, we do not have to change it anymore, as this will always show the current year.
Doing the same in a block theme is not that simple.
Locating the template is very similar. And we do not need to edit the file directly, we can use WordPress editor. However, we still can not add a PHP function there.
Does this mean we can no longer use PHP in our templates? Not at all, we just need to do it in the right place.
The proper way to do it is with a plugin.
- We can use a plugin that creates a shortcode to display the current year and use it in our footer with a shortcode block.
- We can use a plugin that uses the hooks provided and add dynamic content to a block.
- We can create a dynamic block that will be available to use in the editor. This is done, also, in a plugin.
There are other inappropriate ways to do it.
- We can use our theme functions file to create a shortcode or use a hook.
- We can use PHP fallback templates, that will be used if its HTML equivalent is not present.
- We can insert some PHP in a block pattern because they are PHP files.
All of these methods make the same mistake of placing functionality that is not related to design and presentation in the theme. This has been a requirement for submitting a theme to WordPress.org for years, meaning this is not how it is supposed to be done.
Why is that? Mostly because it breaks the integrity of the whole system. It may sound pretentious, but it means that by not using WordPress the way it is designed, we are creating new problems.
The most important is that if we activate a different theme on the site, the code does not work, because we included it in a theme, so it works as long as that theme is active.
So far, I have written about consistency in the system, and how important it is to separate design and presentation from other functionality. But one question remains unanswered.
Why do WordPress’ block templates no longer use PHP? What is the reason behind it? The short answer is states.
The block editor is the application behind blocks in WordPress. It is since version 5.0 integrated as part of WordPress core, but before that, it had to be installed as a plugin named Gutenberg.
It uses a Javascript library called React, and on top of that, it uses @wordpress/data, its version of a library used to manage states called Redux.
What exactly is a state? Let me try with an analogy.
Picture an application as a theatre play. It has a script, which is the code. And also actors, which are the components. For classical theatre, it works. Each actor knows their part and plays accordingly.
Modern applications are more like improvisational theatre. Each actor may have a foundation for their character, but they must react — no pun intended — and build upon the actions of the other members of the cast to move the story forward. The state is the story, that is not written, but can be kept and built upon for the duration of the play.
States are a very effective way to keep track of changes in components, allowing the block editor to reflect instantly the changes we make in any block: content, position, attributes… and outperforming PHP in the front.
If the price we must pay in exchange is not being able to use quick fixes, I think it is a fair price.