Justin Tadlock
Last week, I played around with a new plugin that allows users to export a custom theme.json
file. The project is still a little buggy at the moment, but I look forward to covering it in more detail soon. The export function was more of a secondary objective for the plugin, but it represents a feature I look forward to landing in WordPress one day.
While tinkering with the plugin, I reminded myself to check on the progress of a related ticket for Gutenberg. Currently, the site editor feature allows end-users to export their theme templates. However, there is still no way to do so for global styles.
Essentially, block themes need two components: templates and a global styles configuration. There are other pieces. The functions.php
file is increasingly unnecessary, and the standard style.css
file is often used for adding theme data instead of CSS. There is talk of adding both /patterns
and /styles
folder support for automatically registering block patterns and global style variations, respectively.
WordPress theme development already looks different than it did just a few years ago. Soon, old-school themers will hardly recognize it.
That is not necessarily a bad thing. The ongoing mantra is that the platform seeks to democratize design much as it did for publishing. I have often wondered how feasible such a goal really was. I would see sparks of genius littered throughout the project in the past few years. It took a while for all the moving parts to become a well-oiled machine. There are still some missing components, but the platform’s promise is becoming a reality.
Over the weekend, I happened across an old friend’s Facebook profile. He is one of the few bloggers I began following in the early 2000s. I noticed he had shared something from his blog, and I checked it out. He has a background in journalism, and he has always had unique insights into what most of us might consider the mundane, day-to-day life stuff.
I continued reading other posts. It was a welcome change of pace to pour through thoughts from someone who is simply blogging for the sake of blogging, even if still on Blogger and not WordPress. The site does not look any different than it did years ago. He even has a blogroll. I spent about an hour going from site to site, reading the ramblings of other passionate bloggers, most of them on the self-hosted WordPress software or WordPress.com. It was a reminder of why we continue building this platform.
Of course, we all have different reasons for coming to the same place. We must also have a healthy economy behind WordPress, which helps fund the project’s more altruistic mission. At the end of the day, the goal is to provide free software for the masses, offering an alternative to the gatekeepers and walled gardens elsewhere on the web.
Theme design needed to be shaken up. I enjoy finding the odd diamond in the rough. But, it has been a long time since the average end-user has had true freedom with their website’s design. Kubrick was fine in the mid-2000s. WordPress catered to a DIY crowd that was OK with making CSS changes to get their desired outcome. However, in the 2020s, the platform must bring a new set of tools to a wide-ranging audience. That is what the global styles feature is all about.
When WordPress 5.9 launches next month, many users will get a taste of the site editor. Users who switch over to the upcoming Twenty Twenty-Two theme will have more design power at their fingertips than ever before with stock WordPress. From templates to styles, they will change the front end of their sites to whatever they dream up.
Some will undoubtedly stumble upon the “Export” button in the site editor:
It is a handy tool for theme authors transitioning to block theme development, but that little button has a world of potential. Right now, it spits out an edit-site-editor.zip
file with a /theme
sub-folder. Within that, sits /templates
and /parts
.
What is missing is the theme.json
file, which represents the global styles. When that lands, users will essentially be exporting an entire theme. Well, minus a screenshot and required legacy files like style.css
.
Part of democratizing design is not just handing over the ability to customize the site. Fulfilling the mission means people can share those designs. The next generation of WordPress themers will not be stuck in a code editor like those of us today. They will cut their teeth on the built-in site editor. Some will graduate to more advanced development, but others will have everything they need to publish their themes on WordPress.org or even venture out and build their own businesses. In part, it will level the playing field for those with an eye for design but not the coding chops to create those projects.
Exporting global styles cannot get here fast enough. Then, we need to add pattern exports to the equation, but the mission requires we take it one more step.
I look forward to the day when a user can build an entire theme from scratch in WordPress. Then, they submit it to the theme directory without writing a bit of code. Could one of those “average” bloggers find a talent for web design they never knew they had? Could someone who always wanted to learn but did not have the time/resources/privilege create the next most popular theme? I like to think so.
Exporting global styles cannot get here fast enough. Then, we need to add pattern exports to the equation, but the mission requires we take it one more step.
Couldn’t agree more. For anyone looking to see where this work is being tracked, I wanted to be sure to include a link to the relevant GitHub issue: https://github.com/WordPress/gutenberg/issues/27941 A PR is in progress but has slowed ahead of 5.9 from the looks of it: https://github.com/WordPress/gutenberg/pull/36619
After not reading WP Tavern for a couple of months, due to conflicting interests I came back to take a look.
Once again I sees this once great publication marching to the beat of the Mullenweg drum.
WordPress is a shadow of its former self, doing everything it can to alienate the core users an cater to some romantic idea of an audience who wants to build websites with a squarespaceesque toolset, and all the hassle of self hosted CMS.
With everyone else going more or less headless, WP has managed to make the editor 100% dependent on frontend code. Destroying the user experience, making development inexcusably cumbersome.
For the love of god, why is this still happening!?
I’m not sure what Matt Mullenweg’s thoughts are on the future of theming — I haven’t talked to him. The above are my own. If did not like the direction that theming is headed, I would simply say so. And, I absolutely call out things I do not like. My past posts are littered with such thoughts.
I am a core user of WordPress and have been for over 16 years now. I do not feel alienated. I have never tried Squarespace. If its tools are anything like what WordPress is building, that’s pretty cool. I love the overall direction of the project. Maybe it is the romantic in me that wants to give more power to the common people and remove the barrier to entry to website design. I am OK with that. I would rather WordPress aspire to break down those walls than only cater to one specific crowd or another.
But, honestly, I do not even know what the definition of a “core user” is anymore. WordPress powers over 40% of the top 10 million websites on the web. There is no singular definition for a core user.
To be honest, while I do think that romantic ideals were a relevant factor, I think page builders were a more pressing concern, and a desire to give editors more graphic feedback – in the “core concepts” there is a statement to think of blocks as “glorified shortcodes”.
My main problem with the Gutenberg development process is that, in the beginning, it seemed largely decoupled from the needs of any user. When released, it was hardly usable for anything. As opposed to most page builders, it didn’t even offer a simple UI to position elements relatively. All there was was the option to add a css class. And on the development side, the first useable toolchain came from outside the project itself. So much for “developer experience”, even ignoring that developers were probably more attuned to php than to js/react at the time. That wasn’t well executed, or communicated.
And even now, 3-4 years on, and with a clear commitment of the eco system to go down that road, there’s still no clear way to simply do some things in Gutenberg that are a piece of cake in php. You yourself mentioned some earlier this year -https://github.com/WordPress/gutenberg/issues/32939
Talk about blocks as glorified shortcodes. Gutenberg is emphasizing page-contained visual content/editing over data input in editing masks/post types, for which it’s not that important if the admin view equals the front end (irrespective of whether a static or dynamic templating system is used). I would say that the former is more relevant for personal sites while the latter is the bread and butter of most professional applications of the CMS.
Yet this very important part of the eco system hast not been given too much concern with respect to Gutenberg. There’s a lot of talk about “better development experience” but the opposite is usually the case, not least because of a lack of usable documentation about how to code common things “the Gutenberg way”, even if it’s possible.
My hunch is that these things will be added, slowly, and I very much understand the strategic impetus for Gutenberg in all phases. But it would really be great if the communication could be changed to a tune that would make the people developing those currently “common” CMS things feel less estranged by Gutenberg. In my opinion, a lot would be already won by helping them develop things they develop today using the Gutenberg way.
I’m pretty sure, it would also help figure out some remaining problems with Gutenberg.
Elementor lets me build themes in the current wp theme/files metaphor without hand coding. I’ve never been a fan of page builders at all. I don’t know if elementor will be relevant in 2 years as it has an info architecture problem at present. If they can re-simplify their theme builder I’m not sure I would switch to anything else for 5 years. Long live notepad!
That’s great! I know a lot of folks who love the plugin. What I would like to see is these types of design tools be used to create projects that go back into “the commons,” so to speak. If a user is creating their own site design (or, even just pieces, like patterns), we need to clear any hurdles that stop them from sharing their creations with others. Today, that very much means that you need to be a developer. Tomorrow, maybe that barrier won’t exist.
As long as WordPress doesn’t force us to use the FSE I think this is a good thing. The FSE might be of use to your average user, but for web developers, it’s never going to replace working with code in an IDE of your choice, the ability to use version control (i.e. git), leverage package managers (i.e. composer), use CSS extensions (i.e. Sass) and all of the other tools and best practices that web developers use. Hopefully WordPress doesn’t forget that web developers use their software.
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
WordPress Tavern is a website about all things WordPress. We cover news and events, write plugin and theme reviews, and talk about key issues within the WordPress ecosystem…
© All Rights Reserved. Powered by WordPress, hosted by Pressable