Is Gutenberg the End or a New Beginning for WordPress?
deliciousbrains.com
deliciousbrains.com
First off, I don't think Automattic has handled communicating it very well. Gutenberg is going to be a big, seismic change in what WordPress is. It seems reasonable to expect lots of themes and plugins will break when it goes live, especially older ones that haven't been as actively maintained.
And yet, if you surveyed the global WordPress userbase, I'd be amazed if you found even 10% of them were aware that such a change is even on the horizon. The communication to developers around Gutenberg has been hit or miss, but at least they've been making an effort on that front. In terms of communicating to the general WP-using public, other than a notice in the dashboard in the most recent version, I'm not aware of there having actually been any. So there are going to be a lot of "WTF" moments when people update to 5.0 and things start breaking or behaving contrary to expectations.
Secondly, I fear that Gutenberg is going to split the WordPress developer community. WP has always been a PHP project; if you wanted to contribute, whether to WP core itself or by writing themes or plugins, PHP was the language you needed to know to do that. Gutenberg, however, is all React-based, which means now there will be two classes of WP developers: people working on things that don't touch Gutenberg, who will be writing PHP, and people working on things that do, who will be writing JavaScript/React.
(My suspicion, even though Automattic has denied it strenuously, is that the master plan is to slowly phase out PHP and turn WordPress into a React-only project. So after Gutenberg, we will see more and more components of WP getting rewritten in React, until one day there just won't be any PHP left anymore.)
Thing is, I don't know a lot of PHP developers who are also React whizzes, or vice versa. So I fear that Automattic is taking one of the core reasons for WordPress' success, its absolutely huge developer community, and throwing it overboard. If the plan really is for WP to become a React project, a whole lot of PHP developers are going to need to become React developers in relatively short order. Some will be able to make that transition, but I worry that many will not. Maybe it will pick up enough new React fans to make up for them, I dunno. But that seems like an optimistic read to me.
The more I learn about Gutenberg, the more I wish Automattic had just started a second, React-based project and used that as a clean sheet of paper, rather than taking all these ideas and trying to jam them into WordPress to make some sort of software turducken.
They are trying to push forward with what they think is a good idea, and best for the products future. Doesn't mean they're right, however there is the argument that the customer doesn't know their experience could be improved.
Time will tell in the WordPress case.
It can be good to recognize that back-compat has become detrimental. When that happens, you need to communicate the reasons why you have decided to break it and communicate that the projects values have changed going forward. It doesn't sound like either of those things have happened here.
I say this as someone who loves WordPress and has been developing on it since 2006. I’ve also been working in UX and UI for ten years. I’m hoping for the best, but bracing for the worst.
Gutenberg from my experience is a server hog compared to the classical Wordpress. It's harder on database servers and on memory. Yet they won't even change their PHP practices to make it 7+ requirement.
AFAIK there is no change to database or memory usage post-Gutenberg, especially since pretty much all of the new code executes on the client side when you edit a post. It may use more memory in your browser, but not anything that should cause issues.
That being the case, I can see a well-prepared, well-publicized and well-maintained fork easily taking the cake from WP.org in the near future, as WP.com becomes more like the SquareSpace they admire so much.
What's going to happen with the entire plugin ecosystem? Say I'm a plugin developer - am I going to jump ship to an untested fork with no company backing it, or am I going to go with a safe bet?
I'm happy to see a fork of Wordpress if that's the itch that people want to scratch (more power to them!) but the value of the app isn't in the code itself, is it?
This model has proven successful before in other projects faced with similar issues
Purely anecdotal, but from a hiring stand point, it's extremely difficult to find good software engineers that are willing to work on or maintain a Wordpress-based project even as part of their duties. No one seems to want to touch it. I have yet to come across any engineer that would classify Wordpress as a resounding success in their eyes.
However as you see in some other comments on this thread, backwards compatibility has been key to WP's adoption which can make it challenging to fully iterate the user and developer experience. With Gutenberg we're doing this, and it has generated a huge amount of pushback and even conspiracy theories. Hopefully in a year or two we'll look back at this as something we're not sure why there was even an issue.
The last time people threatened or actually forked WordPress like this was when we first adopted WYSIWYG in version 2.0, in 2005. Part of why WordPress today has 10x the market share of the runner-up is because we think a lot about these decisions, listen to tons of feedback, but are willing to occasionally choose controversial-at-the-time decisions that turn out right in the grand arc of things.
"Automattic Automattic Automattic Automattic Automattic" Throughout your comment you attribute a lot to Automattic that is really core, or contributors, or me. There are hundreds of contributors to WordPress (and Gutenberg) that don't have any association with Automattic, and it's not fair to them to attribute anything good or bad about WordPress to a single company.
"I don't think [...] has handled communicating it very well" That's totally fair, and I believe we can always do a better job communicating. We've done a lot, such as with wordpress.org/gutenberg, the messaging in 4.9.8, at pretty much every WordCamp this year, and my big annual addresses the past two years, but we're not reaching everyone. Web hosts and agencies are helping a ton here to educate their customers and clients, and it's very much appreciated.
"It seems reasonable to expect lots of themes and plugins will break when it goes live, especially older ones that haven't been as actively maintained." This is why we have done a wide public release of the beta plugin and it's active on over 600,000 sites now — this is the most widely tested feature ever to come into core. People are running it with every possible combination of other plugins, themes, and hosting environments, and we've been learning a ton and fixing as much as possible beforehand. I don't claim any software is perfect, but this code has had more testers than we ever get for a beta version of WordPress, which is usually just a few thousand.
"My suspicion, even though [...] has denied it strenuously, is that the master plan is to slowly phase out PHP and turn WordPress into a React-only project." There are no secrets, on stage in 2015 I asked all WordPress developers to "Learn Javascript Deeply" because Javascript interfaces talking to REST APIs was the future of the platform. This is how the Customizer has worked for years, but you're correct that Gutenberg is the first major, full feature to be built on our own REST API and does use React. (In fact we were part of getting Facebook to remove the patent clause from React, which paved its adoption in the WP community and with many others.) So you're correct it's part of the master plan, but not that it has been denied at all. There will always be some PHP for the server side of things, but Javascript is the way forward for the interface and wp-admin.
"If the plan really is for WP to become a React project, a whole lot of PHP developers are going to need to become React developers in relatively short order. Some will be able to make that transition, but I worry that many will not." I'm concerned about this too, which is why I've been advocating for PHP-only developers to learn Javascript for 3 years now.
"The more I learn about Gutenberg, the more I wish [...] had just started a second, React-based project and used that as a clean sheet of paper, rather than taking all these ideas and trying to jam them into WordPress to make some sort of software turducken." First, I love turducken. :) But also, the WYSIWYG was in Javascript before, so it's not like editor-modifying requires a new language you didn't know before. The PHP metabox API still works just like before, and we and others are creating tools that allow PHP developers to interact with Gutenberg. But I'll repeat again that if someone wants to be a relevant web developer in a decade I don't think you can be PHP-only, and you should begin learning and mastering Javascript as soon as possible.
I've worked with Wordpress a lot over the years, so I'm very familiar with its inner workings: this is what's largely motivated me to avoid it when possible, and unfortunately prevented me from contributing to the project.
Given my initial reaction to Gutenberg, I'm imagining the community at large will hate it. The Wordpress community is one that champions amateur, dangerous, big-ball-of-mud software development, under the guise of being "beginner friendly" (where "beginner" = "not experienced enough to be leading clients to believe they can provide professional-grade solutions"). This is a mindset that favours hacks and tech debt. over refactoring, and Gutenberg is definitely going to force both plugin and theme developers to rethink, and rewrite their approach (in a positive way, imo).
If it successfully brings Wordpress out of the dark-ages, that's great obviously. If it makes Drupal more pleasant and easy-to-use for editors: also nice. If it kills Wordpress due to its community migrating away, then at least it could leave room for some more modern competitor.
I just hope the core devs don't do a U-turn on Gutenberg.
The creator likes to namedrop ClassicPress everywhere on the WP.org forums and WPTavern. He's had his posts removed from the wp.org forums due to spam too.
https://camo.githubusercontent.com/5c2b13dae2a33eafd5eab9039...
https://github.com/ClassicPress/ClassicPress/graphs/contribu...
I think it's confusing to screenshot the faces of all the WP developers, put it on your project homepage, and say "This project exists thanks to all the people who contribute." WordPress itself started as a fork so I fully support the importance of forking, but there's a way to acknowledge WP contributors without making it look like we're endorsing your project. Thank you!
Even within the core-contributor community, there is a lot of friction, particularly with the "less popular" components. Accessibility was the first to snap, with the lead resigning, but not after other big contributors took long breaks when needed most. BDFL Matt hasn't helped heal the fractures and has hurt even more components since. The Privacy component, for example, was the butt of a joke during his WordCamp Europe keynote, boiling down our efforts over the past year as asking users to take cookies, which hurt Privacy team morale (the Privacy team primarily worked on creating a standardized way in the core to identify and export personal data, and help people create Privacy Policies by standardizing how plugins can identify what data they collect).
The largest issue is React -- it's so different than the rest of the WordPress core, that 90% of the core developers can't work on Gutenberg issues. WordPress is primarily PHP, and if JS is used, most places jQuery is the framework of choice. It's dated, but it works quite well still. React is quite the departure from all of those technologies, and will cause gigantic rifts in the community. I do believe WordPress will survive, but with thousands of plugins lost forever due to lack of updating.
Nowdays there are some really good solutions like quillJS or prosemirror that are not tied to particular solutions.
As with all libraries, you still have to be good at organizing your code for it to help you in the long-run. That's a lot of the appeal (and problem) of full frameworks: it decides how to organize your code for you.
Should they change the entire stack to use React, they would lose a lot of their community. A lot of their users are code novices that make do with simple HTML and some PHP snippets.
I have not yet done this, but as I understand it... it's possible to use whatever JS you want as long as it works with the GB api.
Basically, I did the hello world react Gutenberg thing, then took a look at a11y and saw that none of the 8K or so institutional user I support could probably legally use it, and then got back to whatever Vue map searching for CPTs or whatever BS I was building based on ACF and plain old CPTs.
So I dunno for sure, but as I understand it you can build your Gutenberg components in any JS-based system without a lot of overhead. But of course, probably best to just use React as that is what all the core components will be written with.
Why does someone select Wordpress in 2018? Why even host a website at all? Because they want to build something custom. But because Wordpress core continues to be basically a simple blog engine, anything fancy has to get implemented as custom code and/or super powerful themes and plugins that are almost like mini CMSs unto themselves. This is where a lot of the security problems in Wordpress sites often come from, BTW.
IMO Wordpress could do a lot more for itself long term by improving the flexibility and power of its core, rather than its WYSIWYG.
From what I understand, it's better WYSIWYG. Great, but we have entire essays demonstrating how WYSIWYG is garbage. Alright but people want WYSIWYG!
To me, this seems like a manifestation of the limits inherent to the simplification of UI. The frontend needs complex information to be able to correctly produce a beautiful design. Ultimately, the user needs to be aware of the concepts (too complex, apparently), or the design needs to be automated and therefore simplistic. WYSIWYG is the unhappy compromise demonstrating that consistency begets complexity.
If this dilemma really is unsolvable, then Wordpress is but one of iteration in a grand cycle of its victims. I worked mainly with Drupal, and the situation there isn't much better, they've simply opted for sophistication over usability.
I would dispute all of those essays.
Explain to me what we do instead of WYSIWIG and if your answer is anything like Markdown then you've never observed real users.
Hell - I hate markdown and I'm a developer. I do not understand the desire to trash WYSIWIG other than reverse Ludditism.
You can find an essay demonstrating everything you care for is bad.
Engineering requires measurement and proof, not essays.
Markdown is great and all, I personally use it mostly for README docs and git tracking. But WYSIWYG is what most blog sites are embracing
Examples (but not limited to)
- Medium
- Ghost → Ghost 2.0
- Webflow + Design tools
- Notion + Notetaking tools
- Premade website tools (WIX, squarespace, Shopify Page Builder, etc) are gaining ground over wordpress traditionally
WYSIWYG has a learning curve associated with it, but it doesn't have to be complicated. Personally, I prefer GUI tools over non GUI counterparts anyhow. These include tools in atom/visual studio code for doing git commits / branching etc.
People are more than willing to learn how to use a WYSIWYG interface if the value they get long term is worth it. Ideally, cost should be minimized (learning) and benefits maximized(building quick blog posts how they want). Blogs are exactly that though, you spend a little bit of time learning the framework, and spend a lot of time using it. The amount a user is willing to learn proportional depends how much they will use it long term.
For a one off task, a user is not willing to spend as much time learning a WYSIWYG GUI tool, and would rather pick something more familiar like markdown or .txt. Examples include learning how to use a new video editing tool, with advanced feature sets (Adobe Premiere, etc) if you don't make videos often. Rather you would prefer learning a simpler tool instead (Adobe spark, etc)
From research I've done the market is largely shifting towards WYISWYG and from a UX research standpoint, this makes sense. Getting exactly what you want lowers the barrier and confusion / expectations of what you receive.
You can quote buzzfeed essays all day, but I always take research with a grain of salt unless (1) the author is reputable (2) it validates research and data I've observed from a number of various reputable sources / my own research. UX is just common sense at the end of the day
------------------------------------------------------------------
> The frontend needs complex information to be able to correctly produce a beautiful design
Not necessarily true, just use a CSS framework and it simplifies a lot of the process. Take your pick with functional CSS like tailwinds, bootstrap, or just modify your own classes. WYISYWG just wraps things in classes as necessary
I've looked at Gutenburg, it looks promising. I've spoken to a number of core devs from gutenburg. I don't really like the tinyMCE editor that much honestly, or the Jetpack installed wordpress.com instance. They both have issues. TinyMCE editor doesn't reflect proper nominal width for a blog at ~800px, so sometimes the results are skewed when previewed live
Jetpack wordpress.com's editor is more closer to what optimal words per line / font-size / width to write should be. However, it has some serious flaws when using 3rd party plugins (such as adding prismJS code snippets) and its a pain to work with
Oh boy would you be surprised. The whole reason we do research is because users consistently break our expectations, in the most uncommon ways.
This is good for bloggers and wordpress.com but adds nothing for anyone that used WordPress as a base platform for something different.
It's the something different that differentiates it from SquareSpace.
https://www.manton.org/2018/10/23/wordpresss-gutenberg-vs.ht...
There are as many sites still on Magento 1 as 2 which they would want to avoid.
And I suspect this is the case with quite a few recent WordPress changes to be honest. The people behind it don't want to be seen as the folks making the 'beginner' or 'amateur' CMS, they want to be up with the 'cool' kids working for Google/Facebook/Netflix/Airbnb/whatever with React and Vue and Angular and what not. For them, stuff like Gutenberg (and arguably even the REST API) feel like attempts to move WordPress away from the 'CRUD sites for small businesses and non programmers' market to the 'professional' one.
Yet that's exactly where the market is for WordPress, and that ease of use that attracted beginners and lower end agencies is why WordPress got so popular in the first place. You didn't need a lot of experience with frameworks and build processes and MVC structures and what not to get started, you could just copy or hack together some simple code to get things the way you wanted, and use third party themes/plugins to do the rest.
Trying to make things more complicated or move the core of the system over to a JavaScript framework basis (as some suspect Automattic may be trying to do) will just kill a large part of the WordPress community, and remove the ease of use aspect that makes it so popular at all.
That's not a problem, Wordpress is literally a blogging platform.
> This is good for bloggers and wordpress.com but adds nothing for anyone that used WordPress as a base platform for something different.
If your application's scope is outside of a blog, Wordpress is the wrong tool for the job. There exists multitudes of frameworks written in any given language that follow the MVC design pattern (some better than others of course) to choose from.
1. Static is secure. Wordpress is a notorious target for hackers and I see constant attacks even against my empty, worthless Wordpress site. But you can't attack a site that doesn't take any input or perform any logic besides choosing which page to display.
2. Markdown is simple and does the job. I don't need anything fancy to write my thoughts and link to resources I find useful.
3. I find Jekyll to be more flexible than Wordpress. Technically both can be used to make any kind of static site, but I find the customization friction to be lower with Jekyll.
4. I like the built-in version control I get with git/Github.
5. I like editing my site with an IDE where all files from content to style are intuitively accessible rather than navigating Wordpress' interface.
6. Github pages includes HTTPS and DDOS protection that I don't need to think about (or even know about). It's just built in.
7. It's in keeping with the open source spirit to have my personal site open source. Anyone can go in and look at what I'm doing, how I'm doing it, and even the history of how the site evolves. They could even fork it if they really wanted to for some reason.
Not the same market.
- Have a user friendly administration section that anyone can use regardless of technical expertise (by user friendly, I mean have WYSIWYG editor for all posts and make it extremely simple to manage content via a UI -- not CLI)
- Have roles for users with restrictable access
- Have a plugin ecosystem that allow just about any customization to be easy enough to implement that paying a freelancer to do so is quite affordable
- Have an entire theming eco-system that is very alive, with plenty of free or paid options to make a site look professional
I doubt we will ever see backend changes, like allowing postgresql database though.
Plugins: https://github.com/planetjekyll/awesome-jekyll-plugins
Themes: http://jekyllthemes.org/
But I do see your point.
2. I personally prefer using WYISYWG, especially when I add images and code snippets. Having to view a markdown renderer means I have to look at two things, unless your using a partial markdown renderer instead on input side (stackedit.io, inkdrop are some examples).
3. Installing plugins in wordpress is easy. The way I do most things is fork entire repos, test it out, and see if its worth learning. This is how I approach wordpress as well, try X plugins disable them all see which works best. With jekyll you have to do install plugins / libraries yourself, I just want to get straight to writing though
4. Wordpress is just bandaid solutions everywhere for me, I only git track changes I make from a base theme (its all just CSS)
5. Wordpress's interface is awful to look at when using the editor in admin panel. But you get used to it. I'm debating in writing a quick javascript extension / userscript that I can toggle to disable all the clutter while writing
6. Had issues with wordpress HTTPS issues that sitegrounds had to fix the otherday, I still have no idea why I didn't have my SSL certificate installed
7. As much as I like opensource, I do a lot of things closedsource.
Wordpress is great for me b/c I can customize it very quickly, do bandaid solution plugins and backups everywhere, and just focus on writing. I don't like reinventing the wheel or building my own tooling if I can avoid it.
Jekyll has always given me build errors in a windows OS environment since its based on ruby. What I had previously is using github-pages and deploying it live to see changes. Still learning netlify. Commits were extraordinarily messy for me actually, I would have 1000+ commits and 990 of them were just minor changes to draft posts. I could probably use seperate branches but out of the box, everything went to master branch
It separates the CMS from the front-end and has a very good API to get the data from the CMS.
Grav is cool, if you need PHP you’re good with flat file.
Off topic, but my most fav CMS of all time is definitely Umbraco. It’s built on .NET, but it’s insanely fun to work on.
Between all three if these CMSes, I cringe when I hear “Wordpress.”
This is clearly not the problem that Gutenberg aimed to solve.
The problem it solves is more what your second paragraph mentions: “how do I insert custom content that isn't just text in a way that looks consistent on the front and back end”?
Adding complex content in a visual way is a real problem in pre-Gutenberg WordPress, to the extent that a thriving cottage industry of page builders now exists, each with their own take on how to add and edit content.
Gutenberg hopes to remove the need for such page builders in many cases, (and eventually) unify the WordPress (and Drupal) community so they can offer custom content types as native blocks under a common API.
For relational content, there are still custom post types and taxonomies.
> IMO Wordpress could do a lot more for itself long term by improving the flexibility and power of its core, rather than its WYSIWYG.
It's doing that too, with the REST API, with WP-CLI becoming a “blessed” project, and with future plans for Gutenberg as a means to control widgets and other site areas, rather than just post content.
> Adding complex content in a visual way is a real problem in pre-Gutenberg WordPress
It's not an actual problem though, is it? That cottage industry already fulfills the needs of those the subset of users that need more than what the tinymce implementation WordPress offers out of the box.
It's better to understand Gutenberg not as a problem solving project but as a reaction to two things that the project leader has trained his focus on.
First, there's this premise that everything is moving to javascript and php is legacy, so WordPress should evolve to run on javascript while casting aside PHP somehow. Fail that and the project could go under is an anxiety that exists.
Second, there's the itch for WordPress.com to compete on more level terms with the state of hosted solutions like WIX, Weebly, Squarespace who offer increasingly simple visual building experiences. This is where wp.com wants to compete and win new users choosing between other hosted providers. Mullenweg wants to have WP be an even bigger monopoly. These are two anxieties driving Gutenberg.
Gutenberg channels energy toward accomplishing a conversion from a PHP-centric project to a Javascript one, while making a play for new users who are choosing between the hosted version of WP and other hosted solutions.
On a technical level, Gutenberg doesn't really convincingly solve technical problems. It makes it easier for developers to tack on GUI driven content elements, which was possible before, but something that many developers didn't get right or didn't know how to do.
It doesn't provide a better WYSIWYG experience. The editor screen and the front-end are going to look and feel very different. The biggest new obstacle to arriving at a better WYSIWYG is the fact that in Gutenberg the interface markup is a first class citizen, with the content merely existing deeply nested inside its components in editing mode.
While editing, every paragraph, every image, every element is surrounded by endless amounts of divs and scaffolding. When designing a document's CSS you style according to the markup that is shown to users, now with Gutenberg you have to take into account the fact that while editing elements are nested deep inside a convoluted set of divs. So we're still storing messy blobs, but now we're going to split up those blobs and add more mess while in editing mode.
Sure it is.
If the first thing thousands of users do after installing WordPress is to pay for a page builder plugin to be able to work with their content in the way they want, that's a problem — it's a sign that the existing editor does not meet their expectations for how a modern CMS/blog platform should let them work, which makes it a good candidate to be solved in the platform itself.
And if completely new users struggle to format content without frustration (I have watched many people trip with the “Classic” editor in new user orientations on simple things like adding and positioning an image or video), that is also a problem, because it affects their first impressions and gets in the way of whatever their personal or business goals are.
Gutenberg is aimed at solving both of those real problems; I think on the whole it does it well, and it's enlightening to see how positively some people react to it:
https://twitter.com/antpb/status/1052996833264455680
> The editor screen and the front-end are going to look and feel very different.
You can style the editor with CSS, and re-use much of your front-end theme styles in the editor stylesheet via Sass. This is how the upcoming new default WordPress theme (Twenty Nineteen) already works: https://github.com/WordPress/twentynineteen
> So we're still storing messy blobs, but now we're going to split up those blobs and add more mess while in editing mode.
The “mess” in editing mode is needed to help people style their content more intuitively; you can't have a WYSYIWYG web UI without adapting the page content with scaffolding to enable styling controls.
There are some big and entirely valid criticisms around Gutenberg (accessibility support, general PR issues, release delays), but “not being designed to address a real user problem” isn't one of them.
It will take a lot of time to address all issues and turn the community around to it, and this is just the start.
Understanding the priorities in play explains in part why Gutenberg is causing friction better than saying it exists because it is trying to solve technical problems for users. That would lead you to think that the technical problems were thought about really hard and that is some primary goal. It's not. It's just WordPress trying to modernise an interface.
> You can style the editor with CSS, and re-use much of your front-end theme styles in the editor stylesheet via Sass.
The reason I bring up the editor and WYSIWYG is that it shows the disconnect between some lauded goal of providing a more seamless experience and the thought that went into the technical solution. My feeling is that we ended up where we are not because we were trying to solve a problem in the best way, but because we were just trying to cram in a new JS way of doing things. It explains better how we arrive at the following mess. Let me show you it through the lens of styling a post:
> The “mess” in editing mode is needed to help people style their content more intuitively; you can't have a WYSYIWYG web UI without adapting the page content with scaffolding to enable styling controls.
Look at the gallery I posted and tell me honestly, are you really saying this is the only way to provide 'intuitive editing'? Of course that is not true, it's simply how Gutenberg decided to implement it. Of course, you can compose your CSS workflow to fit around how Gutenberg's editor functions and you'll get fairly good results if you do. But this is a workaround, it's made the UI a first class citizen at the expense of the rest. So theme developers have to think in terms of the UI, not just what the markup looks like on the front-end. And content creators are forced to think in terms of blocks. It's an UI that is altering how people interact with it, for its own sake.
What's the difference between "compete on more level terms with the state of hosted solutions like WIX, Weebly, Squarespace who offer increasingly simple visual building experiences" and "solve problems for users". If there is something that is making people choose WIX/Weebly/Squarespace, isn't that something precisely: a problem that those things solve and default wordpress (currently) doesn't?
So free users don't want the features that paying users want? Whyever not? Surely the fact that some people are willing to pay for a particular feature indicates just how important that feature is to a lot of users.
I've long emphasised the symbiotic relationship .org has with Automattic in positive terms. Up until fairly recently I would say this relationship was almost wholly to the benefit of the overall project. My impression is that WP.com under your leadership is now behaving more like other conventional tech companies - it's preoccupied with growth. That preoccupation with growth by implication operates in the context of wp.com competing with other commercial companies who compete for the same customers.
When I look at the success of WordPress through the years, I'm seeing growth arriving as a side effect, not as a specific end unto itself. Decisions were made because wrong or right, they seemed like a better, more powerful way to do things. When it becomes about growth, other things become a little less important. Through the lens of the need for growth, options are judged to the degree to which they are vehicles for further growth. Unfortunately this also leads to relaxing other principles that should be central to WordPress.
Before React changed its license, it had already heavily adopted for Gutenberg and Calypso and you had been poised to bless it had there not been so much turbulence. It was adopted because it had been the fastest way to move forward. The same militant zeal that was applied to 3rd party developers using non-GPL licenses was not applied to the adoption of React, because React was a useful tool in the pursuit of growth. Of course, you can say, but it's now a success story because I've no doubt that FB's change of license was influenced by WP. Community consensus was however a second order issue, as was the original licensing, what matters was what would make the people working for you happiest and most productive in the short term. (Credit to you, you were willing to abandon React at one point, that must be noted)
WordPress will soon be adopting AMP in core, given your support. Again, immediate growth will be the primary reason this happens, because AMP is the fastest way to cut down on bloat that is holding back performance for mobile users and users on slow connections. It's a shortcut, it's a shiny looking vehicle to continued growth, delivered on a plate by some of the worlds best engineers. This decision won't be made based on community consensus or a discerning look at whether it's good for the open web, or what other options there are. It will be stressed that AMP is developing web standards and is an open source initiative with many other players that have bought in, saving the web and helping poor users.
Because growth is the imperative, things that hinder growth are treated with the same baseline hostility as red tape is to businesses. Accessibility and privacy are inconvenient obstacles that ultimately need to take a backseat to building forward momentum, rather then the very means with which to democratise publishing and development.
Because growth is front and center, artificial time pressure needs to be created with which to force the issues. And like a conventional tech company that has grown into a monopoly, it starts to take advantage of its privileged position. It becomes aware of its own latitude, like now the ability to introduce a degree of breakage and concentrate all core development on the delivery of a flagship feature.
I'm seeing this and I'm thinking, many of the decisions that are being made are at best following the letter of stated principles, but not the spirit. Each decision can be somewhat rationalised and the pretense can be offered that it's in the interest of increasing the pie for everyone, or to reaching more users, general survival and for spreading OSS practices even further.
What I'm seeing is a web of monopolies that are interacting in such a way that their influence continues to grow. To have the web shaped by a few select players is not good at all, and I certainly haven't worked with WordPress all these years because I care about market share. I was motivated by the degree to which WordPress empowers people, how it brings people together and champions freedoms as well as its role in keeping the web open and independent. Now it's a slave to growth, nakedly pursuing monopoly status, boosting the role of problematic monopolies elsewhere while selectively applying its stated principles.
I have enormous, genuine respect for people working on WordPress, including you and the many people that work at Automattic and elsewhere. I believe strongly that every single person involved is working with the best intentions in mind. But the prioritisation of growth has corrupted the character of the project, and I can't express in words just how sad that makes me.
Thank you for recognizing we were willing to walk away from React because of the license. It was chosen because of technical merit originally, but was a day or two away from delaying the entire project 6+ months to refactor.
AMP is interesting but no decision has been made there yet.
Thank you for sharing your thoughts and a generally excellent comment.
To me they reveal a couple of misconceptions:
1. That a WYSIWYG should provide a pixel perfect like-for-like view of the front end on the back end.
As you mention, the theme you chose doesn't have full Gutenberg styling, so front and back end differences are more pronounced. But even themes that have good integration will display differences, because the back-end cannot perfectly model the front if users are going to do more than manipulate data inside it (i.e. change styling).
I do agree that there are other ways to provide more intuitive editing (like in-place editing), but they are not without downsides too. In-browser editing is a compromise and balancing act.
2. That the structural blocks around visual elements on the back end designed to enable UI elements and controls interfere with styling by theme developers in some way.
That was definitely my experience at first (I've just spent three months updating several themes for use with Gutenberg), but it isn't now that Gutenberg has evolved and I better understand how editor styling works. In short:
- You enqueue your editor styles after calling add_theme_support( 'editor-styles' ); with add_editor_style( 'style-editor.css' );
- You can then copy the bulk of your styles from the front end to that stylesheet (with a few exceptions, such as the post title, which do need editor-specific wraps at present).
- Gutenberg/WP 5.0 prepends those styles with a block-specific selector when you view the Gutenberg editor so that you don't need to worry about the “soup of UI markup”, as you put it.
- You can automate much of the CSS re-use using Sass, like the Twenty Nineteen theme is doing.
Theme developers need not think about the extra wraps unless they are developing custom blocks, and even then it's largely abstracted away for them by the JS API.
I would much rather have editor styling handled automatically by Gutenberg, and I think it will get there, but for the moment this is a small stepping stone on that path.
You bring up how Gutenberg solves some of the issues it creates, i.e. how theme developers supply editor styles to match what is seen in the front-end. Until recently Gutenberg didn't even prepend block specific selectors, it was even more broken than now. Why did it even start out that way? How is that even possible to have Gutenberg develop that far without properly thinking about how to style for it? Why is it this solution patched on? (same can be said for meta fields, accessibility and so forth). Because the project didn't start with a clear idea of the technical problems it wasn't going to have to solve, it wasn't a priority.
So, for theme developers Gutenberg is more labour intensive (though it can be rewarding). It wouldn't need to be more labour intensive had it started with the full breadth of priorities in mind at the very start. You say 'you don't need to worry about the soup of UI markup, but you do. You have to work around the quirks of the editor or constrain yourself. Say you want to target every 2nd heading, or the paragraph after a blockquote, you can't do that elegantly, because the markup is different in the editor as it is in the front-end and it's not solved by prepending block selectors. Gutenbergs editor styles solution isn't elegant either. It is not a complete disaster, but it's indicative of the fact that the project is imposing its own paradigm over the problems its trying to solve. It's literally creating new problems to solve.
> they are not without downsides too. In-browser editing is a compromise and balancing act.
I'm not convinced at all that a different approach to how the UI manifests itself in the DOM would have entailed any meaningful trade offs at all. I've been working with this prosemirror implementation recently and the basic example pretty much matches my demo posted earlier: https://tiptap.scrumpy.io/
WordPress has always been a project where user happiness outweighs developer happiness, though, as much as I'd love for it to at least bring developer happiness inline. It will be interesting to see what the overall reaction is when 5.0 lands and the editor starts to become more widely used and accepted.
And Gutenberg's development is precisely characterised by developers/designers prioritising their own happiness. It's a small group of people working mostly at agencies and companies doing enterprise level work who took Matt's idea around blocks and feverishly adopted the tools they personally wanted to use while developing and making decisions at a pace more rapid than other contributors could cope with. That is in part why we lost the accessibility lead.
Or, it's an opportunity. Look at Shopify - is it a problem that the first thing a new Shopify user does is to head to the Shopify app store to buy and install a handful of plugins?
Also worth noting there is no official WordPress.org paid plugin store and paid plugins are typically not hosted services as with Shopify.
The average experience WordPress users get when shopping for, maintaining, and getting support for plugins is much less smooth than a hosted platform like Shopify. (There are great WP plugin developers and terrible Shopify ones too, but fewer of the former than the latter.)
I can tell you why I do it. I host a couple of WP instances on my server. One for a non-profit sports organisation I am involved in and one for my mom. In both cases I look after the WP install itself (config, updates etc) and they deal with all the content. WP provides a UI that is easy enough for them to use to do so. I am certainly not interested in building anything “custom” for them.
I think you need to think beyond personal and marketing blogs. WordPress is much much more...
Quartz (qz.com) is built on WP. So was Wired (wired.com) and The New Yorker (www.newyorker.com). I had a hand in both The New Yorker and Wired and may other large media companies are built on WP.
To characterize it as a "simple blog engine" is mis-leading.
Gutenberg, while having its teething problems, is a big change. Big changes will cause upheaval. It will cause both petty and important disputes to rise to the surface.
I think this is no different.
The very idea that people try to host e-commerce on the platform is an embarrassment and a shame to security and safety.
It encourages the pattern of hiring non-technical staff to manage the blog-store-landing-page-franken-whatever site, who are in turn encouraged to install reams of untrusted code via plugins.
It is built on a frankly bizarre pattern of page and route management. It uses broken versions of a fairly broken language. It is enormously resource-hungry.
I could go on, but to sum up, my experience working with WordPress has been nothing but a repeated nightmare.
agreeing with sibling, WordPress _is_ a blog engine that has been twisted and squeezed to support other things. BuddyPress is probably the ugliest manifestation of this, one of the slowest, sluggiest, buggiest things I've ever touched.
I praise the extreme simplicity of the WordPress database structure, but that is also a very serious limitation.
Examples if issues:
- WP is ridiculously rigid when you want to scale it - that is due to having it's file storage as and actual file storage, without any abstraction.
- The media library is an utter mess since the backbone.js mockery added in 3.5, with inconsistent use of filter and hooks on backend vs frontend.
- It's forcing compatibility with long dead PHP versions. (5.2. That is before namespaces.)
- I only supports MySQL but maintains MyISAM compatibility, so no foreign innodb keys, no cascade delete, no nothing.
It should never have wished to become other, than a blog/small website engine without first making long, long overdue backend fixes.
But instead, for many years now, I'm seeing the community being neglected; features that are questionable, pushed through (emojis, REST API, Gutenberg); WP.org without a clear focus, and without answering decades old threads, like a database abstraction layer.
All that said, WordPress is easy to use - but I'd welcome an extremely simple, WYSIWYG, small, static site builder instead, with proper support for media, portfolios, galleries, with a WordPress importer, which could easily take over the mess, that WordPress, my once loved CMS had become.
</rant-ish content>
I guess my point is... how would you break down the functionality of those sites by Wordpress core, themes or plugins, and custom code? How much of what makes those sites great comes "out of the box" from Wordpress, vs being bolted on or written from scratch?
We used off-the-shelf plugins for for curation/features: ACF, EditFlow, Yoast (SEO).
We also used custom Plugins for building out curation and full content feeds for our iOS app, managing podcasts, and AB testing.
Quartz was different. We only relied on the WP editorial UI (with EditFlow plugin) and simplified the templates to just deliver JSON (this was before they had the JSON-API in core).We built an independent web app on top of that.
Hope that helps answer your questions.
If you've ever had to deal with out fo date, page builder generated shortcode messes, that is actually a problem that people would like to solve :D
Like, a standardized way of creating a mess is much better than 10 unstandardized ways to make a mess, right? But that's most of modern JS and PHP work anyhow :D
Because for whatever reason, people are failing to realize that Blogger is vastly better.
I want to publish a post about as fast as writing a text or word doc. The current wordpress editor is unexciting but has a fairly decent workflow. Faffing about with everything on a pulldown or modal is not progress.
A fair summary of my views of Gutenberg:
https://www.dedoimedo.com/computers/wordpress-gutenberg.html
WP is now getting a a TON of competition from static site generators, and companies like Netlify. Headless CMS' and Jamstack are the future for these types of sites and people are coming off of Drupal and Wordpress in huge numbers.
As their numbers have shrunk, they've had to make drastic changes. I haven't been seriously involved in the WP community for about five years, but I've heard rumblings within the community about moving to a modern stack that includes ReactJS or VueJS for a while now.
At the very least they're trying to maintain their position and modernize WP to appease some of the critics and vocal members of their community.
Adding extra behaviour to the classic editor is fragile, especially if the feature involves adding or changing something about an existing part of the UI. Gutenberg makes this relatively simple, and at least provides a blessed way of doing this (via plugins), whereas before you relied on the structure of the editor's HTML not changing and breaking your stuff.
Furthermore, everything is retrieved and sent via the REST API which seems like a great approach: it means you can reuse your plugin logic for other parts of the site, and in principle the new editor can be bolted on to some other non-Wordpress projects with only a few adaptions, and WordPress itself may one day be implemented in something other than PHP.
One other thing I like is the ease of use of Gutenberg. While it takes a few extra clicks for things, novices won't care about that, and having more visual clues will really help them. Plus, the blocks now give you a way to make things truly WYSIWYG, especially shortcodes which are otherwise just short strings that only generate their content when you preview the page. Now it's possible to make blocks instead of shortcodes that render whatever needs rendered in the editor.
I guess Automattic could have handled the development better, and given more time for the update to be tested and for the community to be informed and give their feedback. In 2017 they kept saying they'd release it in early 2018, which has come and gone, so I can't help but think they're pushing this out in a desperate bid to hit their original deadline at least in terms of the year. That part might bite them later, especially if there are any huge bugs yet to be discovered.
I found some of the keyboard shortcuts to be unintuitive. Toggling between code and visual modes required four button presses. Edit>Redo is also weird as it uses Ctrl+Shift+Z, not Ctrl+Y.
Overall though I think it's a positive change. I hope that Gutenberg manages to kill all those awful page builder plugins like WPBakery and Visual Composer. That would make me happy.
I am always confused which shortcut to use for Redo on Windows. Microsoft software is Ctrl+Y but I must've grown up using software that chose Ctrl+Shift+Z as that's what I always try first.
It seems that outside of the dev community and people actively involved in WordPress news, there's very little familiarity with the fact that Gutenberg is coming.
We've launched a productized service[1] that helps people take an audit of their site, get familiar with using Gutenberg and give them resources to make the transition.
We've mostly found that's it's been going smoothly, but there are plenty of cases where sites have different customizations that will need to be worked around or refactored.
The Gutenberg team is working hard on making sure legacy things are handled properly, but there's a lot out there and it definitely needs to be taken on a case by case basis.
I did. I went back to the old ways.
So this 3.5 weeks thing is a bit of a distraction.
I'm guessing that Dashboard push may have motivated this being posted here.
It was quick and easy to set it up, and works pretty smoothly.
I've tried Gutenberg and wasn't that impressed. It wasn't adding to anything I was doing and it managed to break two small items.
I know that the WP people are trying to go against Wix, etc. I'd like to have also seen them split into the new React and kept the "classic". I'll most likely become one of the 1000's of sites that become frozen on a 4.9.x release. It will be interesting to see if there are updates in the 4.9 tree or if it will be 5.0 only.
I look at the Wix, Weebly, etc market place has being worth WP going after and I'm sure they will try to pull company/vendor sites from the Facebook and I'm good with that. But one of the powers of WP is the ability to make pretty complex sites using PHP/Plugins. Moving to React isn't going to make that easy.
I really think that this is a case of dumbing down a product may not be a good idea for lots of the current users.
> ‘Clean, Lean, and Mean’
And even after double-checking, I can only assume it's somewhat outdated, or outright irony. Because while I consider WP among the software that has done the most good over the last few decades, those three words really don't come to mind when trying to describe it.
Of course at the time it came out it's immediate comparisons where these $7-digit behemoths being sold to Fortune 500 companies, and it probably did not rely on plugins as much as it does now. So I can see how clean & mean made sense at the time.
Most of us never have to touch the core though.
I made a library[1] to make blocks so I’ve been using Gutenberg a few months. Feels like it could be really really nice if a few changes were made. I commend the WP community for making it though.
Big issues are with trying to make more than just a few blocks, the editor really doesn’t enforce and code splitting. So unless you’re using a library like the one I created, having let’s say, 100 blocks is going to mean an insane amount of JS on page load. Also, good luck trying to debug the stack traces you’ll get in browser. I could go on but the point is: Gutenberg is a nice idea but real projects will find issues.
A big advantage of blocks is they will allow us to simplify many of the different concepts and interfaces throughout WordPress, including our old WYSIWYG sorta-blocks, shortcodes, widgets, menus, and embeds of all types. It solves literally hundreds of interactions where people used to get stuck in our old WYSIWYG and either switch to code view to fix things, or just give up. Like all software, the 5.0 release of WordPress isn't a finish line, it's a starting one. We are already planning for 5.1 and beyond (including minimum PHP updates) and we look forward to bringing the fast, public iteration cycle that Gutenberg has demonstrated to more parts of core.
Hacker News isn't the right place for this discussion, I know, but I want to get it out there. Accessibility is one of the best features of WordPress, even if most people don't know about it. Keeping the WordPress editor accessible not only helps people with disabilities, as it also aids people who may have a temporary ailment (holding their baby, and just having one hand available, for example), or even "invisible" disabilities such as dyslexia, ADHD, or an Autism Spectrum disorder.
The new block editor has made tremendous strides at improving individual component's accessibility recently, and I believe that's where the confusion and miscommunication comes in between all the core teams. Code-wise, the block editor is quite accessible; zoomed out, the editor as a whole isn't. It's a UX issue, more than a development one. It's what happens when the design isn't with accessibility in mind.
I don't think it's worth punting release, but I really would like to see more work on documentation and warnings in the core to people who rely on assistive technologies. If you don't know the layout of the block editor and had to navigate it with only a keyboard and no eyesight, it's incredibly confusing! If there was proper documentation, you might be able to explain the layout and mechanics, which would help, though still not solve all the problems.
If someone is blind and has a blog, in my experience, 90% of them use WordPress because it's very friendly to them when they want to write. It's not a fair comparison, as TinyMCE merely is a glorified text-field, but that's also one of the old selling points of WordPress -- super simple out of the box.
It's my understanding that a lot of the preliminary design for Gutenberg was behind closed doors inside of Automattic, before publicly being brought out to the public and collaboration ensued. I don't believe there is anything wrong with this, as it happens within many FLOSS projects by corporate interests that rely on the platform. I do though wish that in the initial design phase, accessibility was a goal, not an afterthought. It may have been a goal too, not denying that, but there might have been a lack of expertise in regards to how to make interfaces fully accessible.
I don't mean to attack the editor, Automattic, or you about this. I know you've heard a lot about it. I love the block editor; it's such a pleasant experience for me to use. I worry that people though who aren't as able-bodied as I won't feel the same though.
Finally, I have a hunch that Automattic itself has now found that it needs expertise on Accessibility, which is why there's this: https://automattic.com/work-with-us/product-designer-accessi...
I do believe in WordPress.org, and I love Automattic as a company and their stance in regards to the open web. I like that Automattic is a company built on my personal-favorite legal document, the GNU GPL. I'm looking forward to the day that the block editor is accessible, as it's not now. I do believe it will be. I only wish there was a stronger push before :)
https://make.wordpress.org/core/2018/10/18/regarding-accessi...
Accessibility has been thought about from the beginning, and no design happened behind closed doors (it was kicked off and announced at WCUS 2016), but we are doing a fundamentally more complex task with block manipulation.
I'm not sure what the best path forward is there. We'll continue to make the block editor friendlier to accommodate accessibility needs, and I also think it's important that WordPress has a variety of ways to post to it, from email, to other apps, to the command line... by supporting as we always have a ton of ways to get content in and out of WordPress it'll allow people to use the interface they enjoy the most.
It's a static site generator.
Gutenberg thoughts: It's seemed to me that much of WP success in the last several years has been driven by the ecosystem of page/theme builders, which have been built around serving various verticals. They've solved a core problem of not having easy baked-in structured data management, and Gutenberg looks like it's a first step in standardizing that. It seems the tools community will need to adapt to that, which they might, but it also seems like it might be taking away some of their value-add, and there may not be enough room higher-up the chain to add value.
I don't know if there's a huge reason for some of the theme/page services to rush to support the upgraded 5.x series; if it makes it easier to switch to a competitor... will they have much incentive?
This is certainly a shift in the WP world, but it feels like it's at a point where they could lose a chunk of users to competitors. For a lot of other users, though... where would they go? As with many upgrades, if the pain is too much for not much value, that's a time when people would consider other options more seriously.
Like the article says: They see for-profit site builders: squarespace, wix ... as eating Wordpress market share and feel a need to advance Wordpress to make it competitive. They know it’s risky but they see it as an important way to stay relevant.
Wordpress users seem on board with this. A lot of them aren’t developers and want easier solutions to hand their clients.
(Except the guy with the “Gutenberg not in core t short”
I can imagine many people having trouble to adapt because they are not familiar with using styles and templates.
I was not familiar with Gutenberg and was offered to activate it a few months ago. I did so and manage to make it work for me.
I consider that writing structured documents is part of personal advancement in IT and should be viewed as such.
However, I also think Automattic has made life for themselves much, much harder by fragmenting the code base like this. WordPress was always monolithic in its approach, and trying to tack on a (newer, more modern, but still wholly different) core component is a major risk.
I'm working on a migration plan to some other platform as part of our business continuity plan. The stability of WordPress was its biggest selling feature. Now, that will no longer exist.
For all their faults (which are less and less as it develops), WYSIWYG fields using TinyMCE have the massive advantage that they look like the word processors that most people are familiar with. Beyond small personal blogs I just don't think Gutenberg adds any value, and if anything muddies the water for site editors if you're using structured data and Gutenberg.
We've taken the decision to disable Gutenberg entirely and just use custom fields so we can maintain stable data structures, rather than trying to crowbar that into Gutenberg somehow. All you need to do is only use custom post types without the "editor" capability, hide the Posts menu item, and define everything through CMB2 custom fields.
TinyMCE really is quite extensible and flexible if you keep to it's sweet spot. It can produce fairly clean and consistent markup based on a whitelist of elements - which is critical if you're storing HTML directly in a database field.
And since then, these two troubling things have happened:
Oct 9, Accessibility team lead resigns over Gutenberg - https://wptavern.com/wordpress-accessibility-team-lead-resig...
Oct 17, Accessibility audit canceled, because the new accessibility team lead "didn’t have the authority to authorize it in the first place" - https://wptavern.com/gutenberg-accessibility-audit-postponed...
Gutenberg has its place in the web dev world of 2018 but it should have been a completely new project instead of a replacement of good old Wordpress.
Maybe it still requires some polishing but I think that people don't like it mostly because it is something new and they are not used to it yet.
On the other hand, while everyone predicts the death of wordpress, there is still no viable alternative. So many projects on Indiehackers start on wordpress still. There is still no customizable, verstaile alternative for wordpress in spite of its many failings.
If there is an alternative with an ecosystem as big as wordpress, or atleast has the growth potential to become one, I am very eager to know.
There probably won't be, because it would introduce many of the same problems WP has.
If you want an ecommerce platform, there are plenty to choose from. Throwing 'woocommerce' on top of your blog solves some problems, but creates (many) others, and if your focus is ecommerce, use a more focused platform. It's the "it can do everything for all people" aspect which has created some of the problems we see.
What is the best solution for a decent shop nowadays? At least if you want to host it yourself and not rely on a service like Shopify?
Paid support from some plugin vendors always ends up with "disable all plugins except ours first and run everything that way before you ask for anything else". "Even the plugins that this one depends on?" I'd ask, to no reply. I understand why, but plugin vendors will point the finger at other plugins - sometimes rightly so - but when so many plugins can change global state all the time, it's a pain to track down what's breaking.
Any time I bring experiences like this up, I'm told "no one has 60 plugins, that's horrendous, I'd never have more than 5 plugins on any WP project ever, you should have started over, you're exaggerating" - some combination of those sentiments. There were 62 (or 65) plugins - IIRC somewhere around 10-12 weren't actively used.
When I inherit projects, I often argue for greenfield rebuilds with the lessons learned from the previous project. When that goes through, I often hit a valley of "we should have refactored". When starting off on the "refactor" path, I often hit a valley of "this should have been rebuilt". There's often not much way to put good tests around WP stuff to get the confidence and repeatability needed to move forward with large scale customizations.
If you start from scratch, have a talented team who understands all aspects of WP development and document things, perhaps it's "good" to start with?
If you're selling a handful of items... yeah. If you're happy with existing themes and don't want any substantive behavioural changes to how themes/plugins work, yeah. Use it. When you want custom or large changes to how the $80 theme sellers think you should run an ecommerce store... I wouldn't recommend it, and I don't know what I'd recommend, really.
Other options: The Sylius project? Foxycart?
Some of the commerce projects I've dealt with are doing hundreds of thousands of dollars, up to millions in sales. They were pushed to woocommerce because 'it's cheap, can do XYZ, no need for "expensive programmers", etc'. You're doing $800k in sales and have no unit tests on the code running your entire operation? On top of that you want changes to fundamental code bits, without easy to setup dev/test/staging/prod workflow or unit tests? Scares the crap out of me. But yeah, I'm not a WP-head, so perhaps you get used to that level of "seat of the pants" working? Or... you spend so much time/effort setting up custom workflow that you can now easily churn out "woocommerce" work with some level of repeatability and confidence? You're probably not on the 'cheap' end, which is often a selling point for WP/woo work.
No doubt, I know that the woocommerce base is used on some big projects. I also have to imagine they had larger teams of people doing custom work fulltime for a long period of uninterrupted time. If you have that team and are doing customizations and integrations, you're not in the realm of "I need something simple that's not magento".
Ultimately, it depends on your needs and skills. Solo/small team, already 'know' WP with existing skills in that world, use woo - knock yourself out. But don't color too far outside the lines.
For a WordPress only site, half a dozen plugins for specific functionality is what I aim for.
But WooCommerce, they pile up really quickly just for core requirements like payment gateways, a quickview, wishlist: Things that are core or would be baked into the theme in Magento.
62, wow. I flip out if they had half that. Usually they're running some sort of cruddy backup system, multiple security plugins because they got hacked previously (not surprised) and a dozen plugins that they don't need.
WooCommerce on the other hand is all plug and play and easy enough for a lot of shop owners to self-manage.
Magento's admin interface is superior and if your catalog is in the order of 100s of thousands of skus, nothing else is going to cut it. But as you said it needs a lot more server to run effectively.
That's an odd metric. There's loads of companies around wordpress and plenty of companies that focus on woocommerce implementations - that's wholly separate from the complexity of the systems in question.
Wordpress.org appeals to hackers, but Wordpress.com appeals to hacks. No tech support needed, no 3am beepers because a badly behaved plugin wet the bed.
So I am happy that Wordpress is slow to intro new software. Make it work and make it intuitive. Wordpress is the least annoying tech vendor - like Apple in their best days (not now sadly). Not perfect - who is? Would like better wysiwyg editing. But bigger beef is search. It sucks. I use Google to find info on my own site.
It lets you tweak search results by giving different weights to titles, categories, excerpts, and more. I'm not affiliated, but if the default search is no good on your site it might help you get the results you expect instead.
Up till 2004, the king of all blog software was Moveable Type, written in Perl. In theory, you had to pay for this, but there was a liberal free license. Then in 2004 they got strict and said, hey, everyone has to pay.
This set off a movement to find another free blog software package. For awhile it seemed like there were roughly a million blog software packages, written in different languages. PHP was easy to learn, so it gained traction. Blossom was big, Typo was big. Then WordPress gained traction.
During the long era when other blog software was dying, and WordPress was emerging as the clear winner, the success of WordPress was driven by the understanding of BDFL Matt that designers loved it. It worked well with software such as Dreamweaver. People came to PHP because it was easy to learn, and so WordPress should also be easy to learn. Because of this, Matt insisted that WordPress stick with PHP 4, rather than PHP 5, for many years. I believe PHP 5 had been around for 6 or 7 years before WordPress began using it. I believe Matt was worried that the Object Oriented ideas in PHP 5 would be difficult for newcomers to learn.
I believe the decision to stick with easy-to-learn PHP 4 was essential to the success that WordPress enjoyed during that era.
Which is why I am so surprised by Gutenberg. Telling the whole community that they need to learn React is a shocking change of tactics. Instead of focusing on easy-to-learn, WordPress suddenly wants to become best-of-breed? That is a different niche in the ecosystem of CMSs. Once a good value Honda, WordPress now wants to be the high quality BMW.
React radically increases the amount that new developers will have to learn to become proficient with WordPress. And if you're asking developers to radically increase their investment, then suddenly they are going to consider other options, such as Ruby On Rails. If WordPress suddenly becomes one of those frameworks that needs 2 years of hard study before you really understand it, then maybe you should be learning some other framework during those 2 years? Because there is also a lot of ugliness and technical debt in WordPress, things that made sense when the focus was "make life easy for designers" but which don't make sense if the goal is "be the best framework."
I was around in 2001 when PHP-Nuke decided to go down a similar road. The decision was made that it would be refactored into a series of components, each of which would have an elegant interface for interacting with the other components. PHP-Nuke was going to clean up its technical debt, become more secure, adopt best practices. But previously it had been playing the role of "easiest way to set up a blog or forum". It gave up one role and tried to become something else completely. It self-destructed. Two years later it was dead, no one was using it.
It seems to me that WordPress is going down the same road as PHP-Nuke. Obviously WordPress is a much bigger community than PHP-Nuke ever was, but it seems like it is making the same kind of mistake. I thought Matt was extremely wise for sticking with PHP 4 for so long, but Gutenberg seems like the kind of mistake he would have been making if he'd adopted PHP 5 too soon.
This is the heart of it.
To extend the analogy further, they actually could take a page from the car industry. When Toyota and Honda and Nissan wanted to move from the value-for-money segment into the luxury-car segment, they invented new brands for those luxury products (Lexus, Acura and Infiniti, respectively) instead of trying to convince people that "Toyota" and "Honda" and "Nissan" stood for something different today than they did yesterday. And this strategy has been quite successful, letting them grow into a new market without undercutting their hard-won position in the old one.
Not only technical bugs, the UI is poorly designed.
The article announcing Riet's resignation is https://rianrietveld.com/2018/10/09/i-have-resigned-the-word... (Working at time of writing this comment)
Automattic's position of quite verbally "throwing" Gutenberg at users and developers at any cost just shows a really bad example of business driven FOSS project as a base for commercial product (.org for .com).
A11y is just one of the victims. Other community members creating WordPress based websites, services and plugins (myself included) are mostly thrown overboard as a collateral damage. Either learn react fast and figure Gutenberg out by yourself or maybe we'll let you come back later if and when we get to work at least on some documentation and the well-known issues that affect you. With Gutenberg's extensibility being the biggest and most harming one for WP ecosystem.
I use it myself for a simple corporate blog, because it's so widely supported and everything else sucks even worse....
So how is it the end if everything else sucks? Maybe they are stumbling here with Gutenberg (I haven't tried it or even researched it much), but it seems far from the end.
I still don't expect anything to overtake WP. A big reason is that too many agencies rely on it at this point, they aren't going to want to switch to anything else. Also for lower budget clients, pitching anything other than WP is a hard sell these days, as an increasing amount of non tech-savvy users are familiar with it.
That's why it's not the end.
What is with catering to the worst and most clueless users only? We need more than that. We deserve more than that. Gutenberg is disastrous for anyone with an IQ above that of a carrot.
But are there any real alternatives?
Well, insulting hyperbole certainly isn't going to help.
From what I can tell (I haven't used Wordpress in a long time, so I didn't know about this), the main complaint is it's more touch-optimized, and as a result desktop editing with trackpad/mouse is more complex.
That's a fair criticism, but not a conclusive argument against. If the most common use case for non-technical users is a touch interface, then making that the default, and giving highly-technical users who prefer the old editor a way to swap back to it... seems like a perfectly reasonable decision to me, and one that should be made on the basis of user research and usage stats, not on the basis of people who sling insults and leave 1-star reviews on a plugin marketplace.