This post was inspired by Justin Tadlock‘s post on WP Tavern entitled “Themes of the Future: A Design Framework and a Master Theme.”
Justin’s post touches on aspects of WordPress theming that I have contemplated over the past decade while working with WordPress. But some of my thoughts differ from Justin’s because — unlike Justin — I am not a designer nor am I a themer.
“Imagine if — starting with version 6.0 maybe — the WordPress team chose to actually deprecate themes, and then added modules and components as first-class extensions instead? “
Mike Schinkel
Instead I often wear the hat of a PHP/MySQL/Javascript developer who works on WordPress sites. But more importantly for this post, I also wear the hat of a frustrated end-user who has always struggled to build professional looking website for my own uses, since I have absolutely zero design skills.
ASIDE: For those of you reading this who know I am a professional WordPress developer/engineer and are curious how it is I can work with WordPress and am not be able to create an attractive design, the answer is simple. I always work on client projects with a team, which will include a great designer and/or front-end developer.
IOW, my expertise is back-end development and the architecture, maintenance and devops for complex mission-critical WordPress sites. I leave making sites attractive to other people who are great at that kind of stuff.
My frustration related to WordPress theming has stemmed from the state of theming in WordPress and how it feels like many themes are viewed by their creators as works of art, and less like a functional layout designed to provide website owners a layout that meets the (business) objectives for their the website.
As a non-designer, I have tried god-knows how many themes. Ultimately however I have thrown away every. single. one. of. them. I either built a theme from scratch when I had a designer and/or front-end developer on the team, or more often, given up on launching the site.
In my experience any given theme does at best only 85% of what is required for its use-case, and I don’t have the design or CSS skill to finish the other 15%, hence my frustration. Not to mention the fact that (IMO) the more attractive a theme is, the greater likelihood that its code will be a complete mess of spaghetti that is almost impossible for anyone other than the original author to modify.
(Almost) all themes for WordPress are monoliths that end-users cannot maintain themselves, except for those with a myriad of settings (which are typically frowned on by WordPress thought leaders.)
But even those themes with a lot of settings can meet a higher percentage of any given end-user’s needs, typically the more settings a theme has the more complex they are and the slower-to-load they are. Worse, said themes locks a user into never being able to update their theme without a herculean effort and/or paying a king’s ransom.
Personally, I have never found a theme that is 100% useable without some significant HTML+CSS customization and/or PHP/MySQL/Javascript customization. And even the best themes use development approaches that require a going onlarge time investment in content maintenance because the themer made easy coding choices rather than build functionality to allow managing content with less effort. Examples include using categories to group content where a custom taxonomy would be better, and a custom post would be best.
Just the other day one of my clients asked me for help: “We need help setting up a new WordPress site, and we have picked out a theme.” I told this client that whenever tells me they “have already picked out a theme” it causes an immediate feeling of impending dread for me.
In this particular case I recommended they use a page builder instead of a theme. But not because page builders are a good solution but because they give enough control for an end-user to complete a site without having to bring in the high-paid and temperamental developers and/or designers.
But “high-paid and temperamental” is not a slur! I too am high-paid and temperamental; I just know that few use-cases where WordPress is used can justify the fees of a high-paid person to complete a site.
Returned back to Justin; he writes about “needing more designers in the conversation” — to which I agree with — but in the next sentence he discusses minutia about class naming which just sends designers and front-end developers down a path of so much bikeshedding. Better to focus on the high-level goals rather than the lower level details.
Justin also states that if “you put 20 designers in a room and ask them to discuss design frameworks, it could be a recipe for fisticuffs.”
Which is almost certainly true, but what he does not mention, or possibly does not recognize, is that once a framework is put in place everyone pretty much just falls in line and starts using it. Take a look at Custom Post Types, the Customizer, and even Gutenberg. If WordPress were to implement a design framework into core — and many people would piss and moan about it at the time — almost everyone would fall in line and start using it within a year after release.
But I do not think that a adding a design framework is the right approach. Or should I say I do not think a design framework would be sufficient.
Instead what IMO is really needed is for WordPress to embrace the web components standard and forget thinking about themes altogether. Rather than selecting and installing yet another theme what would be 1000% better for the end-user would be a pallet where they can select components — and composite components a.k.a. “modules” and then assemble their site with those components however they need it.
Rather than look for a theme that has all the features one needs — which I have found always limits the choices to zero — a site owner could look for the components and modules they need and then assemble their site from those modules. They could pick a header, a footer, a home-page hero, a set of article cards, a pricing module, and so on.
This is basically the same concept as the existing page builders, but with a standards twist; read on.
Existing themers could innovate by creating palettes and families of components designed to go together, and WordPress could possibly even create a marketplace for those components so that end users could buy different components from the different developers that they can be sure are designed to work together based on shared design “schemes.”
Frankly I think themers who sell themes would make a lot more money if they sold individual components and modules instead of full themes. And I believe most site owners would be super happy to pay a lot more for a collection of modules and components — I know I would — because they would be getting exactly what they need, and not 50-85% of what they need after which they have to invest a king’s ransom of money and time to complete the final 15-50%.
Justin also wrote “Themes would lose their personality and we would live in a world of cookie-cutter designs” if WordPress were to introduce a theme standard into code. But I say that is just fear of change talking. Constraints are your friend, and constraints can supercharge innovation.
What we have unfortunately seen since the dawn of WordPress is lots of innovation in theming, but most that “innovation” has been duplicated 1000 times over, each time by a different themer, and in a manner that is completely incompatible with what the other 999 themers implemented. None of those themer’s work can be used in combination with the work of any others.
A user can’t take the home page of one theme and the pricing page of another theme. If the theme they like does not have all the components they need — and when does a user ever find a theme that meets all of their needs? — they are pretty much out of luck.
Themes are all silos, and never will any two meet. Theming in WordPress has been like the biblical Tower of Babble where no themes can speak to each other, so we have not been able to build much beyond the themes that exist.
Imagine if — starting with version 6.0 maybe — the WordPress team chose to actually deprecate themes, and then in their place added modules and components as first-class extensions instead? WordPress itself could provide the canvas on which to place components and then WordPress could manage displaying them.
If WordPress core were to deprecate themes and embrace modules and components there would be no cookie-cutter designs; it would free designers to build self-contained user experiences within modules — and those modules could be mix-and-match — and then the sky would be the limit because themers would not have to deal with all the non-creative minutia required to build a fully working and fully workable theme?
But let me address the elephant in the room; Gutenberg Blocks.
I did not speak to Gutenberg Blocks because I have no experience as a developer with them. But what I understand — which could very well be an incorrect understanding — is Gutenberg Blocks are complex and have not really been designed to be used when Gutenberg is not generating and/or orchestrating them.
My guess is that Gutenberg blocks are almost certainly not designed to the web component standard and are implemented using a set of fragile CSS conventions and Javascript frameworks. Which is an architecture that will quickly become legacy as the state of the art in CSS and Javascript development evolves, as they do.
I also question if WordPress core will be able to maintain the same level of backward compatibility that it has maintained prior to the Gutenberg era. Methinks the complexity of ever-changing Javascript and the Gutenberg implementation will make robust backward compatibility nigh impossible in the coming year.s
But what about all the existing page builders? The problem with page builders is that their modules/components/blocks are all proprietary (AFAIK?)
Their modules/components/blocks also work in the context of the page builder but not designed to be developed and/or used without the page builder. I don’t mean to say they do this to lock people in, only that the architect a flexible framework would IMO be an order of magnitude harder than just getting a page builder to work with proprietary markup and CSS.
So ideally WordPress would offer a framework based on web components standards that could support a page builder UI — or many different page builder UIs, each from different vendors — but could also support hardcoding of the components into pages for those who like to version control their websites.
Well, this turned into quite a rant. Once I started writing it just flowed, so this has clearly been a pent-up frustration in me for years.
I know even the thought of deprecating themes will send fear and loathing shockwaves across the WordPress theming ecosystem. But please, before summarily dismissing the idea with a knee-jerk, contemplate the possibilities of delivering modules and components designed to be mixed-and-matched instead of churning out yet another theme that can never be used in conjunction with the work of any other themer.
Hi Mike,
Interesting idea. I think for anything to work on the scale of WordPress you need an architect who has done it before. As a developer you know that often there is a trial and error, revision cycle and solutions come together over time. There was some of that with Gutenberg … which is probably why there are inconsistencies for theme builders.
I wonder if something as simple as standardized class names would provide more interoperability between themes?
I am a bit surprised by your deep frustration with modern themes and perhaps there are some misconceptions. Lots of options (i.e. in the Customizer) might slow things down when using the Customizer because of all of the JS controls, though many themes have now worked beyond that. Themes like Page Builder Framework (or Astra, Generate Press, etc) offer plenty of Customizer options, but load quickly when the site is visited.
Keep thinking outside of the box.
Regards
Hi @David McCan,
Thanks for the comment.
My concern with standardized class names is they would require the developers to actively opt-in instead of just redoing it the way they prefer. And that assumes that the developer pays enough attention to even know there is a new standard. My belief is the only way to address change like this is for core to only work correctly when the developer follows the new standard.
As for my frustration, my post probably over-emphasized the complexity and performance as a problem and under-emphasized lack of capability/flexibility to achieve the site goals. And often it seems that the things I want to achieve are a common UX around the web but are very difficult to accomplish with any given theme.
That said, once bitten twice shy and I have not tried to set up a new site of my own for several years, although I will need to do that in the near future. What I will probably use is Mobirise — which is the best website layout tool for non-designers I have ever found — and it does not even support WordPress so I will basically build the site with Mobirise and then write a theme based on that HTML & CSS that it generates.
Gutenberg blocks are simpler than you think they are. Also, welcome to the same realization I had about 18 months ago. 😁
A block is basically a user interface to create HTML. Doesn’t matter what the HTML is. Can be anything. Can have styles, or not. Whatever. At the pure form, it’s a JavaScript based “form” to create HTML to be inserted into the post content. The post content itself ends up being straight HTML. No JavaScript needed to display it.
So. Yeah. That’s where it’s going. If you want to make a block that creates custom web components, nothing preventing that as far as I know. Everything produced still ends up in a post content as HTML. Feasible, certainly.
Hey @Otto,
Thanks for the comment.
I think maybe we are talking two different things about the blocks. It seems you were talking about how the content is stored in the post — as HTML — and I was talking more about the Javascript implementation of the blocks whose purpose is to ultimately store that HTML.
I was also talking about CSS and how — based upon articles like this — it appears Gutenberg requires that all block’s styles to be good citizens and follow conventions to ensure they do not clobber other blocks. But if core where to embrace web components then HTML & CSS would be sandboxed per this article (emphasis mine):
As for creating a Gutenberg block that creates custom web components — absolutely that is possible — but that that is a bit of a moot point because doing so would not address the reason I proposed them. Web components need to be first-class in WordPress core or the blocks that are not web components do not get the benefit of sandboxing. An analogy might be the difference between installing a firewall on a server and installing a firewall around an app for a single port; sure the one app is protected but protecting that one app does not stop hackers from compromising the computer on which the app is running.
But let me say this; I am not against Gutenberg. Ideally Gutenberg will be the way forward and will be able to possible embrace web components as a near future enhancement as Gutenberg has far more interia that any potential alternative. And maybe a new feature version of Gutenberg will embrace web components as first class in which case any debate we are having on this will likely be moot.
BTW, the reason I am paying attention to this now is I am a leading a team of WordPress developers and we are re-architecting ~10 sites to use a shared plugin and we want to implement everything as components rather than design and build pages as they always have. We’ve looked at a lot of solutions, and the one I propose here is the one that we identified as the best solution currently available without switching to full single-page app or using Gatsby. Of course getting getting WordPress core to adopt components is not part of our plan — it would be foolish to expect that — but it would be great if we did not have to reinvent so much of the wheel to get a fully componentized infrastructure for the needs of this organization.
Bottom line, I just want standardization of a solution that works without more complexity than absolutely necessary. Gutenberg is a step in the right direction, but the jury is still out if it will be able to take us all the way, or not. Time will tell I guess.
I would advocate for not forcing and prescribing such changes of the WP ecosystem.
This discussion started a few weeks ago, and since this is about the 10th article about the death of WordPress themes. The funny thing is that each and one of these articles have been written by developers, not designers.
I think the changes described in this article are not for the future, but simply describe what’s happening now. For the end user Gutenberg means blocks. Blocks lead to a new source of income for JS-savvy WP devs, and if you take a look at how people are making money as WP developers/designers, you can see we already have the new market offering various blocks and block-related plugins. This market will flourish, and certainly, the theme market will somewhat decline.
But why would these latest developments/changes require the destruction of the whole WordPress theme system and the rich theme landscape? Because you’re having bad experiences with the themes you used in your projects? Are you 100% sure this doesn’t reveal something rather about your approach to WP theme implementation and customization projects?
Personally I’m glad to see and live this important chapter of the WP evolution – and I also think that themes are a very important piece of this great and now-again competitive product.
And yeah, I get angry when reading these “WP should do this and do that” type authoritarian approaches. Could we rather just accept the diversity of WP features and enjoy the variety of ways users can organize and display their content?
Btw this topic reminds me of what happened after the inclusion of Gutenberg in the core – lots of nightmare feedbacks, lots of users switching to other systems – finally the Gutenberg dev team made a compromise and included a Classic Editor to extinguish the fire, at least partially, by bringing back the traditional editor as part of the new page builder.
Hi Mike!
First, I have to say I like the idea of web components. At the same time I think they are more for professionals. Imho, they are unusable in WP ecosystem. The vast majority of users of WordPress are… just users, non coders, not even 5 lines of html/css writers, kind of. The main reason of why Gutenberg is built how it is built is because Auttomatic does not want to give up the idea of ‘WP for everybody’. Recently there was a publication about how good or bad optimised popular CMSs are, and WP is far from the top of the best optimised ones. Because for everybody. It means everybody uses it how their able to. That’s it. So, as for me web components tech is just kind of too much. At least at this time.
Second, it does not mean nothing can be done. Or could be done, because Gutenberg is already Gutenberg as it is, you know… Ok, my opinion, that themes should not be deprecated, but radically transformed into pure presentational units. No functonality (leave it to plugins), pure design. More my thoughts here, you can check if you like: https://moomoo.agency/pagebuilder-mccloud-sir/
Thanks!
Hey Mike!
A very bold take killing themes entirely. I read Justin’s article as well as a few other opinionated articles about theming in general.
After all the reading I’ve done, and my own work as designer and frontend developer in WordPress, I think WP is making the right move–making themes more of a ‘style guide’ than a functional website. That’s been our approach for the last 9 or 10 months to have themes be more of a ‘skin.’
We’ve taken this into account with all of our new plugins, themes and tools for our client sites.
The themes we create for clients now all start from a minimal starter theme. They cover the templates we have to, and the basic design style guide you’d need for a website, (typography, form fields, buttons, color palettes, textures, etc.) and that’s about it. We even isolated most of the ‘style guide’ CSS into its own files so we’re only changing a few variables, and then overriding a few of the main templates like header or footer.php–and that makes the entire site look like its running on a different system altogether, even though the same starter theme and plugins drive all of our sites.
All of our layout and design patterns are handled by our grid block, or the saved/reusable templates we’ve created for our client. We give them a bunch of other common layouts as well in case they need to accommodate different content amounts/types after our work is done launching websites for them.
Our starter theme is essentially a Squarespace-looking grayscale helvetica site that we then add the branded style elements to, and any other frontend components they may need so it’s more of an additive process to building out sites vs taking away all the shit you don’t need like we used to with premium themes.
Unlike old themes that are bloated and full of things you’ll need to customize (as you pointed out) we’re just adding the style guide to our design system now. The blocks plugin can handle all the layouts and where things show up, and the theme handles the aesthetics of what it looks like.
It still does make sense to use ACF, and custom form fields for single posts should they be standardized on the frontend, (like event posts or something like that) but for landing pages that most websites have, and more in-depth pages like PPC landing page templates, it’s good that users have flexibility to drag/drop saved layouts depending on what their goals for the page are, and what types/amount of content they have available.
Giving marketers and WP content managers freedom to develop those pages from a set of design patterns, vs trying to standardize all that input into fields has been a much better arrangement for us and our customers.
Clients use their sites more often, and for more initiatives, which is ultimately better for us as an agency because the website is seen as an asset that’s generating revenue and interest, vs. something they have to deal with that takes hours to update and get right.
Just my two cents.
-T
Gutenberg blocks are simpler than you think they are.