On not choosing WordPress for the W3C redesign project

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.

lwhi8• 6 years ago

The argument put forward by this agency, doesn't actually hold much weight.

Feels more like their choice was made to fit with the agency capability.

darekkay2• 6 years ago

Not choosing and inaccessible platform was the right thing to do. Hopefully this will make Automattic reconsider their priorities regarding web accessibility.

LordAtlas8• 6 years ago

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!"

cheeze• 6 years ago

Ironic that the link looks kinda... terrible.

I can read it, but it's not pleasant at all.

LordAtlas8• 6 years ago

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.

411111111111111• 6 years ago

Design is entirely broken in Firefox on android... Half the header is cut off etc

retox• 6 years ago

The entire first screen on a 1080 monitor is made of broken looking headers and an outrageously large title. Just garbage.

Avamander• 6 years ago

Gotta love turning zoom to 67%.

cpach• 6 years ago

“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).”

wat

darekkay2• 6 years ago

There's a link to the RSS Club in the next sentence. I broke the "second rule of RSS Club", because I feel accessibility advocacy is more important.

stoolpigeon3• 6 years ago

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.

gexla11• 6 years ago

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.

brylie2• 6 years ago

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.

stoolpigeon3• 6 years ago

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.)

ponker2• 6 years ago

The W3C has to make accessibility priority #1 — commercial entities usually deprioritize accessibility so the W3C must lead by example.

ognarb• 6 years ago

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.

ponker2• 6 years ago

The W3C’s core mission is web standards, not FOSS. They are right to prioritize standards #1 just like the FSF website must be FOSS.

dgellow• 6 years ago

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.

bad_user• 6 years ago

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.

oever• 6 years ago

They also chose the proprietary cloud service GitHub for managing their core workflow.

digitalengineer2• 6 years ago

Does anyone know why Drupal wasn’t considered?

stoolpigeon3• 6 years ago

The article says due to front end complexity. It's in the last sentence of the section with that header.

digitalengineer2• 6 years ago

Weird. I first somehow read a shorter version of the article in the HN iOS app.

lwhi8• 6 years ago

I'd suggest using Drupal with a static generation tool, headless with Next.JS or Gatsby.

cdubzzz• 6 years ago

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).

ggm4• 6 years ago

Is wp still php?

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?

johnchristopher2• 6 years ago

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.).

ggm4• 6 years ago

Is that a good fit for w3c against all the other choices?

ehnto2• 6 years ago

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.

gexla11• 6 years ago

How can you comment so negatively on WP when you know so little about it?

ggm4• 6 years ago

Because I've had to install it, maintain it, and produce contents for it, and never enjoyed it.

noahtallen2• 6 years ago

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.

- 0: https://w3techs.com/technologies/details/cm-wordpress

sofixa• 6 years ago

No, the real problem with WordPress is security and code quality of plugins, of which you require a lot.

systemvoltage• 6 years ago

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.

slim• 6 years ago

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

cjfd• 6 years ago

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....

Meph5042• 6 years ago

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?

tannhaeuser3• 6 years ago

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).

ehnto2• 6 years ago

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.

tannhaeuser3• 6 years ago

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.

bawolff• 6 years ago

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)

zwarag• 6 years ago

IMO they are doing only HTML+CSS.

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.

z3t4• 6 years ago

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.

dmurray• 6 years ago

There's really no one who thinks both use cases are important?

userbinator• 6 years ago

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.

vorpalhex2• 6 years ago

Glad they realized the issues of Wordpress but a shame they went with proprietary nonsense with a faux license.

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.

m_mueller3• 6 years ago

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.

lixtra2• 6 years ago

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.

zelphirkalt2• 6 years ago

"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.

ohashi• 6 years ago

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.

vorpalhex2• 6 years ago

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.

chiefalchemist10• 6 years ago

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.

out_of_protocol• 6 years ago

Having 100% bulletproof site is huge (e.g. you can host static site on s3+cloudfront) vs worrying to be not-hacked, not-overloaded etc

gexla11• 6 years ago

A php based platform has a lot of negatives for scalability

This is an outdated view of how websites are developed today.

Using a cms to generate static content is much more simple, scalable and cheaper.

If the market agreed with you, then this would be the dominant method for creating websites today. You aren't smarter than the market.

Maybe you aren't looking at the right variables which go into your calculation for "more simple, scalable and cheaper."

lwhi8• 6 years ago

Static generation is common approach, and has gained a lot of popularity in recent years.

helsinkiandrew• 6 years ago

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?

prox2• 6 years ago

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.

inglor_cz• 6 years ago

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.

LordAtlas8• 6 years ago

Because Matt Mullenweg's ego trumps all design considerations.

chiefalchemist10• 6 years ago

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.

mattkevan• 6 years ago

Yes, basically.

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.

noahtallen2• 6 years ago

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.

uryga• 6 years ago

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)

7952• 6 years ago

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.

fevangelou4• 6 years ago

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).

All in all a pointless marketing article.

