W3C Drops WordPress from Consideration for Redesign, Narrows CMS Shortlist to Statamic and Craft

The World Wide Web Consortium (W3C), the international standards organization for the web, is redesigning its website and will soon be selecting a new CMS. Although WordPress is already used to manage W3C’s blog and news sections of the website, the organization is open to adopting a new CMS to meet its list of preferences and requirements.

Studio 24, the digital agency selected for the redesign project, narrowed their consideration to three CMS candidates:

  1. Statamic
  2. Craft CMS
  3. WordPress

Studio 24 was aiming to finalize their recommendations in July but found that none of them complied with the W3C’s authoring tool accessibility guidelines. The CMS’s that were better at compliance with the guidelines were not as well suited to the other project requirements.

In the most recent project update posted to the site, Studio 24 reported they have shortlisted two CMS platforms. Coralie Mercier, Head of Marketing and Communications at W3C, confirmed that these include Statamic and Craft CMS.

WordPress was not submitted to the same review process as the Studio 24 team claims to have extensive experience working with it. In the summary of their concerns, Studio 24 cited Gutenberg, accessibility issues, and the fact that the Classic Editor plugin will stop being officially maintained on December 31st, 2021:

First of all, we have concerns about the longevity of WordPress as we use it. WordPress released a new version of their editor in 2018: Gutenberg. We have already rejected the use of Gutenberg in the context of this project due to accessibility issues.

If we choose to do away with Gutenberg now, we cannot go back to it at a later date. This would amount to starting from scratch with the whole CMS setup and theming.

Gutenberg is the future of WordPress. The WordPress core development team keeps pushing it forward and wants to roll it out to all areas of the content management system (navigation, sidebar, options etc.) as opposed to limiting its use to the main content editor as is currently the case.

This means that if we want to use WordPress long term, we will need to circumvent Gutenberg and keep circumventing it for a long time and in more areas of the CMS as time goes by. 

Another major factor in the decision to remove WordPress from consideration was that they found “no elegant solution to content localization and translation.”

Studio 24 also expressed concerns that tools like ACF, Fewbricks, and other plugins might not being maintained for the Classic Editor experience “in the context of a widespread adoption of Gutenberg by users and developers.”

“More generally, we think this push to expand Gutenberg is an indication of WordPress focusing on the requirements of their non-technical user base as opposed to their audience of web developers building custom solutions for their clients.”

It seems that the digital agency W3C selected for the project is less optimistic about the future of Gutenberg and may not have reviewed recent improvements to the overall editing experience since 2018, including those related to accessibility.

Accessibility consultant and WordPress contributor Joe Dolson recently gave an update on Gutenberg accessibility audit at WPCampus 2020 Online. He reported that while there are still challenges remaining, many issues raised in the audit have been addressed across the whole interface and 2/3 of them have been solved. “Overall accessibility of Gutenberg is vastly improved today over what it was at release,” Dolson said.

Unfortunately, Studio 24 didn’t put WordPress through the same content creation and accessibility tests that it used for Statamic and Craft CMS. This may be because they had already planned to use a Classic Editor implementation and didn’t see the necessity of putting Gutenberg through the paces.

These tests involved creating pages with “flexible components” which they referred to as “blocks of layout,” for things like titles, WYSIWYG text input, and videos. It also involved creating a template for news items where all the content input by the user would be displayed (without formatting).

Gutenberg would lend itself well to these uses cases but was not formally tested with the other candidates, due to the team citing their “extensive experience” with WordPress. I would like to see the W3C team revisit Gutenberg for a fair shake against the proprietary CMS’s.

W3C Is Prioritizing Accessibility Over Its Open Source Licensing Preferences

The document outlining the CMS requirements for the project states that “W3C has a strong preference for an open-source license for the CMS platform” as well as “a CMS that is long-lived and easy to maintain.” This preference may be due to the economic benefits of using a stable, widely adopted CMS, or it may be inspired by the undeniable symbiosis between open source and open standards.

“The industry has learned by experience that the only software-related standards to fully achieve [their] goals are those which not only permit but encourage open source implementations. Open source implementations are a quality and honesty check for any open standard that might be implemented in software…”

Open Source Initiative

WordPress is the only one of the three original candidates to be distributed under an OSD-compliant license. (CMS code available on GitHub isn’t the same.)

Using proprietary software to publish the open standards that underpin the web isn’t a good look. While proprietary software makers are certainly capable of implementing open standards, regardless of licensing, there are a myriad of benefits for open standards in the context of open source usage:

