I agree that it shouldn't be pushed too hard, but the WordPress team probably doesn't have enough resources to maintain both.
So why break a perfectly functional feature, if they are on a tight line? Just to compete with Notion.io? Stop trying to gob the next market when you don’t have enough resources to maintain your own stack.
Remember when Ubuntu created the Unity desktop and made all Gnome users angry, just to try to gob the mobile/tablet market?
I’ve tried to use it for 2 years and left. Is Ubuntu the OS of any mobile phone today?
Basically WP did not want to cede control over something as essential as the editing experience to a bunch of third parties, but it was happening because of the limitations of the classic editor.
I have issues with some elements of how they approached the problem but doing nothing would have been a worse choice. I can't say that I've seen a simple, blog-like project where using Gutenberg was a big negative. The classic editor will probably always be around, it's just a wrapper around TinyMCE and there's tons of community interest in keeping it alive.
WordPress provides hooks that make it possible to alter the editing experience in the first place. It would be far cheaper to simply alter the API's to stop making this possible. Of course, that would break a ton of plugins and turn away a chunk of the community. So, the big question still remains: why offering a fundamentally different editing experience through Gutenberg and block editing?
While wp.com and wp.org are different organizations, they are tightly intertwined through code, functionality and a shared design vision. WordPress itself has come a long way from it's original value proposition: a tool for bloggers. Today, it's used as a platform for managing media experiences that powers a big part of the marketing and online communication & publishing industry.
There's big money in being able to sell a seamless, integrated, flexible editing experience that allows publishers to quickly design and publish online flyers, set up marketing / advertising / informational campaigns and so on. WordPress isn't the only CMS that moves towards such an integrated media experience. Others, like Drupal / Acquia, are on a single trajectory as well. And then there's plenty of CMS'es like CraftCMS, OctoberCMS, Ghost and so on.
The downside is that the adding a layer of bells and whistles to the UI, as well as the added complexity to the theming API (block themes,...) tend to alienate the original user base. Many of those used WordPress because it sat at that sweet spot of being able to relatively easily deploy, customize and publish on your own personal weblog.
Sure enough, WordPress still offers to create your own blog. But it's not the same tool as it was some 18 years ago. Neither is the Web the same as it was 18 years ago. And so, to many of its original users, wondering whether WordPress is still the right tool to maintain a personal blog in this day and age is a very real question.
So why not just keep it as an option? Is it because 90% of current users would just do that?
Adapting to the block editor hasn't turned out to be the end of the world but it still feels like a solution to a problem that never existed.
They do offer it as an option, that's what the Classic Editor plugin is. It's provided by Automattic and automatically suggested when you open the plugin directory.
I personally really like the new editing experience. And had been wondering why WP was so behind the times for half a decade now.
And for Unity, I was kinda late to the Unity party, but as my first linux desktop, I liked it a lot and used it almost half a year beyond EOL, because I didn't know which to choose instead (it's Plasma now).
I surely don't wanna praise Canonical here, but I would call them out for other things than Unity and their mobile efforts, e.g. Snap!
A big draw of WordPress is that non-developers can customise it with all the plugins that are available, so saying WordPress is secure as long as you avoid plugins nullifies this. It's terrifying that a contact form or caching plugin that you need to install because the functionality isn't built-in could result in a remote code execution exploit.
IMO the problem with the plugin ecosystem is not that they're required, but that so much of the well-known plugins are bloated crap.
Popular SEO plugins don't stop at inserting SEO tags into your <head>. They come with AMP integration, an online robots.txt editor, automatic content generator, competitor site analyzer, spam blocker, and even a rudimentary caching feature to speed up your site! Meanwhile, caching plugins offer to minify your javascript, photo galleries include a Stripe payment gateway, and contact forms come with their own markup language. Everyone is trying to do everything, everyone is stepping on everyone else's toes, and it's impossible for anyone to maintain all the unrelated features that are bundled together in each plugin.
There are really neat plugins that do one thing, do it well, and are easy to audit. Sadly, they are buried under all the spammy alternatives. WordPress really needs to invest in a better plugin search & ranking system that discourages bloat and offers incentives for high-quality code, perhaps by integrating some sort of static analyzer.
When you find yourself fixing bugs in plugins or trying to unlimit their functionality, because in their design someone introduced an unnecessary limitation via the chosen primitives and abstractions, then you are already clearly above the level of skill or knowledge, that Wordpress targets and are able to use more advanced tools to better effect.
Since Wordpress targets that not so experienced developer or simply hobby blogger audience and aims to make it simple for them to create a blog, that is also the group, from which most people arise to become plugin developers. That in turn leads to inexperienced developers using PHP, which has its own set of problems. For example treating HTML as a string by default, allowing for countless injection and XSS vulnerabilities. Or the incessant spam of PHP open and close "tags" in the code, intermingling PHP, HTML, CSS and JS in the same files, switching context so much, that, given a point in the code, you are no longer sure what context you are really in, instead of them using a proper template engine, or starting to not treat HTML as a string in other ways.
The problem is the knowledge and experience gap that is between a person, who can write a secure and useful plugin and a person, who starts writing plugins, because they are a WP user and got some motivation to start with plugin writing. PHP does nothing to reduce that gap.
Another problem in Wordpress itself is, that its recommended or assumed theme architecture encourages concattenation instead of composition. HTML is again treated as a string, that is to be concattenated from smaller parts. Instead what any good templating engine would do is to have blocks of things, which you define elsewhere and keep every part independent. No stuff like head tag open in one document and closing it in another, making the parts not reusable. Most people creating themes do not even think about this stuff. They just go with whatever WP assumes them to do.
> The problem is the knowledge and experience gap that is between a person, who can write a secure and useful plugin and a person, who starts writing plugins, because they are a WP user and got some motivation to start with plugin writing. PHP does nothing to reduce that gap.
That's my feeling. Anybody used to working with secure and well written codebases with CD/CI, tests and just basic Git versioning will want to run away when they see how typical WordPress sites work under the hood.
I would say, if you have a choice in the matter (many do not have that on the job or when a friend asks them to help them with their blog or shop built on top of WP), that at the point, where you start using a proper template engine and switch from the WP-assumed concattenation way of building things to a style of using composition, you are well beyond the point, where you should switch to something more appropriate for the job.
React makes user stylesheets more difficult to write and in my experience often creates tons of overhead in the DOM tree. Often sites do not use SSR, so all they show me is a white screen (because why care about adding any note about the site only working with tons of JS?) and I close the tab. When React sites actually work somewhat, they are usually sluggish and break basic browser functionality like the back button, bookmarkability and others. It takes a lot of care to avoid these issues, when developing with React, so I am not a fan of React or things based on React.
For me personally React is somewhat of a plague of the "modern web". I am sorry to express it this harshly. React and its ilk create a lot of pain for me. Not everything has to be a SPA. Most things actually do not have to be a SPA.
> ... Everyone is trying to do everything, everyone is stepping on everyone else's toes, and it's impossible for anyone to maintain all the unrelated features that are bundled together in each plugin.
If these plugins were in core though, they'd likely have much better security and be less bloated. The problem with the plugin ecosystem you mention I think stems from monetization - there's the incentive to stuff freemium plugins with functionality so you can charge for paid features. I really don't know how WordPress can reign this in.
I think the WordPress core that plugins build upon has bad security fundamentals as well e.g. the default PHP templating language doesn't even escape strings by default, most theme and plugin file permissions aren't locked down to read-only, Git-based versioning and deploys isn't built-in or widely practiced.
> There are really neat plugins that do one thing, do it well, and are easy to audit.
What plugins would you recommend? I find you can get pretty far with Advanced Custom Fields and an SEO plugin.
With WP it seems that the smallest of add-ons cost money. Even for stuff that is open source elsewhere, the authors have re-packaged it into a subscription service.
My other major gripe is the community. With almost any other platform you can find answers to questions pretty easy. With Wordpress over half the articles I found to issues were blatant SEO spam. Paragraph, paragraph, paragraph, tiny nugget of not useful info, BUY MY ADDON TO FIX THIS ISSUE FOR GOOD!
Often times I came across thread where a person would post: "Oh I know how to fix this, but please buy my consulting services to learn the answer".
If you can do that, I would not hesitate to put WP online without a WAF. Almost all attempts on WP sites are scripted attacks on vulnerabilities that have already been patched.
Patches are good. Saying WP must be insecure because of all the patches is like saying a fancy restaurant bathroom must be filthy because it gets cleaned 4 times a day.
With this block madness it turned from a "semantic publishing platform" to some lousy PowerPoint for the web.
It's time for a hard fork, or for some new project/idea to disrupt it. It may take some time, but this is something inevitable at this point.
> With this block madness it turned from a "semantic publishing platform" to some lousy PowerPoint for the web.
But here you're wrong. There is now more semantic information available to content-transforming plugins, not less, thanks to the block editor.
The content is still stored as HTML in post_content (which they do to support exporting the content as HTML), but because of its annotations, you can get the entire block parse tree from a single function call, on the server side:
https://awhitepixel.com/blog/wordpress-gutenberg-access-pars...
So for the first time, the semantics of page content are exposed in a way that does not involve trying to parse chunks of HTML yourself (except the "classic editor" block if you want to parse into that).
> It's time for a hard fork, or for some new project/idea to disrupt it.
There's already been a hard fork of WP that might suit you:
Why on earth should I include these very beautiful and also very random bird illustrations and colors and typography into my website?
Are these "pattern" in the sense of reusable solution to common problems or just random and non-consistent design blocks?
Also, why on earth should I control border-radii, gradient, colors for every single block in the editor?[0][1]
This is complete madness. For two reasons at least: One, styles should be defined at least on a global level, using tokenized values and possibly exposed only to users with higher capabilities (designers).
Two, authors and editors should focus on content, not styling. Many of them are unable to take rational design decisions. Giving them the power of styling border radii or gradients on multiple buttons/elements in a random fashion on the same page, or even on the same website, is a recipe for a visual disaster.
Yes, you're right about how the semantic data may be stored. Everything else? I can still see a "lousy PowerPoint for the web" everywhere.
What's worst, is that they are pushing these bad design decisions really hard. Breaking existing websites in production. Maybe they'll make it right someday, at least I hope so, but it will take years time. This is why, as I said, all of this should be at least opt-in.
They are intended to be the former but I'm sure they will include the latter in some cases; WP is used by really everyone.
(The bird illustrations are just demonstrations of the content pattern, are they not?)
> Also, why on earth should I control border-radii, gradient, colors for every single block in the editor?
Personally I don't, but there may be reasons to do that. And it's important to note that WP now sees its main competition as platforms that do offer that. But one assumes those features can be switched off by theme editors; many aspects of Gutenberg can be (though it's three years since I did a serious Gutenberg site build so I might be out of date. You can certainly disable whole blocks, build pre-defined block styles etc).
> Two, authors and editors should focus on content, not styling. Many of them are unable to take rational design decisions. Giving them the power of styling border radii or gradients on multiple buttons/elements in a random fashion on the same page, or even on the same website, is a recipe for a visual disaster.
Putting aside the fact that you're basically sneering at users for wanting to make their own creative choices, that is only your call to make when you're managing the system, right? How is any of this different to the any number of plugins or TinyMCE Extended features that were available in WP before? At the end of it is still someone's creative discipline; nothing has changed and CMS developers should be a bit cautious about saying "no, you can't ever do that, because it's tasteless".
(Edit to add: one of the real problems WP will face if they took a taste-first approach is a proliferation of hacky, ugly blocks that exist simply to serve users who reject that particular approach. It is far better to have a generic, configurable interface for core block styles that can be locked down on a site-by-site basis than to encourage a world of hacks and workarounds)
It's still becoming more structured, not less. And a fork like ClassicPress won't change things.
If you really think all these things need to be able to be locked down tight: make the case, submit the patches?
I don't know about every other platform, but Squarespace for example is doing really well in bringing design consistency.
> But one assumes those features can be switched off by theme editors;
Maybe you can shut the light off but at the moment it is really hard or even impossible to tune them.
> Putting aside the fact that you're basically sneering at users for wanting to make their own creative choices, that is only your call to make when you're managing the system, right?
No, it's not about control. It's neither about taste. Individual users can do whatever they want. There are more complex situations where some random guy will use the largest font size in bold red for things he think are important and you still have responsibility for that output. In general, Gutenberg also broke the WP user capability system, so there is still work to do to fix it.
> If you really think all these things need to be able to be locked down tight: make the case, submit the patches?
Yes and I assure you I'm not the only one, but it's not something you can fix with a patch. There were really constructive discussions that led to the Global Styles concept for example. But oh boy it takes time. There is work on a theme.json standard that is still an undocumented, change-breaking mess.
And then, on the next update they put some 50kb of useless svgs in your html...
The other thing is that really at this point block editors are everywhere; they are in every email marketing tool, they are in some social media sites, they are in other CMSes.
A block editor isn't optional at this point. Nor is block layout editing.
And pointing at a million people who install a plugin to keep the classic editor functionality is not the same as pointing at a million people who don't want Gutenberg.
It's pointing at a million people who have a variety of reasons not to upgrade older existing content to blocks, but who still need to edit that content (e.g. complex/ill-advised shortcode setups, specific markup etc.)
(The Classic Editor plugin is not either/or -- you can decide to use it per post or per user.)