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.
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."
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).”
> 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.
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.
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.
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?
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.
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.
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.
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.
> 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.
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.
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.
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
[+] [-] frereubu|5 years ago|reply
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.
[+] [-] chiefalchemist|5 years ago|reply
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.
[+] [-] dubcanada|5 years ago|reply
WordPress is by far the worst CMS you could possibly use, every other single CMS is better in every capacity.
Let's go through why
- Uses PHP 5 spaghetti code with a handful of garbage event listeners and output buffering
- Has no integration with composer at all
- Doesn't have any form of content types without plugins
- Has no cache, no theming engine, no multi-language, etc etc
- Beyond a media library it has literally no aspects of a "content management system"
It's built for a simple blogging platform and for that purpose Gutenberg is amazing.
Why do people continue to try and shove weirdly hacked on garbage plugins on top of basically a glorified blogging platform is beyond me.
[+] [-] interestica|5 years ago|reply
https://www.advancedcustomfields.com/blog/acf-5-9-1-release/
> " 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."
[+] [-] tripleplay|5 years ago|reply
[deleted]
[+] [-] darekkay|5 years ago|reply
Related write-up: https://adrianroselli.com/2020/09/gutenberg-accessibility-co...
[+] [-] LordAtlas|5 years ago|reply
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!"
[+] [-] cpach|5 years ago|reply
wat
[+] [-] cheeze|5 years ago|reply
I can read it, but it's not pleasant at all.
[+] [-] systemvoltage|5 years ago|reply
Excellent. SPAs have their place in things like Notion and Google Docs. I’m glad they’re not depending on Javascript.
[+] [-] slim|5 years ago|reply
[+] [-] tiborsaas|5 years ago|reply
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.
[+] [-] Conan_Kudo|5 years ago|reply
[+] [-] nicbou|5 years ago|reply
It's also trivial to keep under source control.
My only gripe with Craft is Redactor, which can easily be replaced.
[+] [-] seanwilson|5 years ago|reply
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.
[+] [-] luckylion|5 years ago|reply
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.
[+] [-] XCSme|5 years ago|reply
[0]: https://codecanyon.net/category/wordpress
[+] [-] ognarb|5 years ago|reply
[+] [-] dgellow|5 years ago|reply
[+] [-] ponker|5 years ago|reply
[+] [-] oever|5 years ago|reply
[+] [-] colourgarden|5 years ago|reply
> 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.
[+] [-] cjfd|5 years ago|reply
[+] [-] zwarag|5 years ago|reply
Using a generator to build the HTML+CSS from a headless CMS is exactly how a content-rich site should be build today.
That is because writing content is a different task to structuring and styling a page.
And the end result is still only HTML+CSS.
[+] [-] bawolff|5 years ago|reply
[+] [-] Meph504|5 years ago|reply
[+] [-] ehnto|5 years ago|reply
[+] [-] z3t4|5 years ago|reply
[+] [-] quantummkv|5 years ago|reply
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.
[+] [-] momokoko|5 years ago|reply
As someone that has worked with Craft it has a ton of awful edge cases once you get deep into a project.
Craft absolutely does not scale.
[+] [-] j0ej0ej0e|5 years ago|reply
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.
[+] [-] jawngee|5 years ago|reply
We've done two migrations from Craft for clients. WordPress isn't great, but Craft isn't a panacea either.
[+] [-] lwhi|5 years ago|reply
Feels more like their choice was made to fit with the agency capability.
[+] [-] asddubs|5 years ago|reply
[+] [-] mattweinberg|5 years ago|reply
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.
[+] [-] nicbou|5 years ago|reply
[+] [-] seanwilson|5 years ago|reply
I like static website generation but don't want to get locked into a proprietary CMS platform.
[+] [-] ComodoHacker|5 years ago|reply
I'm bad at analogies, but it's like a minority person took top position in a big company with strong discrimination culture in the XX century.
[+] [-] VadimPR|5 years ago|reply
[+] [-] ponker|5 years ago|reply
[+] [-] vorpalhex|5 years ago|reply
A php based platform has a lot of negatives for scalability. Using a cms to generate static content is much more simple, scalable and cheaper.
Keep it simple.
[+] [-] helsinkiandrew|5 years ago|reply
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?
[+] [-] prox|5 years ago|reply
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.
[+] [-] noahtallen|5 years ago|reply
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.
[+] [-] mattkevan|5 years ago|reply
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.
[+] [-] 7952|5 years ago|reply
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.
[+] [-] stoolpigeon|5 years ago|reply
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.
[+] [-] _7gt4|5 years ago|reply
If it isn't prioritized by Automattic, it's not getting in.
https://core.trac.wordpress.org/ticket/32101
[+] [-] digitalengineer|5 years ago|reply
[+] [-] ollyjackson|5 years ago|reply
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