Table of contents
- The interview
- When did you start thinking about working with the Site Editor? And what was your first thought about creating a Block theme?
- That was a big decision. What trigged your enthusiasm?
- What happened when you started off?
- What were your initial concerns about full-site editing?
- So, what made you bet on this then, knowing it would mean a massive investment?
- Do you feel you are in a feature / functionality rat race with the Full Site Editor?
- What advice would you give to WordPress developers who are thinking about working with full-site editing?
- How long did it take for you to get used to the new terms that were introduced?
- Do you have any last tips for all readers?
At the time of the release of Greyd.Suite in 2021 it was apparent we were in for a challenge. The WordPress Block editor kept (and keeps) evolving. New features are first created and tried in the Gutenberg plugin. When they are working well, they are introduced to WordPress core. This makes full site editing a continuously improved experience.
Any member of our team could talk for hours about the broad line-up of features that Greyd.Suite has to offer but given that we are very close to the release of our Block theme, we think it’s a good time to interview Jakob Trost, our CTO, about the considerations, and keeping up with developments in WordPress core.
The interview
When did you start thinking about working with the Site Editor? And what was your first thought about creating a Block theme?
I can’t remember how long it’s been, but that happened when we first saw the first beta stage or probably even the first design discussions about the Site Editor. That was the point where we automatically knew we had to support this. We literally said to each other, “We have to do this!”.
That was a big decision. What trigged your enthusiasm?
Our solution was already block-based. Staying as close to WordPress core as possible, using native features of WordPress, ensures that our customers can always profit from the latest developments in WordPress, and enjoy maximized compatibility with other WordPress tools. So they have a state of the art product to work with.
Besides that: Staying as close to WordPress core as possible is a good way to avoid backwards compatibility issues and technical debt.
So, we knew we needed to also be a full-site editing-based solution. To us, at the time, it was apparent that the Site Editor was going to be the future.
Our thought literally was: Okay, this is the next thing that WordPress does. It looks nice. It gives a lot of opportunities. Obviously, it needs work. But this will be the thing for the future, and we will have to work with it, as is, while it’s evolving.
What happened when you started off?
We didn’t start off immediately when the Site Editor was in its first raw phase because it had less capability than we already offered in our own solution.
We waited until the functionality of the Site Editor at least had a decent amount of what we were already able to do in our solution. It would have made no sense to invest in working with it when it would actually mean a downgrade from what we were already offering to our customers.
After a couple of months into the first release, we started seeing the progress and we started developing based on the Site Editor.
What were your initial concerns about full-site editing?
The first thought we had was: “Uh oh, this does exactly what we are doing!” Which is kind of scary in those first moments. Because you think, “Okay, this is a valuable feature we already built. A good example of this is the option to globally set styles.
Pretty much, as seen from a technical solution, our extension offered possibilities really similar to what global styles in full site editing is offering. In our classic theme we have CSS variables that are exposed in the customizer, so the users can customize these CSS variables. And later, in the content part, you can just select these variables, so it makes it easier to swap out the entire design. Pretty much the same thing that Global Styles does in the Site Editor.
Code-wise the core development team of WordPress decided developers can’t have direct access to edit the Core Global Styles (yet). Which posed us for a challenge! In order to offer the granular design controls our clients already are accustomed to in our classic theme, we had to resort to building a whole new extension: Greyd.Styles. Aside from the fact that this makes it technically quite complex for us to maintain, we think it is not ideal for the user in terms of usability. But that’s a good topic for a separate interview on developer level.
And then there was the entire template editing solution, which is the second part of the Site Editor. We already offered a solution for that, too. We had dynamic templates. System templates, we call them. Users of our classic theme already had the possibility to edit the 404 page, the footer, single page, category-based archives, you name it. You could all build this inside Greyd.Suite already.
Which means that from a functionality standpoint, it wasn’t necessarily something new. But it was clearly something new in terms of interface. Obviously, the technical details are different to what we were building.
So, what made you bet on this then, knowing it would mean a massive investment?
Well, at the end of the day, we estimated that if a lot of experienced developers and designers work on this, probably it becomes a lot better than what we are building, and we can focus more on the more complex things our Suite has to offer. Because the capabilities that the Site Editor offers to build templates and to centrally control patterns and styling, are capabilities that should be standardized, in my opinion. It should always have been standardized, but it wasn’t.
The more we thought about what full site editing actually meant for us, we realized it was actually good for our customers and therefore good for us. We already had experience. We already knew what we were doing.
So the first thought was, okay, this is scary. This actually will take away a huge chunk of what makes our product valuable. But then on the other hand it made us rethink the value we bring to our customers. We have mistakenly been perceived as a page building solution by some. But in fact, we are a solution that is much larger than that and the page building capabilities are a perk on top of what we already do.
Having the page building capabilities largely taken over by WordPress core, that’s actually one of the best things that could happen to us, and to our customers. As it makes Greyd.Suite more flexible than ever. Full Site Editing is the cleanest and least bloated approach I have seen, to actually visually editing your entire website. It’s built with a lot of really good ideas and really good thoughts by the most brilliant people in the WordPress ecosystem.
Do you feel you are in a feature / functionality rat race with the Full Site Editor?
Factually, we are, but it does not have the negative vibe that the expression “rat race” has, at all. It’s an uplifting and very exciting process. We are now working more closely with the WordPress core team to ensure that our products are compatible with the latest full-site editing features.
Before features are added to the Block Editor in WordPress, they are developed in the Gutenberg plugin first. That means we are generally up to speed about what’s to come in a timely manner. Besides Greyd.Styles we have Greyd.Blocks. A set of blocks that have extended capabilities compared to core blocks.
In either, when a capability is coming to WordPress core, we take it out of ours.
What advice would you give to WordPress developers who are thinking about working with full-site editing?
My advice to WordPress developers who are thinking about developing a Block theme is to start by learning about the editor itself and how it works. There are various resources available online, including the WordPress Codex and the WordPress.tv tutorial videos.
Once you have a basic understanding of the Site Editor, you can start to think about how you can use it to improve your own products and services.
How long did it take for you to get used to the new terms that were introduced?
Ah, the wording, you mean. Yeah. That took some effort. Especially because in the beginning there were many discussions going on in the WordPress community about naming conventions. Around us we still hear people speaking about the Full Site Editor. Internally we sometimes still call it by the acronym FSE. It’s a habit that’s still to be broken, we do love our acronyms.
Do you have any last tips for all readers?
Yes! We have also created loads of video tutorials about working with the Site Editor and the Block Editor. Besides that, we will also soon release a whole new demo video of Greyd.Suite. Sign up for our newsletter if you want to know when these are published online.
