Justin Tadlock
With full-site editing just around the bend, it is a fair question to ask whether the WordPress ecosystem is prepared for such a transition, particularly on the theme development side of things.
It is no secret that theme developers have struggled to keep up with the barrage of changes between Gutenberg plugin updates and, ultimately, major WordPress versions. It is also a fair question to ask who is steering the ship. Where are the site developers, theme authors, and other designers who spend every day crafting the front end of the web? Where are the forward-thinking solutions that make sure the project maintains backward compatibility?
There have been some efforts to mend the broken divide between the Gutenberg project and theme developers such as the fortnightly block-based themes meetings. However, those meetings, by and large, are general updates on things the Gutenberg team has already developed or will ship soon. Those meetings are a good stepping stone toward better communication, but the project needs a project planner with both the vision of the future landscape and a sense of the day-to-day issues that theme authors contend with.
The reality is that there are only 132 themes out of 7,455 that list block editor styles as a feature in the official repository. We are a year and a half into the lifespan of the block editor officially merging into WordPress, yet the face of the platform is made up mostly of themes that have shoehorned some basic block styles into mediocre designs. The themes that truly stand out with full block-editor support are few and far between. Many of those are also bidding heavily on Elementor or other page builders.
Whether you like the block editor is of little consequence when there is no buy-in from theme authors. Every week, I check the theme directory for new themes, hoping to find a hidden gem. Every week, I am disappointed to see new themes dropping in 2020 with no support for the block editor. There is an entire segment of users who might enjoy the editor if only they had something more than Twenty Twenty to play around with — it is a fine theme but is not everyone’s cup of tea.
ThemeForest sellers are besting free WordPress.org theme authors 18 to 1 in terms of support with over 2,300 themes listed as Gutenberg-optimized. Granted, themes from the massive marketplace are known to have every feature they can in an attempt to one-up the competition. Also, many of them either have built-in page builders or support third-party solutions.
Still, for the flagship feature of the platform, end-users should expect something more from the official theme directory. A third-party marketplace should not be the only game in town. At the moment, much of the offerings on WordPress.org feel lackluster at best. The handful that go the extra mile, such as the Rosa 2 and Go themes, have mature businesses funding the effort.
There is some broken trust between theme authors and WordPress at the moment. Some shout it loudly (as folks can attest from WP Tavern comments section). Others are more quietly trying to figure all this out.
Even Carolina Nymark, one of the representatives for the official Themes Team, shared some concern. “How do all of you theme authors keep up with the changes to Gutenberg?” she asked in a tweet. When the team leads are not up to speed, it is not good for the project as a whole.
“I don’t,” replied Anders Norén, the primary developer behind Twenty Twenty, to Nymark’s question. “I wait until something breaks (in the beta releases) and try to fix it then. Trying to support changes in the Gutenberg plugin while maintaining support for the block editor in Core is bad for your health.”
There is a major concern from theme authors about the future. It is hard to get excited about the current possibilities when there is uncertainty over what theme development will look like in 12 months. There is no clear and detailed roadmap about how things will work, and many theme designers feel like they are playing catchup from week to week. Instead, they should be able to more clearly look ahead and push early ideas into play.
My ultimate fear is that the Themes Team will one day flip the switch and require all themes going into the directory to support the block editor like it had to do with the customizer in 2015. If theme authors do not organically make the transition such a day may come. The team will be stuck as the bad guys in the middle.
It is easy to identify some of the major pain points for theme authors. Changes between updates will inevitably break something with the theme design.
Breaking HTML changes.
Breaking CSS changes.
Missing class names.
Different methods of handling alignment, depending on the block.
Dealing with inline styles after years of being taught to avoid them.
All of these issues are roadblocks for theme authors. And, when things get in the way of theme authors doing their jobs, they trickle down to end-users.
This is not the WordPress of the last decade. The WordPress that promised to not break things with updates. The WordPress where a one-off theme by a non-professional designer still worked four months later.
The Gutenberg project is still in its infancy. It can be fun to play with, but it can also be messy. I am as much of an evangelist for the block editor as anyone, but I can recognize when there is a clear and present issue of trust between theme authors and the developers of the project.
Currently, theme authors who are attempting to cover all of their bases are designing for at least a couple of versions of WordPress, multiple versions of Gutenberg, and the classic editor plugin. It is a dizzying array of testing for one theme. Those with a dozen or more themes…well, it is not an ideal situation.
A holistic approach needs to be taken toward theme and site design. Theme authors need to see the details of the roadmap and contribute to it, carving the features they see as relevant into stone for the coming years. They need to know that the buttons block design they sweated over for hours this past week will continue working next week.
It all starts at the project management level.
If a breaking HTML change needs to happen, theme authors need more than, “X change needs to happen for Y feature to work.” They need to see ownership of the mistake in the initial planning phase for X, backward-compatible code solutions, and a path toward fewer of the same mistakes happening.
Theme designers still need some sort of design framework. The current utility classes are like a poor man’s version of Tailwind that is being pieced together as the project adds new features without the foresight to look at the future landscape. Maybe the upcoming Global Styles feature can tackle that on a larger scale that provides compatibility across themes.
Ultimately, there needs to be more communication between the Gutenberg team and theme authors who are building themes for the official WordPress theme directory. Perhaps there should even be a new team or sub-team formed focused solely on theming in the block era and working directly with Gutenberg developers to identify pain points. Whatever happens, someone needs to inspire the next generation of themes into being. Until then, most theme authors are stuck wondering what they will need to fix next.
Up next: block/plugin development edition?
It’s an infuriating car crash. The backend interface is still in huge amounts of flux with major drag and drop insertion issues even 18 months after Gutenberg was merged with core. All I’d like is a bit of consistency and for the basics too be fixed first so it’s actually usable. My strategy is to only allow use of the simplest of blocks for layout purposes which is what most of my users want, they don’t need to set line height (most wouldn’t even know what it is) since they’re not designers. I’m in for the block editor but unconvinced of the concept that creating a fully editable site is wise, or even what end users want, the array of options would be so bewildering to a basic user that it’d be impenetrable. What I’m mainly thinking as I watch development is ‘how can I turn that bit off’.
Antony’s comment pretty much sums up how I feel. Like Justin, I am also warming up to the block editor, and can see how it can be used for the better good. But, like Antony said, there are elements being added which I feel will allow users to irresponsibly do things to their site. I honestly don’t envy those involved in the project because I realize just how hard it is to appease everyone involved. As someone who has designed and developed for WordPress since 2006, and was partly responsible for a product that has been used on millions of sites, I get it. You can’t make everyone happy. The question ultimately is, where are the concessions going to be?
¯_(ツ)_/¯
Genesis has been in my toolkit for many years Brian so means a lot that you feel the same way. We build platforms that we need to support and expect to run for many years so this trajectory is of great importance and currently, concern. In another example I’ve recently been taking a closer look at WooCommerce Blocks again and nearly fell off my chair when I discovered that hooks, filters and actions are completely ignored plus there doesn’t appear too be an alternative method to replace or one even planned – the only work around as I understand it is using a deprecated function!!! This renders a huge ecosystem of plugins and methodology of working redundant. For me and the majority of my clients this makes using blocks in the context of a store redundant, hell storefront doesn’t even use them which I think tells you everything you need to know. I feel the team are so focused on this mindset it’s become their only tool and when the only tool you have is a block everything looks like a container block [which you can’t select or find the insertion point for]. I fear there will be no concession until it’s too late, and this feels weird to say, for the first time in over a decade I’m seriously looking at other CMS’s. I see lots of potential good in blocks but at what cost? Let’s just keep Gutenberg where it should be a set of features via something like add_theme_support with plenty of granular control.
Hi Antony 👋,
Disclaimer: I’m not making this comment in an “official” capacity but simply as an individual contributor to the WooCommerce project and filtered through my years of experience in the WordPress community as a freelance developer and some recent experience as an employee of Automattic.
I work on the WooCommerce Blocks team, so your comment caught my eye. You assessment of the current state of Woo Blocks extensibility is pretty spot on, and it’s something we are aware of. However, one exception is that this is something we think about.
What we’re trying to navigate and explore is how we can introduce, or retain, the same flexibility and extensibility developers have been accustomed to in the past while also embracing some of the new direction and paradigms Gutenberg and blocks bring to the world of WordPress. We’re reluctant to just add filters and actions everywhere because we’re not sure yet that will be the best way to make blocks extensible and resilient.
We’re also constantly reminding ourselves of the promise blocks hold for the ability of merchants to more easily customize and edit their stores than ever before. I mean, I’ve worked with WordPress shortcodes and templates for years and year and while I don’t dispute the incredible flexibility they brought to customizing and building sites, the user experience for new users to WordPress has been degrading as other companies have worked on improving this user experience. Gutenberg holds the potential to reverse that degradation for WordPress and in turn the WordPress ecosystem.
hell storefront doesn’t even use them which I think tells you everything you need to know
Storefront is currently in maintenance mode. What that means is we are ensuring all our blocks work well with Storefront, and that Storefront continues to work well with the recent versions of WordPress and WooCommerce, we’re not actively adding new features to Storefront. Themes is another area we’re exploring this year – especially in relation to the direction block theming seems to be going (we’re learning and observing too!).
I think the important thing to keep in mind with all these changes is that nothing is going to be ideal overnight (an impossible task). So it can be frustrating when we’re in the transitory state between the way things were always done in the past to some newer ways of doing things in the future. However, it also presents an incredible opportunity for those who recognize it, to help contribute to and shape what this ideal state may be. Articles like Justin’s are read and discussed. Comments and feedback in the WordPress forums are noticed. Github issues and pull requests (and comments in the respective places) are noted. Experiments by community members exploring what the block editor is capable of are learned from. How people use WordPress (or WooCommerce!) to build things is observed.
The links between all those things and the impact in the codebase and direction isn’t always obvious, but it is there.
Thanks for the candid response Darren, it really is appreciated. However, To be honest you’ve only managed to significantly deepen my concerns on the direction of Gutenberg and by extension WooCommerce.
For context I run a small agency, we specialise in dealing with small to medium, with the a couple of large [one over 100m turnover] businesses. The vast majority of our customers consist of around 5 – 10 people and another significant portion are single person enterprises. In total there are around 150 sites we host, manage and maintain to varying degrees.
What I’m trying to convey is that we run a serious customer focused operation. We use the WordPress platform and premium products from the surrounding ecosystem everyday, in a real world environment for multiple businesses responding to their needs and requests and have been quite the champions for WordPress. That being said, the lack of consistency, clarity and detailed roadmap in the Gutenberg project is not helpful to us as a business or our customers, in fact it’s detrimental and is making us actually question the viability of continuing with WordPress as our go to platform – we are not alone with this viewpoint.
I’m under no illusion with regards to the potential benefits Gutenberg could bring but at the moment it’s no where near to delivering on it yet. We actually use Gutenberg on several live customers sites, in some ways it works well – usually the site we mange need to end – in others is been such a disaster that we had to roll back and restore the original approach. In all cases it’s offered no advantage over a traditional page builder other than a little less bloat. As far as we’re concerned as a business beta software has been dropped into core, essential functions are being removed without replacements even being scoped yet and it feels like we’re in the middle of some grand experiment.
To quickly address a few points directly:
We’re reluctant to just add filters and actions everywhere because we’re not sure yet that will be the best way to make blocks extensible and resilient.
Quite frankly I find this astonishing. So you are seriously telling me Gutenberg is considered suitable for primetime without a standard method as to how blocks can be extended [up to now I thought I’d be missing something].
Storefront is currently in maintenance mode
This is news. We’ve invested some significant time into our own storefront based child theme however if it’s now in maintenance mode there’s a worry it’s going to get dropped/superceeded. Is that the case?
I think the important thing to keep in mind with all these changes is that nothing is going to be ideal overnight (an impossible task).
I agree completely and understand first hand that development takes time, lots of it, and transitions are really, really tough. Performing a significant upgrade or moving a client too a new CMS can be huge ordeal. However this it why we have staging site and in custom dev branches and beta versions.
In our, and lots of other devs opinions it would seem, Gutenberg is beta software and should not be in core. WooCommerce blocks should be marked as beta software without question until it reaches feature parity at a minimum.
On a wider point what seems to be a fundamental misunderstanding by the Gutenberg team is that most businesses don’t want to be ‘empowered’ to customise their stores. Retailers for example just want to sell and market stuff, when people open a brick and mortar store they get shop fitters in to fit out, designers to design stuff, buy a checkout from a checkout supplier and book keepers to do the books – they are the experts. Sure mom and pop places often do lots themselves but as soon as someone gets serious they hire professionals, be that external or internal. The same for online stores and sites. Enthusiastic amateurs build what they can but ultimately they are not professional marketers, designers or developers.
In reality, almost without exception, every company or individual we deal with wants the bare minimum to do with their site beyond posting content, managing orders etc the day to day stuff. They sure as hell don’t want to build it themselves. Our first job for most smaller clients is usually migrating and replacing the disaster of a home made site they tried to build on Wix, Squarespace etc and even WordPress with the usual bloated theme along with 90 plugins they don’t need. The common line we get is “I can never quite get it right”.
They want us to solve all those problems, take the photos, get the stock images, create a colour palette and for it to just work. Then someone to help them when they have an issue so they can just get on with earning a living. You don’t earn a living by trying to understand the nuances of the chameleon that is the Gutenberg interface or why that plugin that’s supposed to work doesn’t work [Unless you’re an agency like us that is].
This move fast break things approach is deeply worrying and I think damaging to the WordPress project and ecosystem as a whole. It’s like you want to create a Webflow or Squarespace competitor and as a company if we wanted to use that, we’d be doing it already! It seems your focus is shifting too far toward individual consumers and you’re losing site of the needs of a large, possibly hidden, segment of your user base. We’re the guys that never install jetpack and don’t connect the store to woocommerce.
My contribution to what the ideal state could be is that we have long term visibility and stability first of all, people are listened too and Gutenberg is a fork or feature plugin that’s eventually merged when it’s truly ready.
you’re losing site of the needs of a large, possibly hidden, segment of your user base. We’re the guys that never install jetpack and don’t connect the store to woocommerce.
This is the crux of the issue. For example, there’s no satisfactory way to replicate a box full of meta fields in Gutenberg, yet. The fact that a popular plugin such as WooCommerce is still using the old classic editor UI is very telling. They are so focused on pleasing the regular Joes and Janes who have a simple blog that they are forgetting the needs of a very big part of the community.
This is news. We’ve invested some significant time into our own storefront based child theme however if it’s now in maintenance mode there’s a worry it’s going to get dropped/superceeded. Is that the case?
To be clear, when I say Storefront is in maintenance mode, it doesn’t mean we aren’t working on it (or that it’s “dead”). We are still giving it attention and have actually increased the frequency of our releases of it (we’re aligning to the same release schedule of WooCommerce core). We also have active attention being given to the child themes and powerpack.
My comment was just intended to indicate that we’re not actively doing new feature development on Storefront because of the shift happening with themes in general in the WordPress ecosystem, and like most other folks involved with themes, we’re experimenting and evaluating how that will impact theming in WooCommerce in the future.
With regards to your other feedback, I really thank you for taking the time to write it. As I mentioned in my earlier comment, we do read this feedback and it is considered.
Hi,
Like Anthony I work in an agency serving clients in many fields (I’m the co-founder and main web person). I second and strongly agree with pretty much everything Anthony said. For us, Gutenberg is still nowhere near ready for primetime and the WooCommerce’s lack of preparedness for it is very concerning. I’m sorry but, at this stage, “we read this feedback and it is considered” or that the sate of blocks extensibility is something “you are aware of and are thinking of” is simply not even close to good enough. It’s astonishing to me as well.
That’s not even mentionning some much more basic stuff like the abysmal state of UX in WooCommerce checkout like submitting an order shows a progress icon in the middle of the page (sometimes 2 screens above the “Place Order” button where no one sees it on mobile. The number of client complaints we’ve had about that… User feedback should be contextual and near the user action, that’s UX 101.
Then Gutenberg itself is even worse. Just one similar example: saving a Gutenberg page/post (by clicking the “Publish”/”Update” button in the top right) results in the success/fail message appearing in the complete opposite corner in the bottom left. It’s such ridiculously bad UX it boggles the mind that Gutenberg has been in core for 18 months… This kind of ridiculous UX is all over Gutenberg. Contextual user feedback, selection and drag and drop visual cues and affordances… that’s also UX 101. This is supposed to replace page builders? Wow.
To now learn that WooCommerce blocks are even less ready than that confirms that we made the right decision to not have subjected our own clients to Gutenberg yet and we’re not adopting it any time soon.
The UX is the worst part of all, lack of features I can handle or work around, the horrendous block navigation and selection I cannot. It just immediately stumps pretty much every single user I’ve unleashed it on. Hell, our professional content team struggle!
Who Automattic complete their testing on, I have no idea, but if it’s not raised a series of red flags then they’re not representative of users.
I’m not sure they even understand UI or put much emphasis on it. While WordPress is usable and has certainly improved, a lot of the UI aspects aren’t that great. My gosh, consider how WP comments work… how long have they been awful? The media library?
They seem a bit like Google… make it function and then maybe someday, someone gets around to making the UI better (even then, not often great, just better).
Yes same here. The few clients we tested Gutenberg on couldn’t even get past the first action on the main screen without help. Navigating blocks was an exercise in extreme frustration for all of them. The same clients got the gist of the Elementor UI in no time flat. Even the old editor makes sense to them as limited as it is. We’d never dream of doing columnar/”block” based content with it anyway so that’s why we use page builders.
Like you, our content people all hate Gutenberg too.
I also have no idea who Automattic have been testing this with but it was certainly not regular users like our clients…
I am surprised that Storefront is being put into maintenance mode. Storefront is the 5th most actively installed theme on WordPress.org.
I agree, and wish there was an easier way to set which blocks you want your theme to be able to use. The current way you do this is more complicated than it needs to be.
Now My target audience is different from some of you as I build custom themes for clients with their requirements and brand, and one of those requirements is that they don’t want to be messing around with unnecessary settings. They want to enter text and or images and have the theme take care of making sure the site matches their brand etc.
Additionally where I think they went wrong (it’s a WP habit IMO) is that they want to force you to use their HTML and CSS classes etc for the blocks. The way Gutenberg is built is problematic, they should have had separate view files for blocks that you could override in your theme. MVC approach would have made Gutenberg much more developer friendly, and allowing developers to override any aspect (M, V or C) of each block would be great. DIYers could still use WP the same way, but developers would have had way more control and flexibility.
My current theme is an Automattic one that I hacked about with; my new theme is the same theme but with some block styles lifted from Automattic themes on the .com site. It is, I admit, a bit of a Frankenstein’s monster in the CSS but it works.
What would have been handy – it may already exist but I couldn’t spot it – is a list of what the differences are between old style and Gutenberg. The CSS for galleries is structured differently now, for example, and images (which meant that the code I lifted from codex.wordpress.org for print styles wasn’t wholly correct). Just a table with two columns would do as a starting point, preferably updated every time the team breaks… I mean, improves things. Older themes could be made compatible with old style and Gutenberg with a bit of help like that.
I like the idea — sort of a transition guide from classic to block for theme authors. That would be a useful part of the official documentation.
I was going to write up my experiences for my own site anyway, but not for another month or so. It would be a start though. There’s scant practical stuff out there for Gutenberg compared to the reams of code snippets and adaptable plugins from people such as yourself and Bill Erickson, so it would be good to share and give back ;-)
“It is also a fair question to ask who is steering the ship” — It is the developers at Automattic and Matt is lead. So maybe that was a rhetorical question? That is not necessarily a bad thing.
Why is this happening the way it is? Because:
-Design by committee is painful and not productive.
-Vocal parts of the community tend to react in a toxic manner.
-Being architected by Automattic employees gives Matt control and ensures an outcome that he is comfortable with. He knows and trusts those people.
-Submitting a design to the community with a request for comment period slows things down.
-The WordPress ecosystem is throwing hundreds of millions of dollars and Automattic is valued at over 3 billion.
-Developers aren’t necessarily good communicators.
Nostalgia and idealism meet reality. That doesn’t mean we should be pessimistic. It is just going to be a lot different. There will still be some kitchen table creators, but most of the innovation will be funded or carried out by developers with some kind of business and support behind them.
The smart move for solo theme authors is to cool your heels until the dust settles. That seems to be what is happening. There are still new viable themes emerging, like the Kadence theme, but those businesses have to be able to commit to an extended period of choppy waters and they will need our support.
@David – Let’s address these, quickly:
-Design by committee is painful and not productive.
=> Perhaps. But if the market isn’t involved how do you develop a solid understanding of what the market needs?
-Vocal parts of the community tend to react in a toxic manner.
=> After adding a couple of Issues to the GB GitHub repo, I’ve all but sworn it off. Why? I’ve seen better “customer service” on Stackoverflow.
-Being architected by Automattic employees gives Matt control and ensures an outcome that he is comfortable with. He knows and trusts those people.
=> Again, that might be true, but that’s not where the bridge of trust is broken.
-Submitting a design to the community with a request for comment period slows things down.
=> As opposed to what? Move fast…and have no buy-in behind you? This isn’t product development and marketing. It’s foolish. Full stop.
-The WordPress ecosystem is throwing hundreds of millions of dollars and Automattic is valued at over 3 billion.
=> I’m not sure what the point is here.
-Developers aren’t necessarily good communicators.
=> This works both ways. See the previous comment about submitting GH Issues.
—
The gist of your comments, while accurate, seems to be: The customers are the problem. That never ends well.
@mfs – I was being descriptive / analytic, not saying that is ideal. The initial development of Gutenberg probably had more feedback than the current stage, but even then the views of the “customers” weren’t taken into account. Still it is coming together. It has been a bumpy road but at this point a lot of people are liking it, myself included, especially for long form content.
The truth is that we don’t have much control or input into the process, or as Justin laments, there is not even much communication. I don’t see that changing. It would be nice if it did. I seem to recall that after Gutenberg was finally merged there was an acknowledgement that communication could have been better. That doesn’t mean that full site editing will be a disaster. Its likely it will eventually end well, but it will be difficult for the little guys to keep up. Consider that Yoast, who was financially well off enough to volunteer full time and was buddies with the core players, was left out of the communication loop and could not get enough traction to feel that he could make a difference … why should we think that there will be better communication with kitchen table developers? Of course, Matt could read Justin’s article and make a change and that would be great. Maybe he will create a developer communications team? Overall, I have a fair amount of confidence in Matt’s motives and aspirations, so I’m optimistic, but it is too bad that it is a rough road for the smaller potential contributors.
I do agree that there needs to be more communication between the development team and authors.
However, full-site editing and block-based themes are a work in progress. Being a builder myself, sometimes it’s not always clear how all the pieces are going to fit together until they fit together. And even then they often require lots fine-tuning.
Ultimately, block-based themes and full-site editing are going to empower MORE creators. Yeah it might be a bumpy ride to get there, but what we’re all creating together didn’t exist before.
I am in full agreement about the future of building themes. It should empower more people to try their hand at custom designs. I truly believe it could be an explosion of creativity and artistry.
In the meantime, we shouldn’t overlook the existing theme-related issues in the here and now. We should learn from today’s mistakes to make tomorrow better.
I am in a minority of one, apparently, that believes that empowering MORE creators is not the creation of a paradise where there will be an “explosion of creativity and artistry.” That’s not how humans work. It is how humans dream — always, and that’s not a bad thing. It’s a lofty mission. Reality is, well, what’s real.
History tells us what will happen, what’s real. Let’s take logo design. Or writing. Or photography. I remember when logo design was a multi-step, carefully executed and costly process to create the stamp that would speak as clearly as a word, that would be as forever as one wanted forever to last, that was zippy in being recognizable, and that had a personality that was the twin of the personality of the company it represented. Logo design involved testing, creating thumbnails, re-do’s, more testing and on.
Now you pick an icon and type a few words into a form and you instantly have a logo for the low, low price of..
Logos have lost their purpose in existing. Humans everywhere were empowered to create them. Yep.
And the same thing has happened to writing copy, creating photos and so on.
Who are the greats in these fields, greats akin to the one’s we once talked about, awarded and revered?
Instead, we have empowered everyone. The result was mediocrity. We’re just adding more of that to the big developing pile.
You’re surely not alone on this. “Everyone is a designer” ®… Gosh. Well, we can be sure of one thing: articles titled “Top 10 Web Design Trends for the Next Year” will get an explosion of new searches on Google after WordPress empowers it’s users with tools like FSE.
Humans are naturally artistic. Much of what we, even the greatest artists of among us, create is mediocre at best. I imagine Stephen King has a few old manuscripts that he cringes at. I’m sure Jimi Hendrix didn’t know how to finger a chord before he picked up his first guitar. Paper, pens, typewriters, instruments — these are all just tools to create art. For every King and every Hendrix, there are 100s or even 1,000s of mediocre artists. It doesn’t mean that we should not empower them to create their art. The next great may be among them and simply need the proper tool to bring their art into being.
WordPress, likewise, is merely a tool. It is a method for people to publish their content. Just because the majority of blogs in the world are not filled with Pulitzer-worthy prose does not mean we scrap the mission of making publishing as widely available as possible. No, we continue on. We continue making a tool, for better or worse, that empowers more people to create things on the web.
The word “design” is not being used above to describe just art or aesthetics. Design can be considered art, for sure, but expression are not the sole concern of this discipline, which is much more oriented to problem solving – by definition.
A powerful tool creates the expectation of instant better results. There lies the problem. For a simple blog, where someone just tries to express him or herself artistically, it’s not an issue, but for a business that needs practical, measurable e reliable results, this is a big deal.
Matias Ventura, one of the architects of Gutenberg, posted his “Thought on Themes” couple weeks ago, where he explored the question: “What does it mean for themes that blocks allow more design tools to be available to users?” It’s an interesting read, and I was a bit surprised, that is didn’t get at least a mention in above article. https://matiasventura.com/post/thoughts-on-themes/
It’s a good read. I wasn’t aware of it until you linked it. I would have certainly incorporated some thoughts from it into the post if I had seen it beforehand.
Thanks for sharing this—you touch on some important issues in WordPress right now. I am already looking forward to seeing your block/plugin development version! :)
Making it easier to communicate about Gutenberg, specifically around Full Site Editing (phase 2), is something I would like to help with. For example, I wonder if the monthly “What’s Next In Gutenberg?” posts might be too high level, and the biweekly “What’s New In Gutenberg?” posts might be too granular. I’m really interested in hearing ideas for better communication, on make.wordpress.org/core or elsewhere. I see how a project manager could be effective here. Do you have other ideas for how the block based theme meetings could be more useful? Are there ideas you’ve heard that seem promising?
If anyone would like to talk more about this directly, I’m @annezazu in WordPress.org Slack!
@Anne McCarthy — Thank you for offering to be part of a solution. Maybe a more long terms approach that builds up two-way engagement. Perhaps a biweekly or monthly theme developers round table held via video where there is a short presentation. It could alternate between theme developers and the Gutenberg team, people could present their work, problems, etc and ask questions and give feedback.
Thanks for sharing your idea, David! Do you see these as being separate from the block based theme meetings and the core editor meetings? What about doing video calls feels like a better medium for these discussions? I definitely think there needs to be more demos shared early and often to help paint a picture of what’s to come and what’s possible now.
Video provides more of a “face to face” interaction. There is less anonymity and more person. People learn differently and text based communication is just one avenue. In the core editor meetings or block based theme meetings is there time for theme developers to say “I’m having trouble with X” and get feedback? There is an us vs them dynamic and the way to dissolve that is for everyone to get to “we”. However that can happen, that should be the goal.
Demos are great.
A weekly post series keeping theme authors updated should begin on the Make Themes blog. So, that’s nice to see. In some ways, this should make for better discussion than the Slack meetings because you don’t have to be in attendance to have your voice heard. I’m hoping this helps with the communication aspect to some degree.
I mainly develop WordPress themes for my clients and I have only developed one that used Gutenberg since it was merged into core. And it was only just to try it out. Otherwise I’ll stick to GeneratePress with page builders like Beaver Builder.
What I found is that Gutenberg works for the most part but it’s clunky and takes too many steps to do simple things. And the worse part of it, all my clients just don’t like it. None of them at all.
Time is money and using Gutenberg is a waste of my time right now. If I’m trying to earn a living and make my clients happy, it just makes way more sense to not use Gutenberg.
If you look at the Two Loops Model (which is the Berkana Institute’s Theory of Change) and use it as way to view the massive change happening here with WordPress, the dominate system is still the old one and the new system is still in flux. So people, especially developers, are going to gravitate to the more stable system, especially if it’s the one they’ve already mastered which gives them the most control.
For myself (as more of a designer coming from building sites on Squarespace but seeing WordPress as the definitive open future of the Web), WordPress won’t really meet my entire needs until full site editing is completed, giving me full layout control of my entire website. Until then, it’s something I’m playing around with every week and keeping an eye on. For example, I’m enjoying simple plug-ins such as Twentig, which boost the customization capabilities of Twenty Twenty.
My ideal vision of WordPress is something which emulates Squarespace but goes far beyond it (which it’s already beginning to do). So once full site editing is achieved, I’d like to see a master theme with basic Google Fonts controls included. After that, I’d like to see a built-in simple to use CSS editor which in turn empowers the end user, giving them the flexibility and control they’ve always wanted with regards to “designing” their site. Once that’s achieved, including the ability to export your customizations off this master theme, you basically have the end user becoming the creator of themes (if they are even called “themes” anymore at that point).
In a sense, I see the future of WordPress as the past of Squarespace, when it had tons of flexibility (i.e. Version 4 & 5). But that flexibility of Squarespace was actually lost and thrown out with Version 6 when the company gave more power and control to developers, killing all of the flexibility and control for designers and the end users in the process.
Webflow? Isn’t that what you are looking for?
Really enjoyed reading this piece. I’ve never fully understood how or where WP became such a hot mess, but it’s important to recognize that people for whom it’s a livelihood have lost a lot of sleep here. Page builders wouldn’t have evolved so quickly if the original WP editor was more user-friendly, yet the new block editor remains stubbornly inferior. Matt has acknowledged that themes – as we think of them now – may not be essential once the block editor is handling the whole site, yet no one can say conclusively what WP will eventually look like, nor when we’ll get there. Everything looks brittle in that light, and it’s unsustainable.
I strongly agree with you @moz.
The point here is: there will be space for some kind of “themes” when the block editor will be a full site editor? And: how can we be prepared as developers?
And again, since all these changes seems to lead WP to some sort of Squarespace or Wix or whatever full site editing platform, why don’t they split into two different projects (one as Squarespace, that can be WP.com and one “for developers” that can be WP.org)?
I might think that more than one dev will switch (back) to Classic Press or some other “old fashioned” platform if the direction of WP (and its consquences) is not clear.
I don’t see themes going anywhere. The theme system will change drastically, but it’ll still be around in some form. That’s scary enough — not knowing what things will look like on the development side of things. The frustration that many authors are feeling is in the here and now. Like you said, folks are losing sleep during this transitional period, especially when things are changing every time you turn around. I expect the future of theme building to be pretty exciting. We just have to survive long enough to get there. :)
Squarespace has a hugely limited theme range compared with WP. If that’s the end goal, theme authors are pretty much toast.
Once we have heard this: “It will be ready, when it’s ready.”
But it was shipped not ready, how many devs screamed: do not release half-backed product! Who cares…
First, I was excited and started to work to update my theme, but when every new version breaks things an requires you to spend hours to look for the solution just to find another set of problems with the new release…
Who has the TIME?!
When I was nolifer and lived at the PC screen, I could afford that, but when you have family, you quickly realize – WP is a black hole of your time. I’ll better spend that time with my kids. WP is not future, our children are the future… WP is “bad for your health” – very good point.
Not listening to community led WP from the democratizing publishing to a health threat. Congrats, great PR achievement!
You make a very good point Tomas, it is the curse of the tech world which I am all too aware of at times. So much time expended on things that where supposed to make life easier. Picasso draws a circle in two seconds, it has been instantiated for ever more (unless some iconoclast destroys it). The computer scientist spends 10 minutes programming a circle but, when they return to look at it the next week, it has turned into an oval.
The post and comments has given me a good insight into the current malaise all this is for theme and plugin developers. I noticed this when I tried working on sites with the Gutenberg plugin active.
Some of the improvements in the latest versions are good to look forwards to when they appear in core later this year but I do notice all the glitches with third party plugins. My observation was that this must be a pain for plugin developers.
The problem with the summary posts is that when those are written, decisions has already been made.
Themers need to participate, test, leave feedback, – and speak louder when they know that new changes will break stuff.
It is not possible to keep up with everything, but those who are able to can pick one open Github issue that they feel strongly about, and get involved.
Most of the time, it’s hard to judge something if there isn’t a half-decent implementation of the vision available –
On May 1st, Josepha Haden posted “An Experimental Outreach Project for Full Site Editing” a call for people to “provide feedback and get it to the developers faster”.
She extended the deadline for submissions to May 22, 2020. “If you are interested in testing early versions of upcoming releases that will make FSE (Full site editing) work better for you, your customers, or anyone who is building or maintaining a WordPress site, please fill out this interest form.
https://make.wordpress.org/core/2020/05/01/an-experimental-outreach-project-for-full-site-editing/
That’s one thought I wish I would have focused more on. This is a two-way street. Part of dealing with our frustrations as theme authors is getting more involved directly in the project.
On that note, it would probably be interesting to see the Themes Team take more charge of pointing theme authors toward tickets that affect themes. Maybe as part of team meetings or regular blog posts. Perhaps have someone from the team take up the role of Gutenberg Abassador and assign them the task of getting the two teams and theme authors more on the same page.
Either way, we need more themers to proactively participate.
There’s been very little thought in regards to Theme developers, from day one, with Gutenberg. From the beginning, they’ve done very little to support themes that aren’t full width (i.e. any theme with a sidebar or two).
As someone who’s been actively using and developing for WP for over 13 years, it’s also very disheartening to see the lack of backwards compatibility. This is even more apparent with the latest 5.4 release where they’ve removed multiple classes & IDs from the Editor styles, causing significant breakages in the editor. When questioned about this in Github issues, they do little to help resolve the issue and refuse to even list all the div/classes/id’s that have been removed or altered.
Building themes and updating existing themes, for Gutenberg, has been nothing but painful. And lets not get started with how difficult they’ve made it for plugin developers to create and update blocks.
Their constant changes in the editor, buggy UI, and countless inconsistencies, is rapidly sucking the joy out of using and developing for WordPress, and it only gets worse and worse with each release.
Been Developing Gutenberg Blocks for past 2 months, and midway into the project, I found it every change you make to the block’s HTML will break the block for all the users becuase Gutenberg saves the HTML in database! I was so baffled… who does that???? Hundreds of developers are complained about this and still do: https://github.com/WordPress/gutenberg/issues/4849
Another big issue is creating dynamic css. There are no gutenberg way to create dynamic styles other than injecting the styles as inline styles which is hinders the load performance of the page as well as make Gutenberg customization very limit as you cannot dynamically style :hover, :nth-child and what not.
There are plenty of other issues that I don’t have the patience to get into..
Disclaimer: previously at Automattic/WordPress.com, currently have users on WordPress.com who are also using my themes. Pioneered Underscores with Ian and Lance. Have developed themes and plugins since version Gold.
None of this is salt. It’s current thinking as I breathe for a while and reflect.
It is also a fair question to ask who is steering the ship.
Everyone knows the answer to this question. I do not think there is a single person in this industry who doesn’t understand that the open-source, pull requests welcome and we mean it ethos, has diminished. There is little to no incentive to make things better unless I’m on someone’s payroll.
Where are the site developers, theme authors, and other designers who spend every day crafting the front end of the web?
In private chats wondering how now to anger anyone while also expressing our opinions about how badly things have gone during the last several years for themes.
The reality is that there are only 132 themes out of 7,455 that list block editor styles as a feature in the official repository.
It will stay that way. What incentive do I have to keep chasing a moving goal post that I have no input on? What incentive do I have to give away my work for free? There is a misalignment of incentives now.
Whether you like the block editor is of little consequence when there is no buy-in from theme authors.
It’s very simple. Old theme authors will either choose to build bespoke solutions or adapt and/or new theme authors will attempt to keep up. Status quo right now is to wait and see when they stop messing with the tools we’re supposed to build with.
ThemeForest sellers are besting free WordPress.org theme authors 18 to 1 in terms of support with over 2,300 themes listed as Gutenberg-optimized.
ThemeForest rewards fierce competition and innovation. It has also made millionaires out of themes purists hate. ThemeForest has won the theme marketplace narrative here. By a mile.
There is some broken trust between theme authors and WordPress at the moment.
Not some. A lot.
My ultimate fear is that the Themes Team will one day flip the switch and require all themes going into the directory to support the block editor like it had to do with the customizer in 2015.
If this happens quality themes will continue to go away to other places. There is no fear anymore – the writing has been on the wall for ages.
The WordPress that promised to not break things with updates.
This. For something that was always supposed to just work, I certainly feel like everything new is a breaking change now.
The Gutenberg project is still in its infancy.
It should have never been shoved down our throats in its infancy. It was a forced change. Years later its issues persist.
Ultimately, there needs to be more communication between the Gutenberg team and theme authors who are building themes for the official WordPress theme directory.
Who will listen and who will take feedback seriously?
This piece could be narrowed down to one line: “Does WordPress care about its plugin and theme authors anymore?”
Many of us from 2003 have spent nearly two decades building something that is morphing into spaghetti code. We have families, children, retirement, and our lives to think about.
I absolutely have passed the point in my life where I’m okay with accepting the opportunity cost of keeping up with changes that happen with or without pushback from theme authors.
Love WordPress. Great piece of software at times, but it’s turned into something I’m not familiar with, and that includes leadership, the development flow, feedback loops, and community engagement.
It used to be that we make WordPress. Now it’s WordPress makes us.
When there is stability with Gutenberg and it’s not constantly releasing breaking changes we’ll see if it’s worth going all-in on.
Until then, what incentives do we have to keep pushing a narrative that this change has been a net good one for theme authors?
Stats don’t lie. Simple theme development used to be a thing. I’d like to see that again.
pins comment
Love WordPress. Great piece of software at times, but it’s turned into something I’m not familiar with, and that includes leadership, the development flow, feedback loops, and community engagement.
It used to be that we make WordPress. Now it’s WordPress makes us.
Preach! 💯 💯 💯
Personally, I use a couple of custom themes I created myself based in Underscores for most of my client work. Trying to keep up with all the constant changes happening with the block editor has been exhausting. So, most of the sites I manage still use the classic editor. I’d like to love the new editor but core devs are not making this easy.
I still remember how many apologists were saying two years ago that most themes in the repository would be Gutenberg-ready in a year and that current page builders would end up being just mere Gutenberg extensions. Adapt or die, arrogantly they said. These people would not make a living as fortune-tellers.
The Gutenberg block editor features are pretty awesome. The integration of block editor is now available outside the block editor. Widgets and navigation screens are examples.
I agree with Carolina. The Gutenberg development in react is still not handy for developers. Developers still using shortcodes instead of making a Gutenberg block. I think developers and end-users still need some time to be familiar with Gutenberg.
And the full site editing is now another most interesting feature. But, It should need much more testing and obviously with backward compatibility.
The Gutenberg project merges into the core. But with backward compatibility. We also don’t forget that the Classic editor has 5+ million active installs and according to WordPress stats there are 25% + users have old WordPress versions which are not yet migrated to Gutenberg.
Developers customize themes with actions, filters, and creating templates. Full site editing also provides block-templates and block-template-parts same as templates and template-parts. Much more testing and theme developers engagement need for full site editing feature.
What I noticed in Gutenberg is that a shortcut user get’s up to speed better while click-users (mousers) are not even finding the drag points. So for none-coders it’s still a bit hard to understand and hence use it properly.
Example the grid-columns, you’ve selected a column -> how do you get to the parent columns block? I had to tell my friend to arrow up until the block desired is selected. Is this intuitive? heck, no!
@justin one think I found in a linked post:
“It is next to impossible to fully use a utility-class framework like Tailwind CSS in a theme without recreating core features.”
Why? Okay right now you cannot really use additional-class field in backend but outside of that it works VERY well, see here: https://github.com/sebot/mist/ it’s missing a bunch but I am short of time due to some urgent health issues I have to sort.
Best,
Seb
Good point with the inline-styles. I was spinning my head arround this for a year now, and have come to the conclusion, that I don’t really care, if styles are applied inline. As a theme-author, I prefer consistency for page looks thus I prefer styles that are globally set inside my theme’s style.css.
However Gutenberg opened up another playground-area. I still haven’t fully understood how many styles and where are injected into a usual site by wordpress core.
It was shipped way to early, but I guess someone wanted a christmas-present at the time.
But on the other hand, I can say, my customers like Gutenberg. And since I’ve started injecting my theme’s styles into Gutenberg, the page-/postpreview also looks pretty close to the real thing.
Wouldn’t it make sense to have by default to separate modes –
1) Editor Mode – for end-users to add content
2) Designer Mode – just to design the layout (even create custom layouts/templates for editors to use
So, current “customiser” – should be only enabled to “designers”
That is an eminently good suggestion that I wish was a concept used a lot more throughout WordPress. The editor, author and other user roles are not fully covered by this concept.
Good post.
A pain point when developing themes for Gutenberg is the inconsistency of CSS. There is no philosophy behind it, e.g kind of a design system. And things change too fast, mostly breaking changes. Of course, they have purpose, but theme authors on org don’t have enough energy and money to keep up with that, just for fixing things to make they work just like before.
Gutenberg is an interesting project but I think the decisions made during its development is not wise. We need better thinkers.
Being a rep for the Themes Team this may sound a bit controversial, but the best advice I could possibly give to someone who wants to start their journey on WP Theming is simple:
Don’t. I’m not joking, just don’t. If you want to make a living out of WP and feed your family, start building plugins. or blocks. or anything else. But not themes.
There is no communication. There is no consideration.
One way or the other we all feel excluded from WP development. Sure, we can contribute on some things but the community is not part of any decision-making process. Unless of course you consider what happens now an accessible way for the community to contribute in a meaningful way: A handful of a8c employees discussing openly on Github across 1000 tickets and 800 PRs disregarding most people that point out problems.
Newsflash: Discussing something publicly doesn’t make the decision-making process open.
All of the decisions that have been made benefit a single entity: WordPress.com. Not the users, not the community, not developers. The company. You can try to justify whatever decision you want as “putting power in the hands of users” but come on…
Not a single person believed someone a couple of years ago when he was preaching in WordCamps “Gutenberg is not a page builder”. At that time perhaps we was right, it was just a content builder, or if you want to get fancy with names, an immersive editing experience. But the signs were always on the wall.
So where are we now?
We’re at a point where WordPress (or rather Automattic) is actively working towards moving WordPress to a direction where it will be capable of competing with Squarespace, Wix and the like. The same things that made people move away from these platforms and come to WordPress, now get added in WP. The same things that the platforms mentioned above in their relative maturity regretted doing and started removing.
The side-effect of that is hurting, alienating and putting aside a multi-billion dollar industry that is WordPress Themes. Hundreds of companies, thousands of developers and the people that depend on them.
The “why” is pretty obvious… .com needs to compete with the companies mentioned above. .org never needed that…
Perhaps the single greatest loss in the WordPress space was the Governance project that never took off.
Perhaps the single greatest loss in the WordPress space was the Governance project that never took off.
Was actively banned from .org. Credit where credit is due.
I wasn’t aware… That’s just sad and disheartening :(
If main player is overpowering whole community, is it possible to use Governance project to create alternative community? I guess it would be painful and would remind the Mambo/Jumla situation, but perhaps it would be worth for the future? Otherwise, as you pointed out – new WP approach will cannibalize whole industry of themes.
Today I went to see what is the situation on ClassicPress end and discovered that they released Classic Commerce fork of WooCommerce – this is huge, because business-focused developers will have solution! If ClassicPress would adopt Governance project and find a sane way to integrate Gutenberg as normal plugin, that could be the game changer :)
I’m not sure about others, but I’m so tired of this constant disrespect for the community, that I need some fresh air, some really good news and I’m rooting now for the change. It looks that the fullness of time has come.
I don’t think that Gutenberg will ever come to ClassicPress! Why would it? The whole point of ClassicPress is to offer a modern business-focused CMS without the block editor, that is why it forked WP 4.9.8
Not developing for themes but it’s pretty much the same on plugins. It’s hard enough to make sure that the plugin is compatible with multiple Gutenberg versions( core and plugin ) but having different DOM structure, classes and elements on each version make it a lot harder. The other one is the “80-20 rule”, there is no clear guidelines regarding this rule.
I’m an early adopter and built a lot or resources for Gutenberg; and don’t get me wrong, I really like it and will continue developing but the need of improvements when it comes to releases are important. Maybe just include Gutenberg on core releases and have developers use the Github version instead of having separate plugin.
Looking forward to the block/plugin development edition :)
This is where I need some clarity. The version of the block editor that is in core seems to be stable and compatible with plugins etc. The points about inline styles I have taken on board and if these are not done to some industry standard, that is concerning.
The Gutenberg plugin is another matter. From what I can see this is the testing ground for what we will get in WordPress in the future and, yes, you will experience breaking changes with plugins that haven’t quite updated to be compatible. Is it just that the Gutenberg plugin is always ahead of the curve?
It reminds me of the transition form Mac OS 9 to OS X twenty years ago. That was messy too if you where deeply embedded in the older OS way of doing things.
Obviously, that aside, there are issues for theme developers in the way Automattic are communicating on this and you would wonder why WooCommerce still has a distinctly classic look.
How much should I really care about themes?
With sidebars, menus and footers getting converted into blocks, it seems the theme is just a container that I can add custom styling to if needed.
If I use a free Gutenberg theme like the Go theme (https://wordpress.org/themes/go/) I don’t see why I’d ever need to switch themes since everything would be blocks and I can modify with custom styles if I ever needed.
What am I missing? Is there a reason I should care about themes?
The old benefit of a theme remains: consistency.
Just imagine you applied all your stiles to a site with hundreds of posts and pages with all different looks and inline-styles. Then your boss comes up to you: “Let’s have a fresher look.” And then your are there clicking through all of it…
But we’ll see, if customizer and Gutenberg really merge.
Pretty much what I was getting at with my comment above which is why I see a standardized theme being the future and custom styles being the new focus, whereby the end user can easily export, share, and import custom styles on their own.
Once you reach that point, having solved content, layout, and styling (and even allowing people to easily share professional looking layouts via block patterns), the only thing really remaining for a developer is custom blocks that add some additional functionality that isn’t there already.
All said and done though, wasn’t that the whole point of why Gutenberg was started in the first place? To empower the end user and finally give them some flexibility and control over their site.
I mean to me this is why developers were so much in demand with the old system in the first place. It’s because the end user really didn’t have that much flexibility and control with the system and the themes. Even small, minor tweaks to a theme could be excruciatingly difficult to change without the CSS, HTML, and/or PHP coding experience to do so.
Yes, Nollind, giving that flexibility and empowerment to users – who want that customization to do themselves – is great – but there are many audiences who don’t want to make that decision or they are paying someone else (a theme developer, an agency) to make those decisions for them – like deciding what colors a table should be and don’t want to think about having that option available
(https://github.com/WordPress/gutenberg/issues/16478)
I’m in that latter situation – I’m a web developer for a local organization and maintain our internal theme.
My co-workers who edit the content on the website don’t need to care about the line-height or the select which 18 different colors on the color palette, they just need to 3-4 of our internal colors and have the line-height already set by default by; so these decisions can be made by me and the graphics/design team. Yes, resuable blocks and block patterns can help make some of these decisions already
However, in Gutenberg, you’re unable to remove those decisions and it’s a longstanding issue – https://github.com/WordPress/gutenberg/issues/20588
Note, this is just one decision – it’s certainly not the most frustrating or impactful issue that I have with Gutenberg but I’m writing this on a Sunday morning, on my free time, why should I spend it sharing even writing more of my criticisms if no one from the Core Team is going to listen and take these into consideration? Why would I make a pull request if it’s going to sit there for weeks if the core members aren’t to even acknowledge it?
I admit that I don’t know enough about JS and react that I can’t confidently say where the decisions that they are being made are the ‘best’ ones but for the broadly project from a technical scope there are clearly several issues (here’s a couple for starters) where there’s issues that could be addressed by core members:
https://github.com/WordPress/gutenberg/issues/4849
– (especially this one)
https://github.com/WordPress/gutenberg/issues/11388
https://github.com/WordPress/gutenberg/issues/7604
At various points in their journey of learning and using Gutenberg, people in the WordPress community will either walk away, find other solutions, or do the absolute bare minimum to fulfill their needs and won’t carve out any leisure time to give back with Gutenberg because it’s not a pleasure or fun challenge for them.
I think we touched basis on this as it does relate to my(our) themes at Rough Pixels…quote from your post Justin:
”Currently, theme authors who are attempting to cover all of their bases are designing for at least a couple of versions of WordPress, multiple versions of Gutenberg, and the classic editor plugin. It is a dizzying array of testing for one theme.”
Frustrating is an understatement, but I feel I have no choice at the moment. Then there is the fact that trying to style block editor content to coincide with the theme is a nightmare because the core CSS for the editor is difficult to override…
…I can’t count how many times I’ve requested a reference of CSS to style every block in the editor so that we know what to put into our theme’s block editor style sheet. But it falls on deaf ears.
I still to this day, wished that WordPress (Matt) created the Gutenberg WP version as a separate CMS.
By the way, nice to see our Prologe Lite theme in the post featured image 😁
I have argued many times in the Gutenberg debate that the block editor should have been developed to a rigorous standard first that catered good layout in terms of containers, sections, rows and columns, flexible in that you could apply css flex or grid to each of these elements while facilitating settings for responsive styles, all preview-able live in the editor. With this an API should have been provided so that theme developers and page builders could override to add more sophistication if needed.
The grid block plugin that Automattic is developing gives a hint of that possibility.
Maybe through the API the more sophisticated css flex and grid would be applied, leaving the standard install with a block theme for novice/new users.
Very good point Stephen. I thing about that for years, especially with Grid Layout. Unfortunately, most of layout block add extra div which are not necessary.
While crystal ball future-telling isn’t a thing, mind sharing if you sense theme devs would find it more satisfying and sustainable to focus on themes and plugins for ClassicPress.net?
There are devs moving to ClassicPress, or at least checking it out as an alternative. Both plugins and themes.
What ClassicPress.net could really do – take the Gutenberg and put it into its right place – make it a good plugin! Thank would be the winner!
The block editor is still not production ready.
Good article. Gutenberg is a dumpster fire and many developers and users are jumping ship, whether to ClassicPress (as I have) or other options.
Many others continue to use the Classic Editor or Disable Gutenberg plugins which simply means the WP project will have more confused and unhappy users to deal with in 2022.
How many CSS and JavaScript frameworks does it take to make a web page?
Gutenberg isn’t about WordPress (dot) org. It is trying to address a problem that didn’t exist within that realm. We have excellent page-builder options. Gutenberg is about Automattic competing with SquareSpace, Wix, etc.
I feel sorry for theme devs and even site designers/developers or site owners who now have to deal with this. I’m glad I exited site designer/developer space, so now only have to worry about this mess as a site(s) owner.
Justin,
This is the best article I have read on this site to date. It is heavily fact driven and I think it expresses what a lot of people have been trying to say. I hope this is the beginning of more open and honest pieces that cut to the heart of the real issues.
Thank you for putting to words so eloquently what needed to be said.
-j
Thanks for the post. All the comments here sum up the frustrations of the community.
Gutenberg is trying to solve to many issues for different type of people: end user, developper, designer, and so on. It can’t. Please go back to original WordPress philosophy and like others theme builders ship it as a plugin. Stop reinventing the wheel a keep core light.
As a front-end developer since a decade, I prefer creating themes from scratch without Gutenberg because it’s not viable for businesses and we don’t need it to achieve our complexe goals.
Thanks for reading.
I spent a month with Gutenberg on a single WP project (Lumina Solar), but right now it’s not my first option when thinking to create a new WP site.
Believe or not, but to bring some multiple-layout blocks to work with Gutenberg is a huge work which requires many test and improvement. I must separate each section to 3-4 small components and load pieces.
It’s not easy to craft blocks. The document is not ready to learn and build your own blocks. I wish to play more with blocks, but my clients will not pay much for something they could hard to manage.
For the next step of Gutenberg, should we improve much more about the way to create a production site for developers? It’s a big blocker at this moment.
I think we should bring a WordPress into 2 options: being the API-data management platform (to let developers craft their visual UI by their way), or becoming a real drag-and-drop website platform.
It is so irritating. 18 months in and I still cannot use Gutenberg in my environments. It crashes page saves with completely random regularity. I have posted the bug (which can be found all over the internet) to be simply dismissed as ‘it’s your environment’. My environment is completely standard. Some installations work, some don’t, some start working and give up on the nth page. And that’s just “does it work?” 18 months in this should have been fixed (it’s a known issue with REST API but it’s the only piece of code that seems to have this issue and the whole development team are in denial.
That’s before I start in on ‘how it works’ when it does work. One paragraph one block? Really? And HTML comments in the code? Really? And the inability to modify embed HTML without being snottily told “That’s invalid” and being dumped with an HTML block and no preview.
At this rate it will be at least another two years before I inflict it on my clients.
Moderator’s Note: Deleted sentence. Let’s keep things family friendly. – JT
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
Email Address
Submit
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

source