On not choosing WordPress for the W3C redesign project
w3c.studio24.net
w3c.studio24.net
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.
But more importantly, it should not be in core. Full stop. Once WP became REST-driven the push should have been to lighten core. That is to decouple as muxh as possible. Core is that _core_. Then you configure your needs from there. Core should be the basics, as light and as lean as possible.
But instead, more and more unnecessary bloat. More and more features with less and less benefit.
Yes, I'm looking at CraftCMS and others as well. WP has jumped the shark. It's not going away. But I'm tired of having to shower after everytime I work with it.
WordPress should not have the same mindset as Jetpack. Oops? Did I just say that?? ;)
(Source: I wrote the REST API in WordPress and lead the API team for many years.)
But instead let's force feed - oops, I mean ship - and bake in a product (i.e., GB) that was half-baked technology implementation and barely an afterthought in terms of user experience. (Note: UX in this case includes all the devs who were begged to jump on board, and then jerked around like a puppy on the leash.)
WP core should be a service. Lean, tight and clean. Tightly coupling more and more likely unnecessary features to that doesn't help anyone. Trying to maintain that monolith is overly complicated. And so on.
We have the plugin architecture. If it's broken, then let's fix it. If it needs some sort of dependency manager, then let's talk about thst as well.
But Gutenberg? That makes 2020 look like a summer holiday, and we all know how bad 2020 has been :)
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.
> - 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.
You need to use a third party service or setup.
> Yes, but adding further content types at the level of code or these plugins is easy, trivially so.
Compared to what? Drupal? CraftCMS? Joomla? Where you go to a UI and do it all, versus installing a plugin with it's own quirks or using functions.php which ends up being the last place you want to touch after your done?
> It has several caches that are very powerful indeed, including those included by default. PHP is a theming engine.
No it doesn't, you need a plugin like W3 Total Cache. On their Cache page they tell you to use a plugin. https://wordpress.org/support/article/optimization-caching/
The other caching setups Opcache, Varnish are either integrated in PHP or a completely different service.
PHP is not a theming engine. Blade, twig, etc are theming engines.
> I mean, people use it to run newspapers, so not sure if this is true. It depends what you need.
Newspapers are glorified blogs, so yes that makes sense that they run on WordPress.
But the problem isn't random sites use WordPress, the problem is people build weird monstrosities on top of a really garbage system.
I'll agree that its easier to do custom post types on other CMS. But sometimes at the cost of real overheads in terms of complexity for users to swallow to get there.
Caching is built into the core, which is what all caching plugins leverage, the interface to it is hidden.
PHP is a theming engine.
I've never got why people escape into Blade, Twig or so on. PHP was designed to have loops, logic, to take variables and so on and interpolate them within HTML. It has an alternative syntax to make this easier. It's one of the unique capabilities the language has over almost all other languages you'd use on the web. More often than not you end up escaping into pure PHP in any case in something like Blade.
> But the problem isn't random sites use WordPress, the problem is people build weird monstrosities on top of a really garbage system.
Don't think its garbage for the reasons explained, but I think this true of all software projects. Seen plennty of Drupal, Laravel or Joomla projects end in this state.
Compare a Twig theme with a PHP based one. The former is much cleaner because views and controllers are separated, there's clean ways to reuse views, and the syntax is cleaner and more concise for common operations. The standard PHP approach in WordPress gets messy really quickly.
Related, but I can't believe how much responsibility WordPress theme writers have to manually make sure echoed strings are escaped properly (Twig has the same problem because it would be fighting against WordPress otherwise).
I think one thing that's missing from the templating engine argument is WordPress' data model. While PHP may be a templating language WP's API to access data is a huge pain. A great example is wp_nav_menu. To modify it in any meaningful way you have to use the Walker Class. Seriously? It's an array. If WP's data model were better you could definitely 'foreach' your way through that thing... but you can't.
Antlers has a shorthand syntax to cycle through its navigation type. Laravel doesn't have a native navigation type but when I set one up it's pointing to table of pages. At this point I can use Blade to go through that table and pull out the appropriate title and url.
Why is this nice? No more "#" for placeholder menu items. More control over the Aria roles, etc.
This is just one win, in my experience, of using Laravel/Statamic.
Edit: for grammar
When you have a few hundred images (and that's just for a small site, let alone newspapers), do you really think having just a dropdown with media type and month for a filter (out of the box) suffices? Asset management is a core feature for any large-scale media outlet CMS.
I just don't think it is truly as bad as has been made out by the initial comment.
Totally agree, but unfortunately PHP's integration within a markup processor is quick and dirty, without consideration for context-dependent escaping and quoting etc. hence continues to give rise to a large number of HTML injection attacks.
I wouldn't use that as an argument.
For me many maybe even most newspaper sites are just plain out bad designed.
They tend to be overloaded, slow to load, easy to overlook things easy to get accidental lost and hard to find things from lets say a week ago.
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.
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.
They also get free suppport. You don't get that with WordPress.
From what I've seen, almost all hosting providers now offer one-click installs for WordPress.
Aside from that, what's the UX like for a client spinning up a new WP site on GoDaddy or Bluehost vs. a new Wix, Weebly or Squarespace site?
In the end most of this is pretty subjective. If you like WordPress keep using it and recommending it. I used to love it and don't anymore. I think my clients get a better value using Statamic or one of the other options I've pointed to.
Anecdotally I have heard that many clients prefer Statamic's and CraftCMS' editing experience over WP.
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.
Yes I know there is third-party plugins and services. I mean "core" wordpress. Not what a bunch of other's built.
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."
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.
Related write-up: https://adrianroselli.com/2020/09/gutenberg-accessibility-co...
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!"
I can read it, but it's not pleasant at all.
It is truly terrible, isn't it!
wat
Excellent. SPAs have their place in things like Notion and Google Docs. I’m glad they’re not depending on Javascript.
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.
It's also trivial to keep under source control.
My only gripe with Craft is Redactor, which can easily be replaced.
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.
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.
Is this available publicly? Most of my work these days is putting right WordPress sites (and setting up Varnish and ESI) rather than building them, but this would be of interest.
The pre-approved plugin list (https://www.altis-dxp.com/resources/pre-approved-plugins/) returns 404 though :(
> 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.
Otherwise I experienced exactly what you mentioned. Install a plugin, write code to dequeue its resources from all pages it's not running on. Of course, there are plugins that help you do that, but it's yet another plugin!
> I think part of the problem is WordPress plugins compete with each on features and need even more features on top to charge for the premium version, so page speed and robustness via simplicity get lost in the noise.
I agree, that looks like part of the reason for bloat, but most have also evolved over years. Most successful plugins have been around for a decade or so, and few people talked about web performance in 2010. That many authors initially just solved their own problem while learning php and shared their solution plays a part as well (not to mention that they often started writing them on php4).
I use The SEO Framework now on most of my sites, and it is a good experience. It is made by someone who cares about his users instead of wanting to milk them.
https://wordpress.org/plugins/autodescription/
If you need to move data over from SEO plugin to SEO plugin, check out the Data Transporter plugin. https://wordpress.org/plugins/seo-data-transporter/
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).
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.
> 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.
Regardless, to define a language it only makes sense to author the specification from the language perspective. From what I've read, and honestly it's been many years since I have read their stuff, most of the authoring docs have a section in them talking about applications and editors creating the documents.
I don't know, seems consistent to me?
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.
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.
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.
Get a few hundred of those on a site and see how much ram you need.
We've done two migrations from Craft for clients. WordPress isn't great, but Craft isn't a panacea either.
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.
Feels more like their choice was made to fit with the agency capability.
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.
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.
I like static website generation but don't want to get locked into a proprietary CMS platform.
To say it's more complex than WP is true .. but to completely discount it, is foolish.
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.
I see Gatsby similar to Django in that it has "batteries included" for building a modern interactive site. It suits our needs quite well and I'm really happy with it.
> 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?
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.
> Migrating static sites where the content + theme are all stored in Git is a dream compared to WordPress.
Wordpress (and similar) site migration has been a well solved problem for quite some time. Sure, there might be easier ways to do migration but that's a long ways down my list of things to worry about when choosing my tooling. Ease of migration isn't much of a consideration.
> A lot of WordPress sites aren't even under source control...
A lot of Wordpress sites are a dumpster fire actively attacking the internet. That's not the sites I build and manage. I'll create static websites for my own usage, but not for buyers of my services.
Any headless CMS service (as opposed to self hosted) is really just an option of interfaces on the market. Of the things which matter to buyers, that interface is everything on the back-end (the site as a whole has more important goals.) The buyer doesn't care about ease of migration, how content is stored, etc. Only developers care about these things. So, let's talk about what buyers want, not developers.
If a X headless CMS service can provide the best UI for the buyer, then that's what everyone should default to. If not, then all other bullet points don't matter.
All state is stored in Git and Netlify CMS is just a client-side JS script that talks directly to GitHub. It's an interesting approach that suits some projects. Don't read into this comment more than that.
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.
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.
I wasn’t able to find what fraction of the Internet sites are multilingual but would be curious what’s your estimate. I still would be surprised if it is >10%. Maybe more if you weight by traffic but that is not the relevant metric here.
The plug-in approach has another advantage: there are several reasonable approaches to a multilingual site, i.e. you can have a default language if a translation is not available. Or rather show nothing. You may want to force a translation of each page. How do you track the translation of changes in one language, etc.
By picking/adjusting a plug-in you get the behavior you want instead of a one approach satisfies nobody default solution.
* I’ve dealt with these WP multilingual plugins and they were all atrocious (see my first comment). Nowadays, if I have a core set of requirements, and a piece of software only offers that set through plugins, I will not consider it anymore. Plugins are fine for nice-to-haves, but not for must-haves. It’s a recipy for a maintainability disaster.
[1] https://weglot.com/wp-content/uploads/20191017121225/image16...
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.
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.
Btw, there is a hosted WP to static SaaS. I forget the name tho'.
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."
I don't know how representative these results are, but it's a clue.
https://trends.builtwith.com/cms/WordPress
I don't now if there are numbers for static sites on there, but my guess is that those numbers don't come close to Wordpress, especially for the top million sites.
The investment in tech like Gatsby, goes a long way to showing how the market does support this.
Market dominance, won't describe the trends a market is moving towards.
So, which is it? Don't use Wordpress because it's PHP based and doesn't scale? Or Wordpress headless is okay because the front-end is static?
Static sites are the future, not Wordpress? Or Wordpress is still going to be a part of the headless market because the CMS supports that functionality?
You're confusing me.
I just wanted to correct you.
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?
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.
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.
I think its a bad sign if there is such a massive opposition to the direction and it is disregarded completely.
And like you said, once you start using atypical situations, it becomes a unnecessary complicated affair. Luckily you can dismiss Gutenberg, thats the only upside.
Many of the often touted so high number of users of WP are however, rather casual want to host a blog kind of users, who really don't need much more than posts and plugins, which take care of implementing stuff on an unfitting abstraction, ehich remains invisible to the casual user.
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.
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.
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)
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.
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.
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.
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.
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.)
If it isn't prioritized by Automattic, it's not getting in.
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.
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).
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
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.
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.
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.
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?
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.
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.
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.
Could be either used as "full CMS" or as data source for a downstream static site generator...
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/
Its really thrilling to see someone think technical decisions out loud. So keep it up, despite what I am about to type!
There are a couple of interesting things in this article.
1. It is absolutely remarkable they got 15 days to rather requirements and choose a CMS. Having worked in a couple of agencies, this is a lot of time, which is to the good W3C paid for it.
2.
> We have very talented front-end developers, however, they are not React experts - nor should they need to be. I believe front-end should be built as standards-compliant HTML/CSS with JavaScript used to enrich functionality where necessary and appropriate.
It makes a lot of sense for websites to be written in HTML/CSS in this progressively enhanced way, but does it make sense for complex user interfaces like any WYSIWYG editor?
Even the Classic Editor basically dropped probably thousands of lines of (actually third party) Javascript into the mix in the form of TinyMCE.
3.
> We won’t stop trying though and plan to do more R&D with Gutenberg in the future. The W3C project, however, did not feel like the right place to do this. On a project as wide-ranging as this one, development time does become a factor.
This is about agency and project risk which is entirely fair enough. However, what is slightly strange, if risk of delivery due to unfamilar technology is a factor, is that the project then goes onto make two other decisions.
- Use Craft
- "We are currently considering a Headless CMS option for front-end page delivery"
It is unclear from this piece if they have much experience using Craft, but my project manager alarm bells are ringing a bit when a team is intending to "deliver project in technology they have no internal expertise in".
Of course, Craft is by all accounts excellent, but could be a source of problems. The judgement is between the technical difficulty of using Gutenberg and learning a whole new CMS as a developer.
Further: the headless CMS option.
Do the team have the experience of doing this? Where I currently work we are actually considering moving back from headless CMS because the current leader in the field, Gatsby, has some pretty major downsides.
One of the reasons is that site build time is terrifically slow. Their approach seems to be roll our own headless thing with Symfony which will presumably do calls in real time. Symfony is very full-featured, but this seems like rolling your own headless framework - who is going to maintain it?
Of course it could be very simple, but launching a project in: an unknown CMS, with an unknown way of doing a website, seems a strange move when one object seems to be reduce technical risk.
What if you want a cdn outcome which doesn't drive to an sql backend?
I've yet to experience wp consciously without it making me wince. I know a lot of former print press is using it, so the for profit sector likes it. That does not axiomatically make it best of breed.
Being php is also not axiomatically worst of breed. The questions are decoupled really.
1) is wp still php
2) is wp best of breed.
3) if you want static site through cdn is wp the best fit?
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.).
Please stop, it's going nowhere.
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.
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.
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.
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?
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...
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?