“The community of participants working with OSS may promote open debate resulting in an increased recognition of the benefits of various solutions and such debate may accelerate the adoption of solutions that are popular among the OSS participants. These characteristics of OSS support evolution of robust solutions are often a significant boost to the market adoption of open standards, in addition to the customer-driven incentives for interoperability and open standards.”

International Journal of Software Engineering & Applications

Although both Craft CMS and Statamic have their code bases available on GitHub, they share similarly restrictive licensing models. The Craft CMS contributing document states:

Craft isn’t FOSS
Let’s get one thing out of the way: Craft CMS is proprietary software. Everything in this repo, including community-contributed code, is the property of Pixel & Tonic.

That comes with some limitations on what you can do with the code:

– You can’t change anything related to licensing, purchasing, edition/feature-targeting, or anything else that could mess with our alcohol budget.
– You can’t publicly maintain a long-term fork of Craft. There is only One True Craft.

Statamic’s contributing docs have similar restrictions:

Statamic is not Free Open Source Software. It is proprietary. Everything in this and our other repos on Github — including community-contributed code — is the property of Wilderborn. For that reason there are a few limitations on how you can use the code:

Projects with this kind of restrictive licensing often fail to attract much contribution or adoption, because the freedoms are not clear.

In a GitHub issue requesting Craft CMS go open source, Craft founder and CEO Brandon Kelly said, “Craft isn’t closed source – all the source code is right here on GitHub,” and claims the license is relatively unrestrictive as far as proprietary software goes, that contributing functions in a similar way to FOSS projects. This rationale is not convincing enough for some developers commenting on the thread.

“I am a little hesitant to recommend Craft with a custom open source license,” Frank Anderson said. “Even if this was a MIT+ license that added the license and payment, much like React used to have. I am hesitant because the standard open source licenses have been tested.”

When asked about the licensing concerns of Studio 24 narrowing its candidates to two proprietary software options, Coralie Mercier told me, “we are prioritizing accessibility.” A recent project update also reports that both CMS suppliers W3C is reviewing “have engaged positively with authoring tool accessibility needs and have made progress in this area.”

Even if you have cooperative teams at proprietary CMS’s that are working on accessibility improvements as the result of this high profile client, it cannot compare to the massive community of contributors that OSD-compliant licensing enables.

It’s unfortunate that the state of open source CMS accessibility has forced the organization to narrow its selections to proprietary software options for its first redesign in more than a decade.

Open standards go hand in hand with open source. There is a mutually beneficial connection between the two that has caused the web to flourish. I don’t see using a proprietary CMS as an extension of W3C values, and it’s not clear how much more benefit to accessibility the proprietary options offer in comparison. W3C may be neutral on licensing debates, but in the spirit of openness, I think the organization should adopt an open source CMS, even if it is not WordPress.

40