brylie2• 6 years ago

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?

fevangelou4• 6 years ago

Joomla has several d'n'd content builders nowadays.

As for the separation of types of extensions, that's actually a good thing for many practical reasons.

In the end, it depends on what you're building...

3stripe• 6 years ago

Just to correct one of your points: Craft was created by Pixel & Tonic who are a US company, not UK based.

fevangelou4• 6 years ago

Indeed, mea culpa.

tweetle_beetle• 6 years ago

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?

fevangelou4• 6 years ago

My mistake on its origin. Indeed though it's used on some high profile (albeit not high traffic) sites by well known UK agencies.

ComodoHacker• 6 years ago

Huge credit to Craft team! A proprietaty product being chosen for so heavily open-source leaning project is a big win.

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• 6 years ago

Open source is discriminated against, not the other way around.

sradman• 6 years ago

TL;DR: The W3C Redesign Project has selected Craft CMS over Wordpress.

From the CMS strategy and requirements document [1]:

At a minimum, it’s expected W3C will have 10-30 people editing content on a new CMS, though this may be more.

Why is the CMS used by the internal marketing team even under consideration for a web site redesign? This has the feel of busy work to me.

[1] https://w3c.studio24.net/docs/cms-strategy-and-requirements/

gassius• 6 years ago

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.

brailsafe• 6 years ago

Not necessarily equivalent, but usually used for that. Most frontend libraries are good tools for that task, and ok tools for other tasks.

quantummkv• 6 years ago

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.

_7gt4• 6 years ago

WordPress has some serious edge cases, and lots of stale issues in Core, many with patches that just go stale themselves.

If it isn't prioritized by Automattic, it's not getting in.

https://core.trac.wordpress.org/ticket/32101

Ayesh• 6 years ago

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.

somishere• 6 years ago

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.

frereubu2• 6 years ago

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.

chiefalchemist10• 6 years ago

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.

rado2• 6 years ago

Meanwhile, the core lacks: multilingual, CDN support, caching. Essentials.

rmccue4• 6 years ago

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.)

dubcanada3• 6 years ago

I'm obviously in my own bubble, but I don't understand people complaining about WordPress.

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.

katzgrau• 6 years ago

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.

conatus6• 6 years ago

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.

dmje• 6 years ago

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.

XCSme6• 6 years ago

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.

frereubu2• 6 years ago

"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.

pacifika• 6 years ago

https://wpackagist.org/

interestica• 6 years ago

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)

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."

LordAtlas8• 6 years ago

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.

Googling told me it was a bug that had crept back: https://github.com/WordPress/gutenberg/issues/20950

It was fixed again in WP 5.5, but it was agonising working on layouts before that.

trbfred• 6 years ago

Why did they not consider Pimcore? Other parts of their platform seem to be using Symfony too...

Could be either used as "full CMS" or as data source for a downstream static site generator...

tiborsaas• 6 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.

Conan_Kudo• 6 years ago

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.

nicbou2• 6 years ago

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.

seanwilson10• 6 years ago

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.

mobilefriendly• 6 years ago

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/

lwhi8• 6 years ago

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.

chiefalchemist10• 6 years ago

I belive that with GatsbyJS you can your a repo + markdown as a "backend".

seanwilson10• 6 years ago

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.

todotask• 6 years ago

Other than versioning, are there important features we could benefits?

gexla11• 6 years ago

You can use Wordpress as a headless CMS.

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?

seanwilson10• 6 years ago

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.

lovetocode• 6 years ago

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.

pindab0ter• 6 years ago

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?

ThinkBeat• 6 years ago

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.

gexla11• 6 years ago

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.

gexla11• 6 years ago

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?

lwhi8• 6 years ago

This isn't a sensible approach.

We need experts to develop products from a code PoV.

We need experts to create content.

Not many content creators are great developers and visa versa.

chaoticlaw• 6 years ago

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.

seanwilson10• 6 years ago

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.

luckylion2• 6 years ago

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.

rmccue4• 6 years ago

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).

seanwilson10• 6 years ago

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.

XCSme6• 6 years ago

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.

[0] https://codecanyon.net/category/wordpress

dawnerd• 6 years ago

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).

colourgarden2• 6 years ago

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.

colourgarden2• 6 years ago

For reference, here's the list of CMS requirements put together by the team - https://w3c.studio24.net/docs/cms-strategy-and-requirements/

mattweinberg2• 6 years ago

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.

nicbou2• 6 years ago

How's Redactor working for you? I have constant issues with it.

mattweinberg2• 6 years ago

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.

conatus6• 6 years ago

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.

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.

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.

pythonbase• 6 years ago

What options do we have in Python world if someone wants to migrate CMS based sites built using WordPress ?

webmaven• 6 years ago

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.

[0] https://plone.org/

tomd• 6 years ago

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.

paledot• 6 years ago

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.

ollyjackson• 6 years ago

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

On not choosing WordPress for the W3C redesign project

Related Stories