I'm technical director of an agency that builds websites solely in WordPress, and I can say with feeling that Gutenberg has (so far) been a disaster not just in terms of accessibility but in terms of clarity of the development process. It's been a moving target since day one, with us constantly scrambling to keep up with large changes in each release. We held off for a while, and have only built three sites with it, but I wish we'd held off longer.
For example, there have been major interfaces changes on a regular basis, each of which we have to spend time walking our clients through. One change - defaulting to full-screen editing, which hides the menus and loses a lot of context that editors were used to - was pushed through at the last minute of a release cycle with a personal intervention from Matt Mullenweg. That meant that suddenly editors were confronted with an unfamiliar editing interface even if they were already registered and hadn't changed anything themselves, rather than a dismissible tooltip letting existing editors know that they could use a new full-screen editing interface. That seemingly arbitrary and personal style of project management really doesn't foster confidence that things are being thought through carefully.
I know from personal experience that you need to keep up momentum in a development project otherwise things stagnate, but so far the development of Gutenberg has been very much "move fast and break things" which would feel appropriate for a beta, but not for the default editing experience.
I think Gutenberg may well turn out to be really good - our clients do prefer it over the classic editor once we have it under control - but the way this has been managed has lost a lot of good will on our part as an agency and I've been actively looking at other CMSes like Craft as a result.
Gutenberg shipped way too soon. It has been a textbook case of how not to launch a product. Solid idea...horrendous execution. Mullenweg owes the WP community a massive apology. He especially owes the #a11y Community an apology. Hint: In either case don't hold your breath.
But more importantly, it should not be in core. Full stop. Once WP became REST-driven the push should have been to lighten core. That is to decouple as muxh as possible. Core is that _core_. Then you configure your needs from there. Core should be the basics, as light and as lean as possible.
But instead, more and more unnecessary bloat. More and more features with less and less benefit.
Yes, I'm looking at CraftCMS and others as well. WP has jumped the shark. It's not going away. But I'm tired of having to shower after everytime I work with it.
WordPress has never internalised the ideas of API-first development or the ability to have a lightweight core, and to this day it’s still treated as an addon piece that could someday be removed.
(Source: I wrote the REST API in WordPress and lead the API team for many years.)
Exactly. Let's make removable the piece that is the most industry standard compliant. The pieces that maximizes the flexibility of "the appliance". If GB came first, I'd agree with you. As we know, it did not.
But instead let's force feed - oops, I mean ship - and bake in a product (i.e., GB) that was half-baked technology implementation and barely an afterthought in terms of user experience. (Note: UX in this case includes all the devs who were begged to jump on board, and then jerked around like a puppy on the leash.)
WP core should be a service. Lean, tight and clean. Tightly coupling more and more likely unnecessary features to that doesn't help anyone. Trying to maintain that monolith is overly complicated. And so on.
We have the plugin architecture. If it's broken, then let's fix it. If it needs some sort of dependency manager, then let's talk about thst as well.
But Gutenberg? That makes 2020 look like a summer holiday, and we all know how bad 2020 has been :)
CDN support out of the box isn't essential, most sites will never achieve the kind of traffic that merits a CDN. However, to add to your list: database migrations, task queues, middleware, form validation, templating, dependency management, unified plugin framework, etc. No lack of callback soup though.
Those don't belong in core either. Core should focus strictly on the being a rock solid foundation. Plugins are there to supplement that. That's the beauty of the architecture. Or at least, is supposed to be.
WordPress should not have the same mindset as Jetpack. Oops? Did I just say that?? ;)
Literally everything in your list is about developers.
Literally nothing in your list is about editors or end users.
Maybe take a look at the words "content management platform" and consider whether maybe developers aren't the most important people in this particular world.
Most people love WordPress because most people aren't nerds. They want to easily publish content using a familiar and intuitive interface. They couldn't give a monkey's about whether it's written in PHP, Django, Perl, some Jamstack fad or BBC basic.
Most of this plain isn't true - afraid it does feel very much like a bubble there!
> - Uses PHP 5 spaghetti code with a handful of garbage event listeners and output buffering
I mean it has listeners for almost every event you might want to interupt and trigger something on that are well documented and have been for decades.
The PHP 5 code is very much legacy so I will grant you this.
> - Has no integration with composer at all
Composer support is absolutely fine and there are well maintained ways of keeping plugins and themes under Composer and have been for many years.
> - Doesn't have any form of content types without plugins
Yes, but adding further content types at the level of code or these plugins is easy, trivially so.
> - Has no cache, no theming engine, no multi-language, etc etc
It has several caches that are very powerful indeed, including those included by default. PHP is a theming engine.
Internationalisation built into the core, I'll grant the multi-language support is not as good as it might be. Could be better.
> - Beyond a media library it has literally no aspects of a "content management system"
I mean, people use it to run newspapers, so not sure if this is true. It depends what you need.
The organisations behind WordPress decided to meet their user need and provide a really good, well understood platform for content management with an extensively tested UX experience of end users. They prioritised this over developer niceities.
If the purpose of software is to augment human capacity and be genuinely useful, this was the right decision. The rough edges from a developer experience perspective have been largely smoothed off by a well established ecosystem like Roots.
> Composer support is absolutely fine and there are well maintained ways of keeping plugins and themes under Composer and have been for many years.
You need to use a third party service or setup.
> Yes, but adding further content types at the level of code or these plugins is easy, trivially so.
Compared to what? Drupal? CraftCMS? Joomla? Where you go to a UI and do it all, versus installing a plugin with it's own quirks or using functions.php which ends up being the last place you want to touch after your done?
> It has several caches that are very powerful indeed, including those included by default. PHP is a theming engine.
Fair enough. Probably at "agree to disagree" here.
I'll agree that its easier to do custom post types on other CMS. But sometimes at the cost of real overheads in terms of complexity for users to swallow to get there.
Caching is built into the core, which is what all caching plugins leverage, the interface to it is hidden.
PHP is a theming engine.
I've never got why people escape into Blade, Twig or so on. PHP was designed to have loops, logic, to take variables and so on and interpolate them within HTML. It has an alternative syntax to make this easier. It's one of the unique capabilities the language has over almost all other languages you'd use on the web. More often than not you end up escaping into pure PHP in any case in something like Blade.
> But the problem isn't random sites use WordPress, the problem is people build weird monstrosities on top of a really garbage system.
Don't think its garbage for the reasons explained, but I think this true of all software projects. Seen plennty of Drupal, Laravel or Joomla projects end in this state.
I've been learning Laravel and Statamic this year. Both are a joy to use. I've been building WP sites for about 7 years. My goal is to never build another WP site again. Gutenberg is just one reason why.
I think one thing that's missing from the templating engine argument is WordPress' data model. While PHP may be a templating language WP's API to access data is a huge pain. A great example is wp_nav_menu. To modify it in any meaningful way you have to use the Walker Class. Seriously? It's an array. If WP's data model were better you could definitely 'foreach' your way through that thing... but you can't.
Antlers has a shorthand syntax to cycle through its navigation type. Laravel doesn't have a native navigation type but when I set one up it's pointing to table of pages. At this point I can use Blade to go through that table and pull out the appropriate title and url.
Why is this nice? No more "#" for placeholder menu items. More control over the Aria roles, etc.
This is just one win, in my experience, of using Laravel/Statamic.
Massive fan of Laravel. If the relationship between Statamic and Laravel is similar to that between Wagtail and Python, plus the static storage, it seems like it would be very good indeed.
I don't know anything about Wagtail or Python so I can't speak to the comparison. However, I chose Statamic because it's a Laravel package and can be extended via Laravel. That adds a lot of flexibility to it. From what I understand Livewire is also compatible with Statamic.
> I've never got why people escape into Blade, Twig or so on. PHP was designed to have loops, logic, to take variables and so on and interpolate them within HTML.
Compare a Twig theme with a PHP based one. The former is much cleaner because views and controllers are separated, there's clean ways to reuse views, and the syntax is cleaner and more concise for common operations. The standard PHP approach in WordPress gets messy really quickly.
Related, but I can't believe how much responsibility WordPress theme writers have to manually make sure echoed strings are escaped properly (Twig has the same problem because it would be fighting against WordPress otherwise).
Mate, Wordpress does not even have a way to manage your images without using a plugin. People using Wordpress to run newspapers and magazine sites have to use a hacked together solution involving either more plugins or writing custom code. As someone who's had to run a magazine site with Wordpress, I can painfully recall all the issues I've faced and cursed the dev team.
When you have a few hundred images (and that's just for a small site, let alone newspapers), do you really think having just a dropdown with media type and month for a filter (out of the box) suffices? Asset management is a core feature for any large-scale media outlet CMS.
> PHP was designed to have loops, logic, to take variables and so on and interpolate them within HTML. [...] one of the unique capabilities the language has
Totally agree, but unfortunately PHP's integration within a markup processor is quick and dirty, without consideration for context-dependent escaping and quoting etc. hence continues to give rise to a large number of HTML injection attacks.
This is true. I understand other languages (for example Go) have very nice features of this kind - contextual auto-escaping and so on. However a lot of other languages also have these footguns around escaping and security.
WordPress is more about the ecoystem than the CMS itself. If you just install WordPress without any plugins or themes, it's pretty useless.
WordPress is so popular because you will find a plugin or theme to fit almost any need.
The majority of the users are not developers that care about composer, WP source code or out-of-the-box potential. They are users who know that once they install this platform they can create whatever site they want in a few hours doing a few Google searches and maybe spending a few hundred bucks.
Also, Statamic is free for personal use now. If you've got some time download a copy and play around with it a bit. It really is the most fun I have had building a site in years.
Anecdotally I have heard that many clients prefer Statamic's and CraftCMS' editing experience over WP.
Nope. But anyone that needs one probably isn't a position to self-host and is going to require the services of a developer negating the costs of the services anyway.
They also get free suppport. You don't get that with WordPress.
Sure, but at that point the user is now paying for web hosting rendering the cost issue moot. And when they do run into issues who are they going to turn to? With the exception of WPEngine my, and my client's, experience with support from web hosts is garbage.
Aside from that, what's the UX like for a client spinning up a new WP site on GoDaddy or Bluehost vs. a new Wix, Weebly or Squarespace site?
In the end most of this is pretty subjective. If you like WordPress keep using it and recommending it. I used to love it and don't anymore. I think my clients get a better value using Statamic or one of the other options I've pointed to.
Honestly, I'd love to see some numbers these days. If you're a developer, sure. But I've seen very few non-tech types that manage their own WP sites. And the ones that do tend to put a a lot of time into tutorials of various kinds. Start throwing a price tag on that time and I suspect WP becomes more expensive.
Like PHP in general, it was easy to get started with and now there are tons of developers pushing it in the ecosystem. Now that so many people know it, it's self-perpetuating at this point.
"Why do people continue to try and shove weirdly hacked on garbage plugins on top of basically a glorified blogging platform is beyond me."
I've been critical about Gutenberg, but I'll respond to this by sticking up for WordPress a bit here.
Others have answered the technical questions, but on your point above, that's not what agencies like mine do. We write custom theme code from scratch (although we do have a base framework that we built as a starting point) for clients, and use WordPress as a base system. It deals very well with those kinds of things as long as you know what you're doing. We spend a lot of time with clients up front to understand their use case, and build something robust but user-friendly. The first site we built, for a cross-UK social enterprise with over 200 services, is still going strong. Just because some people (that is, a lot of people) think you can chuck some free hacky plugins at WordPress and get a website doesn't mean that's all it is. It's evolved to a point (well, had evolved to a point) where it was a great base CMS on top of which you could build quite complex websites.
There's a decent ecosystem of paid plugins, like Gravity Forms and SearchWP. If you know your stuff there are also some great open source ones, like CMB2.
Some other reasons why agencies in particular stick with WordPress:
1. People know it, are familiar with its conventions, and actively request it. It allows organisations who are growing to jump from their little Wordpress site to something more complex without having to relearn a CMS. If you're an organisation that's familiar with a CMS there's a significant time cost involved in your staff learning how to use a new one. That's not a good reason on its own for not picking a different CMS, but it's a barrier when the CMSes you're comparing a much of a muchness.
2. Because it's so ubiquitous, if you want to change agency, that's relatively easy, reduing organisational risk. (Choosing an agency that care about quality, however, is a different matter). If you use something that's not common, you risk having to rebuild a site from scratch because no-one else can take it over.
3. There are excellent WordPress hosting companies out there that take away the legwork of doing things like full page caching, CDNs, git, LetEncrypt etc. etc. We use one that for ~$500 a month offers exactly what one of the hosting companies listed on the CraftCMS site does, but we can have 35 separate sites, whereas the same money would get you just two on the Craft CMS host.
Honestly, I think you can do pretty much anything you want in WordPress and Drupal, and possibly CraftCMS too, although I haven't gone deep into Craft yet. What makes a huge difference is getting an agency that knows their stuff and actually cares about both build quality and high-quality hosting.
I think the "hard and fast" mode is also making it hard for plugin developers to keep up. Two weeks ago, a conflict was pushing changes to a live site on preview. (Which is absolutely insane to me - I suspect there are users who unknowingly published changes to a live site)
> " Fixed validation bugs
One of the major improvements shipped in version 5.9 (PHP validation for the Gutenberg editor) was found to accidentally publish changes when previewing a post. The same bug was also responsible for preventing the Beaver Builder plugin from launching its custom editor – sorry. This bug is now fixed, and previewing content will now work as expected."
Well, I'll chime in with a weird bug that was supposedly gone from previous versions but came back in WP 5.4 Gutenberg.
You know those side panels where you can change values for blocks like padding, etc.? Well, every time I started typing in a value, the input field would lose focus. So if I wanted to enter 100 as a value for height in pixels, I would need to enter 1, click back in the field, enter 0, click back in the field, enter 0 again. Or type it in a text edit and copy-paste.
Not choosing and inaccessible platform was the right thing to do. Hopefully this will make Automattic reconsider their priorities regarding web accessibility.
I am an adult with no accessibility challenges and I still find Gutenberg a piece of crap whose interface seems designed to make you pull your hair out.
All my clients who just want to write posts ask me to turn the damn thing off. Somebody once yelled, "WTF is this stupid thing making me add blocks for each subheading and paragraph? That is not how writing works!"
“This post is only visible to RSS feed readers, unless you got here by manually parsing the feed (weirdo) or someone shared the link with you (they probably should not have).”
Adrian is a talented designer. I've known of him since his evolt.org days. Rather surprising then that this is the design he went with. But hey, personal blog allowances, I guess.
> One final note. We are currently considering a Headless CMS option for front-end page delivery. This means using the CMS in a decoupled way to manage content but use a separate system to deliver front-end pages. Please note this solution would not be reliant on JavaScript (e.g. a single page app which is common with headless.
Excellent. SPAs have their place in things like Notion and Google Docs. I’m glad they’re not depending on Javascript.
it would be ridiculous if w3c relied on javascript for it's website. for instance the current website demonstrated a lot of advanced html/css when it was updated ~15 years ago
It's no wonder, Craft is a great pick. I've built numerous sites with it and it works like a charm. What they nailed down is that it has great UX for content creators and developers as well. The speed at which you can build sites is amazing.
You can even build your startup MVP with it if you consider it as a headless, REST API prototype tool. Data modelling is where it excels.
I guess I have to stop praising, it starts to feel like a paid ad :)
BTW I don't get the naysaying for being proprietary, the source is open.
The source is shared, it is not an open source CMS. If it was an open source CMS, it would be provided under an open source license that complies with the OSD in full.
I love Craft's data structure. What WordPress mashes together as custom post types, Craft natively implements as entries, which are arbitrary collections of fields.
It's also trivial to keep under source control.
My only gripe with Craft is Redactor, which can easily be replaced.
When working with WordPress, can anyone recommend a trustworthy place to go for plugin recommendations?
The problems I find with WordPress are:
- WordPress core is missing a ton of stuff you'd expect to be there so you have to turn to plugins.
- It's hard to assess the quality of plugins. They conflict with each other, kill page speed, they break as WordPress is upgraded, and there's tons of bad advice you have to navigate around (I find this problem with PHP in general, where top voted answers/suggestions are bad so you need to keep your wits about you more-so than other communities).
Generally when I'm fixing WordPress websites, I'm stripping out all plugins (I've seen over 50 on one site before!) that have been added by non-technical users, then trying to find the simplest way with the fewest plugins to get the functionality back to what it was.
You can get pretty far with just ACF, a contact form plugin, an optimisation plugin (how is page caching still not built into WordPress?), and coding small features into themes directly.
> You can get pretty far with just ACF, a contact form plugin, an optimisation plugin (how is page caching still not built into WordPress?), and coding small features into themes directly.
This. I work on large, high-traffic WP sites a lot, and we're essentially keeping a hand full of plugins and writing everything else ourselves. Lots of plugins are complicated because they want to enable ordinary users to customize their behavior, which you don't need if you have even basic php skills. And from a code quality point, I prefer our own over most plugins.
If anyone builds sites for clients and uses a lot of plugins, it's because they don't have anyone that can write code.
Can you recommend any plugins in particular or a place you'd trust for plugin recommendations?
> Lots of plugins are complicated because they want to enable ordinary users to customize their behavior, which you don't need if you have even basic php skills
Yes, I've realised this too. Generally you pay for the features + customisability you don't use as well.
E.g. if you want to add social sharing icons yourself, just inline a few SVG icons with links to like 3 social networks into your theme and you're done. A social sharing plugin though will offer to connect to 100+ social network, with live share counts, icon choices, colour choices, page placement choices etc.
On top of this, most plugins aren't optimised and they'll load JS and CSS you're not even using (including on pages you're not using the plugins at all).
Similarly, I've seen contact form plugins that for a simple three field contact form will load underscore JS, backbone JS, fontawesome, jQuery and a pile of CSS.
I think part of the problem is WordPress plugins compete with each on features and need even more features on top to charge for the premium version, so page speed and robustness via simplicity get lost in the noise.
I can't recommend anything beyond ACF (and that I'm somewhat hesitant, it has a few annoyances) and maybe Autoptimize (feels stable, but haven't worked with a lot). I work with Yoast a lot because clients like it and editors know it, but I wouldn't recommend it. I hate all Permalink-Plugins I've ever seen. I don't do any caching in WP, I use varnish.
Otherwise I experienced exactly what you mentioned. Install a plugin, write code to dequeue its resources from all pages it's not running on. Of course, there are plugins that help you do that, but it's yet another plugin!
> I think part of the problem is WordPress plugins compete with each on features and need even more features on top to charge for the premium version, so page speed and robustness via simplicity get lost in the noise.
I agree, that looks like part of the reason for bloat, but most have also evolved over years. Most successful plugins have been around for a decade or so, and few people talked about web performance in 2010. That many authors initially just solved their own problem while learning php and shared their solution plays a part as well (not to mention that they often started writing them on php4).
With regards to Yoast SEO, I stepped away from that. Over the past few years there have been many instances where an admin_notice could not be removed. The last straw for me was last Black Friday sale, with a yellow flashing banner on all my admin pages. Not fun.
I use The SEO Framework now on most of my sites, and it is a good experience. It is made by someone who cares about his users instead of wanting to milk them.
Indeed. This is one of the reasons we started maintaining what is essentially a WordPress-for-enterprise distro, with a mix of first- and third-party code. The third-party plugins we bundle with it are from the select few sources we trust to build and maintain quality code (typically our peers).
> This is one of the reasons we started maintaining what is essentially a WordPress-for-enterprise distro, with a mix of first- and third-party code.
Is this available publicly? Most of my work these days is putting right WordPress sites (and setting up Varnish and ESI) rather than building them, but this would be of interest.
I think one of the largest and best place to find plugins is still CodeCanyon[0]. Because it has such a big audience and established market the good plugins are usually quickly separated from the bad ones.
Even the high rated plugins there are pretty terrible and some are downright security nightmares. Just be careful.
Also have run into a ton of plugins that don't play nice with dockerized deploys (they want write access and don't use the native wordpress functions).
I agree, it's still a minefield and for a really big business where the site being down a few days is a disaster it's not the way to go. I still think that for the average user, WordPress + themes + plugins is the easiest (not best, but easiest) and cheapest way to go.
So while talking during the entire article about being firm supporter of open source software, they choose a proprietary CMS. I'm disappointed by the W3C.
I have to say that I’m not sure why we would care about the license of their CMS. Their work is on standardization, whatever tool works well for them in their context is a good choice. What matters is their output, that standard documents are available publicly and are accessible by the majority.
The long term support of that CMS also matters. Exported HTML/CSS/JS files look more and more like binary blobs.
If you can't edit those pages in 10 years from now, without yet another expensive migration, then in retrospect it will rightfully seem like a poor decision.
Not really. As they explain, they took great care to make sure that the output (and thus saved data) is in line with W3C mission. Maybe migration might be needed in the future, but I see no reason why it would be any more expensive than migrating from WP (which is, btw, notorious for its storage schema choices).
One important point tucked away here that is getting missed:
> Another major factor in the decision to remove WordPress from consideration was that they found “no elegant solution to content localization and translation.”
To restate - WordPress does not support multiple languages by default. And anyone who has built a multi-language WP site with one of the popular plugins (WPML, Polylang) can attest that it's a pretty terrible editorial experience.
Craft, for example, has (very good) multi-language support out-of-the-box.
Studio24 and W3C probably should have pushed that point rather than accessibility concerns.
The 'eat your own dog food' principle would dictate that the W3C writes their site in plain html + css. The fact that this is not even considered proves the these languages are so incredibly non ergonomic. I know.... it is an often reiterated point, but when it is the site of the W3C it really is very hard not to notice this....
How so? W3C is also involved in standardizing the DOM interface to html. JS is equally their own dogfood (in the age of whatwg its debatable whether any of this other than maybe css is really their dogfood anymore)
I don't see how the w3c establishing a rule set would mean they would code it by hand, can you provide more details as to why the should, and not use a CMS that produces compliant code?
Because they edited and published the HTML spec with lots of examples portraying HTML as an authoring language. If W3C actually does intend to publish further HTML specs based on WHATWG (which they haven't done since 2017), they should consider injecting their own navi/styles into the bikeshed-generated WHATWG material as part of their CMS setup (and they have tons of static HTML anyway).
W3C and WHATWG signed and MOU last year to work together on documents and specs.
Regardless, to define a language it only makes sense to author the specification from the language perspective. From what I've read, and honestly it's been many years since I have read their stuff, most of the authoring docs have a section in them talking about applications and editors creating the documents.
They're still using HTML and CSS, all websites do. It's the dynamic and generated nature of web applications that makes static HTML and CSS not useful on it's own. You could argue the right choice then is a static site generator, but the difference between static site generation and dynamic site generation is really just when you do the generating work.
W3C, at least on their current site, have hardly any dynamic content beyond aggregated news/event snippets on the front page and maybe charter status pages and roadmaps published once every two years or so. Their collaboration workflow for spec text runs on github. They have gateways/integrations to external services (HTML validator) and a lot of static HTML.
There are two camps withing the HTML/CSS community, one that thinks HTML and CSS should be hand written (with the help of a static site generator), the other one thinks that HTML and CSS should always be generated by a design tool like Frontpage, CMS, Wordpress/Gutenberg et.al.
The biggest issue I have with Gutenberg is the typing latency when you are editing a standard 6 paragraph blog post with 2-3 images. On my laptop I can actually see the latency while typing. Characters appear on the screen seconds after typing them like a slow motion reveal frequently used in school PowerPoint presentation by kids to to look cool.
It's maddening to see this much latency while typing a bunch of plain text on a machine than can comfortably handle big Android Studio projects without any such latency issues. Modern web really is a dumpster fire.
I don't think it's shameful, though just niaeve to expect it to work well.
To be fair I do think it is difficult to make a choice until you make an app of size you will not know about those edge cases.
My agency worked on a site which had ~1M+ pages and the backend became unusable (entries table was dead), task management had to be bespoke, search had to be dealt with by Elasticsearch amongst other things.
Can validate. Craft is amazing, by far my favorite CMS, but if you have a true enterprise site and need to do any changes to fields, it's a nightmare. Crashes the site constantly, only solution is to boost RAM.
Hey all: we build a ton of websites in Craft and I've presented technical topics at their yearly conferences before. Happy to answer any technical or other questions about Craft here or via email, if anyone is curious to learn more.
In my opinion it's a great CMS and a good choice for the W3C site. It's content author-friendly, is also very developer-friendly and supports modern development/SDLC processes. You'll be pleasantly surprised if your only PHP-based CMS experience is with other CMSes.
It’s been good for our clients! WYSIWYG is a required feature for many of them and I’ve found Redactor better than a lot of alternatives we’ve tried. What issues do you have?
One thing that’s helped us is making heavy use of Craft’s matrix blocks. That keeps a lot of styling and inline elements out of the WYSIWYG itself. Then we can turn off a lot of the WYSIWYG buttons/features and keep it simple.
Is there an open source CMS that people would recommended for use with a static website generator for large websites? Netlify CMS is interesting for example and I love how content changes are versioned in Git.
I like static website generation but don't want to get locked into a proprietary CMS platform.
> and I love how content changes are versioned in Git
Developers love themselves some Git, but that's probably not the best content workflow tool for people who will write copy which actually accomplishes the goals of the site (like making sales.) Why do developers in this thread act as if it's going to be developers writing the content?
> Developers love themselves some Git, but that's probably not the best content workflow tool for people who will write copy which actually accomplishes the goals of the site (like making sales.) Why do developers in this thread act as if it's going to be developers writing the content?
I never said to expose sales people to Git. Have you tried Netlify CMS? All it's doing is giving non-technical users a pretty frontend to edit posts/pages that are stored as Markdown files on GitHub, so it's user-friendly + developer friendly. Check out the video: https://www.netlifycms.org/
Migrating static sites where the content + theme are all stored in Git is a dream compared to WordPress. A lot of WordPress sites aren't even under source control (with automatic security updates live updating the CMS code with no diffs if something goes wrong or it gets hacked), and because some state is stored in the database and other state stored is in the file system, it makes migrations, upgrades and rollbacks overly complicated.
You could use WordPress as a headless CMS, but you've still got to have a plan for how you're going to backups, rollbacks and deploys for content + custom editor features.
You mentioned that content changes are versioned in Git using the Netlify workflow. Why would that be useful if not for being part of an editor workflow? If it's not part of the editor workflow, is it part of the development workflow? What are we comparing this to? versioning in Google Docs? MySQL? How is it something I should "love?"
> Migrating static sites where the content + theme are all stored in Git is a dream compared to WordPress.
Wordpress (and similar) site migration has been a well solved problem for quite some time. Sure, there might be easier ways to do migration but that's a long ways down my list of things to worry about when choosing my tooling. Ease of migration isn't much of a consideration.
> A lot of WordPress sites aren't even under source control...
A lot of Wordpress sites are a dumpster fire actively attacking the internet. That's not the sites I build and manage. I'll create static websites for my own usage, but not for buyers of my services.
Any headless CMS service (as opposed to self hosted) is really just an option of interfaces on the market. Of the things which matter to buyers, that interface is everything on the back-end (the site as a whole has more important goals.) The buyer doesn't care about ease of migration, how content is stored, etc. Only developers care about these things. So, let's talk about what buyers want, not developers.
If a X headless CMS service can provide the best UI for the buyer, then that's what everyone should default to. If not, then all other bullet points don't matter.
All state is stored in Git and Netlify CMS is just a client-side JS script that talks directly to GitHub. It's an interesting approach that suits some projects. Don't read into this comment more than that.
Drupal has modernized (its highly modular with OO PHP) and is an excellent enterprise CMS. It can be implemented as the headless backend: https://www.gatsbyjs.com/guides/drupal/
Currently using Drupal 8 with a decoupled Next.js frontend .. works very well. Seem less upgrade to Drupal 9. Advanced CMS editing tools, moderation tools, media management, componentised content modules, content library, all content exposed via JSON:API, multilingual by default .. built on Symfony.
To say it's more complex than WP is true .. but to completely discount it, is foolish.
Does Gatsby build fast enough for a large site though? I find their business model strange if I'm understanding it correctly - faster builds are a paid feature.
I also don't understand the hype. I think it's just good marketing, people don't know the alternatives, and it uses React.
I usually side with Hugo because it's so fast and simple to get running. I don't love the template language but the majority of sites don't need complex template logic anyway.
Fast enough depends on your needs. I work on a Gatsby site that builds ~9k pages in ~9 minutes in AWS CodeBuild. We're looking forward to implementing incremental builds at some point, but our current build time is acceptable.
I see Gatsby similar to Django in that it has "batteries included" for building a modern interactive site. It suits our needs quite well and I'm really happy with it.
For what it's worth, a quick test of Hugo with 10K posts with a minimal theme takes 40 seconds to build. Speed isn't everything but x10 faster is nice.
This sounds like the hype I mentioned earlier if I'm honest. I'd rather just use Hugo today and know most small sites I make are going to build in less than a second without having to pay extra.
PHP scales fine especially serving mostly static content. Not sure why that's even being used as an argument against choosing WordPress. There are valid concerns, this isn't one of them.
Well, you're going to need apache or nginx, then you're going to need a php cgi or fpm. You still need somewhere to store your data so now you get a database layer that has to scale too. Don't forget your op cache. Oh and you probably need some kind of shared filesystem too, so there's that.
If any of those pieces break, get overloaded or have a security bug, your website is down. When your website isn't getting traffic, you still get to pay for those things, maintain them and perform regular updates.
With a static site you have files that get served by whatever. As long as you are serving files you are up. You should update your nginx or whatever on occasion. Scalability is stupidly horizontal.
WP is php, and it tends to take a ton of plugins of various quality, vendors and support to get it to where you want it. Last I looked at it, it didn’t even support multi-language out of the box.
That’s a feature not a bug. >90% of the websites don’t care about multi-language. Why should their CMS be more complex just to carter the rest? Plugins nicely separate the concern and let the authors of the plugins get paid for their efforts.
Typical American viewpoint that is. In European markets it is probably the inverse, most sites need multi language support. For a contentmanagement system I find it pretty poor to be missing this.
Indeed, I thought for a moment about Switzerland, that might have one of the highest rate of multilingual websites at least in Europe.
I wasn’t able to find what fraction of the Internet sites are multilingual but would be curious what’s your estimate. I still would be surprised if it is >10%. Maybe more if you weight by traffic but that is not the relevant metric here.
The plug-in approach has another advantage: there are several reasonable approaches to a multilingual site, i.e. you can have a default language if a translation is not available. Or rather show nothing. You may want to force a translation of each page. How do you track the translation of changes in one language, etc.
By picking/adjusting a plug-in you get the behavior you want instead of a one approach satisfies nobody default solution.
* first of all I think that not translating web content is leaving big chunks of potential markets by the wayside. the whole point of the web is that people are able to find you and your offerings worldwide - maybe they could be a fit in places you didn’t expect? [1]
* I’ve dealt with these WP multilingual plugins and they were all atrocious (see my first comment). Nowadays, if I have a core set of requirements, and a piece of software only offers that set through plugins, I will not consider it anymore. Plugins are fine for nice-to-haves, but not for must-haves. It’s a recipy for a maintainability disaster.
"Various quality" is a very mild expression for it already.
Add to that the tendencies of many to use PHP directly as a way of cutting pages into non-modular non-composable pieces, that can only be concattenated instead of used everywhere, and add to that a mix of PHP, HTML, CSS and JS in the same file ... well you are set up for a catastrophe in terms of maintainability, which maps closely to how most plugins for WP are written.
I don't now if there are numbers for static sites on there, but my guess is that those numbers don't come close to Wordpress, especially for the top million sites.
> Many CMSs are used to produce static sites; WordPress included.
So, which is it? Don't use Wordpress because it's PHP based and doesn't scale? Or Wordpress headless is okay because the front-end is static?
Static sites are the future, not Wordpress? Or Wordpress is still going to be a part of the headless market because the CMS supports that functionality?
Unless there's dynamic content, the pages are going to be cached anyway. I'm not sure static would buy anything much really. So few would be hitting the actual site.
> The use of React complicates front-end build. We have very talented front-end developers, however, they are not React experts - nor should they need to be.
> I believe front-end should be built as standards-compliant HTML/CSS with JavaScript used to enrich functionality where necessary and appropriate.
This is what worries me about React (and with other front end frameworks in general). I'm writing this as someone who choose Vue for their latest project.
Web pages started off being documents - electronic versions of printed typeset pages - and could often look very beautiful. A lot of React pages seem, to me, to look like a collection of components - like modern versions of VB forms - facebook/twitter spring to mind etc.
There are a lot of very good HTML and CSS 'coders' that aren't developers, they come from more of a design background. Are they being disenfranchised by the modern frameworks? Will we end up making the web look less beautiful?
I use Wordpress extensively and I find the whole Gutenberg switch to be absolutely atrocious. From the design to the technical implementation.
And it is also received as such. The classic editor has been downloaded millions of times.
What worries me most is that the developers haven’t responded one bit to these issues (if I read the relevant issues) and it solves no problems.
It feels a lot like the technology du jour was picked and molded in a preconceived idea of a page builder. Forgoing a lot of that professional page builder plugins do great and much better already.
So the absolutely silence on these criticisms is what worries me most.
And yes, using react feels like a bad fit, it creates another layer where none needs to be, like the article stresses.
True story: I opened a couple issue tickets on Github for Gutenberg. Both very real and legit. To say the reactions from that team were hostile is an understatement. I've since promised myself to not try to help. It's not worth it.
I have a self-hosted blog with Wordpress and the change from classic editor to Gutenberg was like re-educating yourself to writing with your weak hand. Yuck.
In the meantime, I got used to it, because I did not want to fight the development direction that was seemingly set in stone. And, to be just, Gutenberg got better. Nowadays you can pull most things off in it without thinking twice.
But once you start horsing around with something untypical in mind, woe is you.
Before Wordpress my go to CMS was Drupal, but it suffered from the same problems. It took 3 years to even port the most standard and most used plugins to the new version.
I think its a bad sign if there is such a massive opposition to the direction and it is disregarded completely.
And like you said, once you start using atypical situations, it becomes a unnecessary complicated affair. Luckily you can dismiss Gutenberg, thats the only upside.
If WP ever (probably not) gets away from the "everything is a post" approach, none of the gazillion plugins will ever work again. WP only gives you things, if you use its classes, so the tendency of its users is to make everything a post, but a post is (surprisingly ha!) not the correct abstraction for everything. It is in fact a very bad design.
Many of the often touted so high number of users of WP are however, rather casual want to host a blog kind of users, who really don't need much more than posts and plugins, which take care of implementing stuff on an unfitting abstraction, ehich remains invisible to the casual user.
I think this is an easy misconception to get from the article. But react is just used for instances of the editor inside of WordPress admin because editors are extraordinarily dynamic and interactive. I would suggest that editors are one of the best examples of things that should be SPAs!
Any “front end” HTML is generated via PHP. No relation to react :) indeed, most of the accessibility issues with WordPress are in gutenberg itself, not the front end content. (When I say front end, I mean stuff you would see browsing the site as a normal user.)
> are they being disenfranchised by the modern frameworks?
Though this isn’t exactly your point, this is brought up a lot in relation to gutenberg. The reason gutenberg needs something like react is because it needs to be a lot more powerful than a simple text form. And it needs to be a lot more powerful because many WordPress users struggled to accomplish anything other than basic text formatting in the classic editor. Gutenberg is moving a lot of disparate concepts under the same roof now, and it provides / will provide a uniform, standard way for editing many parts of your site.
While yes, this is a technology shift for developers (you need to be a lot more comfortable with JS to build tools for the editor), it’s still a big win for users who aren’t developers as they can accomplish much more with less effort and knowledge. Sure, some things might be a little more effort now than they were previously due to rough spots in the experience, but overall it unlocks a lot more functionality in the long run.
> Gutenberg is moving a lot of disparate concepts under the same roof now, and it provides / will provide a uniform, standard way for editing many parts of your site.
yeah, and i hope it'll make the myriad mutually-incompatible page builder plugins die out. yuck. [1]
i'm a bit torn about GB... the goal of allowing tree-ish structures that map to nested DOM elements is great (and something TinyMCE, the old editor, didn't really allow). but the editor needs work. right now, it simultaneously goes too far (everything is a block => editing simple linear text is annoying) and not far enough (editing nodes and moving them around still feels clunky).
and i wish they'd gone with "everything is a node" instead. right now, inline elements are very much second-class citizens – they have to be "formats" within a RichText, a separate non-block thing [2]. they work fine for bold, italics and even links, but they're much more limited than blocks (can't remember specifics now though)
---
[1] if i sound bitter... i am, having had to untangle messes people made with some weird page builder thingy and work with themes that come with their own bespoke page builders (!)
[2] seriously, npmjs.com/@wordpress/rich-text is a package independent from Gutenberg (though it lives in the same monorepo)
Modern frameworks like React are powerful, but complicated enough to put them way out of reach of anyone not a developer.
The high and low-ends of web frameworks seems to be splitting further apart - complicated but powerful, or simple but restricted like Squarespace.
There’s a lot of talk here and other places about how the modern web is boring and it’s become a monoculture, but there’s not a lot of talk about how it’s become so much harder for a non-coder, or at least a committed amateur to make powerful websites themselves.
I wonder if you could blend the two approaches. Let people think in terms of documents that feel static. But wrap them in a navigation system that benefits from components.
The trend is always to make every element of a document a component which is great for technical efficiency but removes a lot of flexibility. A document is still a good abstraction.
Never mind - their contributing.md document makes clear it isn't a FOSS project.
---------------
I wasn't familiar with Craft. Looking at it they seem to have their own license and it seems pretty restrictive. Can anyone point to any existing discussions about the implications of the license and if it is truly open source?
I understand FOSS projects that have some kind of payment option, but I don't understand how the code can be available but there is no way to run it without paying for it. The language of the license is also rather informal. As a layman it has an appeal to me but at the same time I'm wondering how some of those things are defined.
> Never mind - their contributing.md document makes clear it isn't a FOSS project.
Where did you end up finding this information? How did you not see the "pricing" link in the navigation at their website? Or did you not look at their website? If you're having to pay for the software, then you probably don't need to dig much further to see that it's not FOSS. You seem to be making this more complicated than it actually is.
I went to the repo and read the license. The article made me think it was sold but open. Lots of FOSS software has purchase options. That alone doesn't indicate if something is foss or not. The license confused me, as I stated but they have another file "Contributing.md" that explicitly states it is not a FOSS license. Now I just wonder why anyone would work for them for free.
The post linked here has the section "The question of open source" and it states "While their source code is open, they do have commercial licenses and cost money (though a modest sum)." That is where they link to the github repo. I'd say all that wording also muddies the waters. I guess it's "open" in the sense that you can read it. But I don't consider that to be open. I guess they are drawing a distinction between FOSS and "open". I can't argue that but I still think the way it's written is confusing. (or maybe I'm just not current on how these terms are being more commonly used.)
I'm not sure it's so cut and dry. We tend to reduce things down to binary thinking, perhaps by training.
There do exist several prominent FOSS projects that also have pricing pages. They usually charge for hosted/managed deployments of their project or binary distributions (e.g. compile it yourself for free). While I believe it poses a conflict-of-interest, there are also a number of FOSS projects with pricing pages for "enterprise" features.
This is my experience as well. Any tickets related to a11y, PHP code clean up/modernization, or security don't get the love JS-heavy tickets get.
Thumbs up to people as Sergey who triage issues and brought up some of the tickets. Drupal is sort of following the same way; if it's not related to the latest Drupal version or related to media uploads, editing experience, etc, those issues are lucky to picked up.
> Drupal also has this complexity issue which makes developing sites harder than it needs to be, and is why we didn’t consider that platform either. I’ve talked to other agencies who have decided to drop Drupal due to its complexity.
I am sure I’m biased as I’ve spent a lot of time in Drupal. There are certainly some oddities wrt Drupal’s frontend but dismissing it entirely on that seems silly. Especially when it does a decent job of ticking some of their other boxes (e.g accessibility, open source, headless tooling).
Technical director of a LAMP stack creative agency here. This write-up almost exactly mirrors our experiences across Wordpress, Drupal and Craft. I think they've made an excellent choice.
If anyone from studio24 is reading this we've developed a Craft plugin for Varnish purging etc that we're using across multiple production deployments: https://github.com/Whitespacers/Citrus
Given W3C's emphasis on URLs as a permanent reference to content, I'm surprised they use a CMS at all. My next blog-ish project will be static HTML compiled from markdown. When I move on, so long as I keep paying for hosting, it'll remain accessible at the original URL.
I don't know of a proper CMS that behaves this way, but I confess I haven't investigated the problem since it's not a pressing one for me right now.
I kind of feel for these guys. This kind of project is the worst (massive, content/maintenance-heavy website with many admin users .. urghh). And given that they are likely to be heavily scrutinized on whatever direction they take, I mean it's pretty much lose lose (I really hope they are killer designers). That said, reading the blog post took me back to 2013 .. symfony/PHP? If I was the W3C product manager I really wouldn't be confident with the technical approach. It reeks of confusion, and appears to be relying on others for technical leadership. The W3C should be leading the way here. The approach should be something you write about and people go wow! They nailed it. At the moment it sounds like someone's googled accessibility and is in the process of pushing high-contrast lemons through the orange peeler.
I am almost sure this is not the case, but the article leave me with the impression that the author is not up to latest trends and paradigms. React, or any other modern front end framework, is not equivalent to SPA.
Am I the only one who hates the whole concept of a CMS? I much prefer just working HTML changes into a dev cycle. CMS encourages marketing and sales people to wreak havoc on your web experience. Working in HTML changes into the dev process also helps keep the engineering team aligned with the business/marketing strategy. I use Middleman for generating static html websites and it works great. I would love to see the concept of a webmaster come back.
There’s real value in allowing people with no HTML/CSS knowledge to write content. I also don’t see how writing and publishing content would wreak havoc on someone’s web experience, or am I missing something?
I think all CMS I have used (aside for one I built of course)
Are annoying, and getting pixel perfect results is challenging. I presume that will become easier when we move to headless CMS.
The reason I like he and that often insists on it ,is because my team finds it both tedious and boring to have to make constant changes every time some in marking or legal or content writers which to ”change a few things” It is also far cheaper for them to so it themselves, and my team can can focus on on more important things. And yes there will be times when a developer needs to make changes still.
The company I am at now sends” superusers to pretty tremendously comprehensive training on how to use the CMS tool. Usually, one or two people from each department are chosen to be superusers.
That all works out much better than my team had to do the training. We were frankly not very good at it and it is far cheaper to outsource that for us.
All of that means that our team get magnitudes fewer phone calls or tickets about how to do X or Y since the go to the super users for help. If the superusers are not about to figure it out he or she contacts us.
This is awesome because when the superusers contacts us she can give a much more insightful description that a newbie employee with limited exposure to CMS's. To our tools. And often not that familiar with computers.
People often talk about CMS being too slow in production. We have very few problems with that.
We took a lot of time evaluating and testing the tools we use both for performance and for ease of expanding extending and customizing and developing And superusers how we believe our superusers will like the interface. And yes of course we had focus groups with potential superusers we're they could give us feedback.
I swear nobody making comments on this item has used the software in question.
With both Craft and Wordpress you can do EXACTLY the same output as you would with a static HTML site.
How does a headless CMS solve a problem which you apparently know nothing about?
Are you creating custom content management systems without knowing how the most popular options work? That's not to say you have to know how these work, but I would be skeptical of hiring anyone who didn't know the capabilities of what's already on the market.
> I much prefer just working HTML changes into a dev cycle.
Have you worked with either Wordpress or Craft? With each of these, you control the HTML which gets generated via templates which are files on disk which can be checked into your repository.
The content management element of the CMS allows users to log into the control panel to manage the content. This experience is controlled by the developer. In some cases, you might constrain editing to a simple WYSIWYG experience which is similar to support you might expect from Markdown. In other cases, a developer might allow blocks of HTML which could even include styling.
How would you expect "marketing and sales people" to work with Middleman or any other static site generator?
I think that love it or hate it, the CMS is a major value add to an organisation. They probably don't want to waste your time (or theirs for that matter) having to go back and forth between their content team and the dev just so they can create/update/delete a page.
Please note this solution would not be reliant on JavaScript
Please choose it then, because it would be a sad day for the Web indeed if the W3C's site turned into a horrible JS SPA like so many others unfortunately have. The W3C's collection of standards is an important and prominent example of the document-centric-web, and keeping them as static pages that can be viewed with anything down to a text browser is definitely important for accessibility.
> What options do we have in Python world if someone wants to migrate CMS based sites built using WordPress ?
It is more of an equivalent to Drupal than WP in terms of scope, but Plone[0] has been used on a lot of sites, and has ticked all of the boxes mentioned (i18n, a11y, etc.) for a very long time. The underlying Zope web application framework isn't particularly popular these days, but is a solid (if somewhat idiosyncratic) foundation. At 22 years old, you could call Zope the emacs of Python web frameworks.
There are also a variety of CMSs based on Django or Flask, but I'm less familiar with those.
Wagtail - https://wagtail.io - is the most popular Python CMS. It runs sites for NASA, Google, Mozilla, NHS.uk. It's open source and under very active development.
Massive props to Studio 24 for showing their working in public on all of this. It is amazing to see. More large scale projects of this kind should do this sort of thing.
Its really thrilling to see someone think technical decisions out loud. So keep it up, despite what I am about to type!
There are a couple of interesting things in this article.
1. It is absolutely remarkable they got 15 days to rather requirements and choose a CMS. Having worked in a couple of agencies, this is a lot of time, which is to the good W3C paid for it.
2.
> We have very talented front-end developers, however, they are not React experts - nor should they need to be. I believe front-end should be built as standards-compliant HTML/CSS with JavaScript used to enrich functionality where necessary and appropriate.
It makes a lot of sense for websites to be written in HTML/CSS in this progressively enhanced way, but does it make sense for complex user interfaces like any WYSIWYG editor?
Even the Classic Editor basically dropped probably thousands of lines of (actually third party) Javascript into the mix in the form of TinyMCE.
3.
> We won’t stop trying though and plan to do more R&D with Gutenberg in the future. The W3C project, however, did not feel like the right place to do this. On a project as wide-ranging as this one, development time does become a factor.
This is about agency and project risk which is entirely fair enough. However, what is slightly strange, if risk of delivery due to unfamilar technology is a factor, is that the project then goes onto make two other decisions.
- Use Craft
- "We are currently considering a Headless CMS option for front-end page delivery"
It is unclear from this piece if they have much experience using Craft, but my project manager alarm bells are ringing a bit when a team is intending to "deliver project in technology they have no internal expertise in".
Of course, Craft is by all accounts excellent, but could be a source of problems. The judgement is between the technical difficulty of using Gutenberg and learning a whole new CMS as a developer.
Further: the headless CMS option.
Do the team have the experience of doing this? Where I currently work we are actually considering moving back from headless CMS because the current leader in the field, Gatsby, has some pretty major downsides.
One of the reasons is that site build time is terrifically slow. Their approach seems to be roll our own headless thing with Symfony which will presumably do calls in real time. Symfony is very full-featured, but this seems like rolling your own headless framework - who is going to maintain it?
Of course it could be very simple, but launching a project in: an unknown CMS, with an unknown way of doing a website, seems a strange move when one object seems to be reduce technical risk.
What if you want a cdn outcome which doesn't drive to an sql backend?
I've yet to experience wp consciously without it making me wince. I know a lot of former print press is using it, so the for profit sector likes it. That does not axiomatically make it best of breed.
Being php is also not axiomatically worst of breed. The questions are decoupled really.
1) is wp still php
2) is wp best of breed.
3) if you want static site through cdn is wp the best fit?
Changing from PHP wouldn't change WordPress, it's general engineering approach hasn't changed since it gained popularity a decade or more ago.
Except for Gutenberg, which could be characterized as an admin facing HTML editor powered by React components but with an interfacing layer between Gutenberg and React, so only some of your React knowledge applies. It gets saved as HTML. The actual served content is still served as PHP generated HTML. React isn't involved in the client workflow.
All of this javascript code is of course bootstrapped and defined by PHP hooks including dependencies, and redefined again in the JS, so you're constantly diving between PHP and JS just to set up the JS.
Now to work on WordPress idiomatically you need a whole new set of skills that introduce a whole new slew of problems. So it's not best practice or well engineered PHP, and it's not best practice or idiomatic React. The docs for Gutenberg are incomplete, so no luck there either.
Another platform that failed in this same way was Magento 2. They want to use the Cool Kids Tooling, but they want to do it their way, so there's all this Bullshit™ inbetween and you get a hamfisted barely documented Frankenstein's monster. The third party tooling docs can't help you because of the proprietary integration making much of it no longer apply, and all the novel domain knowledge to get it to work is floating around in Stackoverflow threads and github issue tickets.
I believed there are multiple versions including paid support models for commercial use. I wanted to know if the one(s) you buy are based off the same code as ones you run yourself. Not all things are dogfooded.
> I've yet to experience wp consciously without it making me wince.
You might be surprised to hear that likely a third of the websites you visit run WordPress. [0] So it’s not really constrained to just former print, it’s basically any site that needs to have a lot of content.
I think it can be argued that WordPress is the best CMS out there because you can really make it do just about anything you need if you know PHP. (And the built in extendability systems are pretty powerful.) It’s powerful, fast, flexible, etc.
The real problem with WordPress for most users is that it’s difficult to set up a nice site unless you either have a perfect theme or you take the time to figure everything out.
This is why Gutenberg is so important for WordPress: it’s basically reimagining the site in terms of “blocks” so that we can eventually have a unified editing experience for all parts of the site. Instead of digging through a ton of different settings and customizer and appearance pages, it’ll mostly be in a unified UI. So making that powerful and easy to use is a big project at the moment.
These are most of the time not the good questions.
Can WordPress be deployed by anybody ? Yes, there's a ton of PHP hosting providers and they all have a one-click install WordPress button.
Does WordPress enable authors and owners to update their website content and the design with a WYSIWYG interface ? Yes and yes (see divi, beaver, etc.).
Not a WP fan (although I've built large scale sites professionally) but the arguments regarding the frontend are kinda BS. What does Gutenberg have to do with the entire frontend layout? Gutenberg can still be used just for the main content region, not surrounding blocks. Not really a "talented" team after all.
Plus, UK dev companies tend to be biased towards Craft these days cause (guess why) it's also UK based.
I also wonder how they got Statamic in the list (probably to dilute the argument for the need for a commercial CMS) and not the 2nd largest CMS in the world (Joomla).
I started my web development career with Joomla, around 2008. At that time it seemed somewhat convoluted -- having arbitrary levels of hierarchy to define a basic content model and redundant concepts for extending core functionality (i.e. what WordPress calls plugins and Drupal calls modules). Has Joomla managed to simplify it's architecture in the past 12-or-so years?
Also, open-source CMSs are lacking for non-proprietary drag-and-drop layout builders (such as can be seen in Wix). Does Joomla have core or a fully open-source extension for drag-and-drop page building?
> Plus, UK dev companies tend to be biased towards Craft these days...
This seems a tad hyperbolic surely? For every Craft CMS site built in the UK, my guess is that there are 200+ WordPress sites built. Is there a particular niche that you are seeing this trend in - enterprise sites?
For example, there have been major interfaces changes on a regular basis, each of which we have to spend time walking our clients through. One change - defaulting to full-screen editing, which hides the menus and loses a lot of context that editors were used to - was pushed through at the last minute of a release cycle with a personal intervention from Matt Mullenweg. That meant that suddenly editors were confronted with an unfamiliar editing interface even if they were already registered and hadn't changed anything themselves, rather than a dismissible tooltip letting existing editors know that they could use a new full-screen editing interface. That seemingly arbitrary and personal style of project management really doesn't foster confidence that things are being thought through carefully.
I know from personal experience that you need to keep up momentum in a development project otherwise things stagnate, but so far the development of Gutenberg has been very much "move fast and break things" which would feel appropriate for a beta, but not for the default editing experience.
I think Gutenberg may well turn out to be really good - our clients do prefer it over the classic editor once we have it under control - but the way this has been managed has lost a lot of good will on our part as an agency and I've been actively looking at other CMSes like Craft as a result.