40 responses to “W3C Drops WordPress from Consideration for Redesign, Narrows CMS Shortlist to Statamic and Craft”

  1. “More generally, we think this push to expand Gutenberg is an indication of WordPress focusing on the requirements of their non-technical user base as opposed to their audience of web developers building custom solutions for their clients.”

    I don’t know exactly how they mean that, but for me, it was the exact opposite: Gutenberg opened-up a brand new level when it comes to building custom solutions for clients which were simply not possible before.

  2. Thanks for the heads up about the Classic Editor going away. This would be the last straw. So misguided. Gutenberg provides nothing useful to me and adds undesirable complexity (and bugs). So I have 1 year to make WordPress go away. Sad to find myself kicked out. Wish it weren’t so.

    • I was thinking that. There is always the possibility of exploring the fork ClassicPress. Not sure if they did though. Maybe they did and found it not meeting the requirements enough.

      Alternatively they could have made their own fork. All perks of the GPL ;)

  3. It’s sad to see WordPress is not on the recommended list. I think the concern about Gutenberg is only half of the truth. Gutenberg is being improved, in a speed that we’ve never seen before in the WordPress ecosystem. And I’m sure it will satisfy W3C requirements for long term. Besides, WordPress is a truly OSS, which W3C should reconsider.

  4. “I don’t see using a proprietary CMS as an extension of W3C values, and it’s not clear how much more benefit to accessibility the proprietary options offer in comparison. W3C may be neutral on licensing debates, but in the spirit of openness, I think the organization should adopt an open source CMS, even if it is not WordPress.”

    This an interesting critique, in the context of Automattic and wordpress.org taking a pragmatic view, and using proprietary software quite freely when it does the job best. I don’t criticise it for doing that, by the way. But, to take an example, wordpress.org uses Slack heavily for communication, rather than Mattermost. My personal view is that life has too many other things to think about for me to care much about that one way or the other. But it’s at least a little curious to read an article on the Tavern criticising external bodies for apparently having the same policy as the main bodies in the WP world have. It seems unlikely that external bodies are going to take such critiques seriously in that context?

    • But, to take an example, wordpress.org uses Slack heavily for communication, rather than Mattermost.

      WordPress started using Slack about 18 months before Mattermost existed. Switching services, especially when so much time has been spent for integration, isn’t quite that simple.

  5. It’s unfortunate that the state of open source CMS accessibility has forced the organization to narrow its selections to proprietary software options for its first redesign in more than a decade.

    I share this sentiment. Also deeply curious since the cursory notes on accessibility for both of the reviewed CMSes seem to highlight a ton of issues like “Buttons and Checkboxes are built using div elements” or most inputs lacking clear focus styles. An element like the Calendar for choosing a post date seems entirely inoperable with keyboard on Craft, for example, while WordPress’ has had significant effort and rounds of feedback poured into that element alone to make it fully operable.

    We always have a long way to go to continue to make WordPress usable and accessible to the vast majority of people, and there will always be disagreements on whether we are hitting the mark or not on specific parts of the experience, even within the contributors working to make WordPress better day to day, but overall I think the effort exhibited from those contributing to the software is steps ahead. In my opinion, building a components API that can lead to better accessibility baselines for developers extending WordPress is on its own very impactful and equally challenging.

    Then there’s also the recommendations to the person authoring content, from heading outlines to color contrast in different places, on top of ensuring the semantics of blocks in the front-end are the best they can be. We ought to continue being our harsher critics, but in these wider comparisons I think we also need to retain perspective.

  6. The bad implementation of the otherwise good idea like Gutenberg is the main cause. Gutenberg has so much issues that my clients are not threatening to change companies if we don’t install the Classic Editor instead of the block editor. We maintain one mid sized European news website CMS and it has many customizations on top of WP, but it looks like the editors were extremely unhappy with Gutenberg. Performance was one of the reasons. Something bugs when you have multiple media files on the page and/or when you work with combination with custom plugins.

    I think it’s time for Gutenberg team to have some changes in the way they pursue this editor and in fact to involve more professionals and prosumers, not just devs and the everyday life of how the CMS is used in order for them to have a more objective picture.

    It’s one thing to build a page builder for devs, it’s something completely different to build the page builder to work for professional journalists and creators, which are not coders or devs.

    To me Gutenberg is bad because it lacks the appropriate survey data from real world usage. Just because something looks installed, does’t mean people are happy with it.

    Gutenberg opens a huge marketing hole for someone to take in.

  7. Good for them. I’ve been a WordPress fan and user for years, but only a reluctant Gutenberg fan. To call something Gutenberg in the first place is pretty grandiloquent. If something were pure genius and groundbreaking, that term might fit.

    After many hours using it, it still feels odd, buggy, and tricky. I don’t know if it’s too many cooks, too complex to simplify, too much work put in to back out, too little testing before publishing, or simply too goofy. It can make one want to go shopping elsewhere.

    I’m sure they mean well.

  8. Out of all of the Studio 24 statements, I would say that this one is the most indicative of where they and a lot of other agencies stand on WP right now:

    “More generally, we think this push to expand Gutenberg is an indication of WordPress focusing on the requirements of their non-technical user base as opposed to their audience of web developers building custom solutions for their clients.”

    For context – I work at a design focused agency that places a lot of value on providing a great admin experience for content authors that provides both a flexible authorship experience that is also limited. We want to prevent content authors (who – no shade – are not designers and typically do not have “design awareness”) from messing up a great design that they paid quite a bit of money for. From this perspective, Gutenberg feels very iffy:

    Yes – I can create custom blocks. Yes – I can remove default blocks or restyle them based on a projects needs (though, with a slew of ‘breaking changes’, this feels like less of a solid option). But in doing all of this – you spend more time removing things, and you are more vulnerable to future additions/markup changes/who knows what else. And to top it off, training content authors to create rich, resource related content with Gutenberg blocks takes longer and is more vulnerable to improper content entry, compared to using ACF fields and TinyMCE.

    As such, it feels more and more like WP is becoming less and less of a product is BOTH a consumer friendly product and a CMS that can be customized to the needs and desired limitations of a project by a developer. This is something that is really is starting to shake my confidence in the CMS, something this WP fanboi didn’t really think was possible.

    Wanted to say this just to echo Studio 24’s reluctance and insecurity with the future of the project. It’s something that I think WP should really take into perspective and ideally address. Even if their plan is “yeah, from here on out, we are now primarily aiming at non-technical users and not custom CMS developers”, it would be great to know so I can peacefully move on to another CMS, rather than riding on a wave of uncertainty.

    • I do not believe that Gutenberg serves the non-technical user base either. I observe that most non-technical users just want to get their information online with as little fuss as possible. I see Gutenberg working against this purpose. I have found that some non-technical user’s think even the Classic Editor is too complicated! Gutenberg will make their heads explode.

      I see Gutenberg chasing after a mythical user that is neither technical nor non-technical. Reminds me of some now defunct retailers that decided to go after a different kind of customer, only to discover too late that it was a very slim slice of the market.

      • I do agree with this. It’s great in abstract, it’s great on paper. But in my experience the IRL usage doesn’t really align with the idea of it.

        My partner is a graphic designer who recently made a site with Squarespace. She hated it, because it seemed like she could do anything, but ultimately it just placed her in an invisible box. The ability to easily do anything custom out of the box in a repeatable, easy to use way within that system was an illusion. IMO the same is true for Gutenberg.

        I also recently helped a non-profit set up a site. I opted to just use Astra and Gutenberg, thinking it might be faster. I thought by importing block patterns, setting up Customizer settings, etc. I would save time and it would be easy to use. In the end I spent too many hours trying to figure out how to get the nested block layouts I wanted, which felt like an exercise in “How to make a dev with 12 years experience feel like an idiot” When I went to train the client, they were perplexed and unenthused to edit. Explaining how to make some of the layouts, change the fonts and colors, etc, completely overwhelmed them, not to mention the concept of “reusable blocks”. They made one content update (which did not match any of the other layouts on the site) and now I get emails asking for help entering content (which in this case I don’t mind, but thats not the point 🙂

        I share these two stories because they speak to the downstream effects of giving too many options to users. They either end up dumbfounded and confused and making a mess, or they think they have more power than they do and get frustrated by the tools (or lack thereof) available to them.

        • Let’s point the elephant in the room, although I am sure this comment won’t be published.

          By trying to make things easier for the ecosystem with replacing tons of plugins made by devs with blocks that can be customized by the end user, WP actually the new editor “harder” for the average user.

          Currently you have two type of people working with the CMS, usually that is the company that builds the site – devs, coders, WordPress technical experts, marketers, designers, and there is another group – the people that would actually use the site for publishing – bloggers, creators, writers, journalists, artists, news editors, commentators, reviewers etc.

          By creating Gutenberg, they tried to blend these together and they cannot be one thing most of the time.

          If the first group is the people that build your house and put the furniture inside, the second group is the people that live in that house. These, in most cases, are two different groups!

          That’s why it would make total sense to have two distinguished modes, one is to [build] the site and the other mode should represent the [writer’s mode]. One is almost a one-time thing, a more static approach that happens one more several times in large periods, the second is something that happens frequently.

          You can’t force a journalist to use a non-standard text editor with block building to write their content. Look at this comment field – it is a known from the 80s word processing experience, email client experience, office doc writing experience, text writing experience that everyone is familiar with.

          If you force a news editor, a journalist to write his content in blocks instead of the familiar experience from 40 years, then you are alienating him.

          Just ask any journalist out there, any professional writer, if they find an experience of “building” their content better than “writing” their content.

          Gutenberg should split in two modes! And no, Iceberg is too glitchy and slow to do the trick!

      • I’ve been saying this from the beginning, it is a tool build by devs and geeks aimed at devs and geeks. TinyMCE editor + shortcodes was much easier than the current stage of Gutenberg. I am not against Gutenberg’s idea, I am against its implementations. It’s basically Linux throwed at the average Joe. Even if you gave them Ubuntu or one of these trying to be friendly distributions, their market share would still be less than 1% for the average desktop user. Coders, devs, geeks, they should understand they are not representing the average Joe.

  9. Thanks for this article on the CMS platform work for W3C. I’m the founder of the agency who is working on the W3C redesign project.

    You make a lot of good points. I’ve written a post explaining the background of how we chose the CMS which I hope makes this clearer and addresses some of your concerns. https://w3c.studio24.net/updates/on-not-choosing-wordpress/

    I was not aware of ClassicPress so thanks for that. However, I’m not sure using a fork is such a good idea for W3C who are keen for some stability in their tools. Having said that I see Backdrop (Drupal 7 fork) is still being actively maintained so this approach can be successful. https://backdropcms.org/

    We are trying our best to work in the open on this project and will continue to post updates to https://w3c.studio24.net/ as we go along. W3C is committed to taking community feedback on the project.

    • Great write up and I echo your sentiments.

      The list of considered CMS’s does seem short though. Did you guys look at others like Grav?

      Am also in the same boat and will most likely be changing CMS in 2021. Will be following your progress with Craft!

    • I’d certainly love to see objective data showing how/where Craft or Statmatic are actually better in terms of accessibility than WP. The arguments I’ve seen seem based more on subjective feelings and drama than reality.

      Personally I think the complexity argument is strongest. Too much custom gutenberg work ends up feeling like it’s built on sand, and while it “works today” it’ll come crashing down tomorrow.

      Gutenberg blocks just don’t have a solid foundation that allows 3rd parties to easily build out custom solutions that promise long term stability. This was the killer feature of WP and WP widgets a decade ago. Heck, core blocks don’t even address the basic need these days for mobile responsiveness, let alone UIs that embrace content creation on touch based devices.

  10. Craft and statamic are awful niche money Pits, and their licenses preclude taking work done elsewhere.

    I’d also question anyone suggesting any multi-lingual CMS solution is ideal, but have shaken some wonderful properties out of WordPress and multisite.

    Gutenberg is getting much better. I recently as a few months ago upgraded a plugin I maintain to use storybook for a block it carries, and was delighted to not need a database, we server etc to test an editor plugin.

    This really does seem like selection of vendors wasn’t ideal

  11. Wait a second, W3C – an organisation that employs people and generates revenue that can pay them a salary of sorts, that has money enough to pay an external agency to build a new platform for their website – is essentially coming under fire here for choosing a proprietary solution.

    Open Source is great and contributions by a wide range of developers is an incredible asset, but you’re missing how many of those developers do it for nothing, no financial reward, not even some recognition.

    Automattic haven’t really stepped up on that front, despite making millions out of WordPress.

    The W3C are free to use whatever tool is fit for purpose. If their financial commitment to a particular platform improves its longevity and betterment, then so be it.

    WordPress is not geared up for that kind of investment and would need to change how it rewards contributors massively in order to shift this discussion.

    Yes the tool can change and the license may go some way to enabling that, but to see the proprietary tools that have been around for much less time being so well polished by much smaller teams really destroys the argument in my opinion.

    WordPress desperately needs some new blood in terms of its technical oversight so that it can continue to be a serious contender as many companies are starting to see that ‘free’ is actually turning out to be quite expensive.

  12. It would be interesting if we could learn more in-depth details about why they prefer Classic Editor to Gutenberg, especially given the Classic Editor’s limited potential.

    I can understand complaints from those who are used to their Premium Theme’s Page Builders and Gutenberg gets in the way. On such a large scale project, though, I assume that there will be a custom implementation, where Gutenberg shines, allowing you to build really cool stuff.

    On top of that, Gutenberg content can be easily migrated on a future redesign compared to shortcodes (which can easily cause a huge mess), allows you to write the cleanest HTML possible, and the frontend output is much faster, as most of the time there is no need for storing data in meta fields, with everything remaining on the post’s table.

    I assume that it’s about accessibility issues, but it would be interesting to learn which in particular, and how the Classic Editor is better at dealing with them.

  13. While it’s true that I reported that 2/3s of the issues raised in the spring 2018 audit are resolved, that’s only a partial representation of the overall state of Gutenberg’s accessibility. There are still a lot of issues that need continuing work, as well as new accessibility problems that are continuously introduced as features are redesigned or introduced. That 2/3s resolution only encompasses the issues raised within the first few months after Gutenberg was released, and addresses nothing at all in the features developed since then.

    While Gutenberg has decent accessibility in comparison to many similar editing environments, I would be hard-pressed to consider it something that can be recommended for any organization that needs people with disabilities able to work on content creation. The complexity and rapid pace of change has a profound impact on the ability to learn and use the system, even if one were to assume that the technical implementations were perfect. (Which they aren’t.)

    I can’t make any statements that would be meaningful about the other content management systems under consideration; but if WordPress wants to be taken seriously in environments where accessibility is a legal, ethical, and mission imperative, there’s still a lot of work to be done.

  14. Don’t forget the other major reason why WordPress was removed from consideration; “no elegant solution to content localization and translation.”

    I’ve been complaining about this for year, localization and translation should be in the core. WordPress is about communication and not having multi-language support in core is a huge failure.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.