The ongoing WP Drama sparked my interest of what is going on with other CMS systems.
My approach was mostly what pain points I personally see with WP and what interesting, different approaches other CMS might have.
As the name says CMS stands for the management of Content. So let's start there.
For many people the killer feature of WP in the block era is that already while editing one can see how things will look in the frontend. So that you can see and edit layout and content at the same time. For me this is at the same time the biggest achilles heel of WP.
So where exactly do I have a problem with that? Let's have a look at the following content type and how it could be implemented with WP.
As you can already see, this not very exotic content type already is hard to represent in WP.
For a proper Editing-UI one needs custom development or at least plugins like ACF.
Some things like a multilingual site are not or pretty hard to cleanly do in WP.
All in all WP, or at least WP Core, pretty quickly reaches its limits for anything that structurally isn't a classic blog post or generic page.
Let's just reiterate: Why would we even want a content type in such a form?
Let's break it up into 3 steps:
So, next, some approaches from other CMS. Very high level, not how everything works, just what is nicer than in WP:
Content easily defined in YAML files.
Since just text files easy to version and mergeable.
UI to define content types and fields
Easy import/export -> versioning, migration (similar to ACF Export/Import Sync but for everything)
Blocks similar to WP, less flexible, but easier to handle.
The combination of fields and blocks enables strict specifications as well as flexibility, as required.
Way easier to extend without build chain.
What I haven't mentioned yet is that multilingual content is a core feature for Kirby, just as with Drupal and Neos.
With its concept of "Dimensions" it even goes a step further.
Without going too much into the details: Translating content into different languages means having different variants of the same content.
But languages are not the only situation where such a relation might be needed.
For example one could have a situation where a content, although always in german, needs to be different for austria and switzerland.
E.g. because of the currency or because features differ per country.
Neos makes it possible to define language and market as two different "Dimensions". Then you can create content for each specific content, but can also define fallback rules if something is the same everywhere.
This is already a great example of how Neos whenever there is the need for a feature like multilingual content doesn't just implement it, but also tries to find the most generic solution that can also cover more exotic edge cases.
Backend layout can be defined inside a certain range via YAML
Something we need again and again is preparing bigger changes of content.
E.g. when launching a product publishing the product page, the corresponding support area and a news.
And work on these collaboratively before publication.
Here Neos offers Workspaces that work similiar to Git branches.
The templates are very close to what one is used from classic PHP based WP templates.
But there is a clean, consistent API that is also easy to extend.
What I really like about this is the individual control of HTML instead of markup predetermined by the CMS.
Very powerful tools for complex data queries and transformations.
But very steep learning curve for something that only exists in Neos and for plenty of use cases probably only overcomplicates things.
Therefore I am not even going deeper into this.
Exporting or importing data from a local environment or backup is rather cumbersome.
One the one hand because the final URLs for images are directly inside post content and you always have to mess with the DB.
On the other hand because posts or media do not have unique IDs and hence it is easy to break references based on IDs.
It is similarly annoying to move setting changes between development environment, staging and live server. Partially as well as fully.
Other CMS systems can do this way better:
After all these technical things and features I'd like to close with something else.
Since one of the reasons why I have looked at these other CMS was the ongoing WP Drama I was also interested in how the ecosystems as well as the power- and organisational structures around the CMS work.
As you all know WP Core is Open Source and developed by volunteers, although often in the form of sponsored fulltime developers.
The same applies to many plugins.
Especially bigger plugins, often even for essential things like e.g. custom post types or forms are commercial products.
That on the one hand means more stable development due to sustainable financing, on the other hand fragmentation and lack of cooperation and standardization. Sometimes even less interest in usability or security than in more profit.
So, how does this look elsewhere?