For all the criticism the Gutenberg Block Editor gets, it was a necessary move for Automattic. They were one step away from being ousted from their own CMS by the likes of WPBakery, Visual Composer and Elementor. If your CMS becomes just a glorifed container for third-party solutions, it's just a small jump from there to having your users move to a completely different backend built by the aforementioned authors.
I still don't get why did they had to reach for such a needlessly complex solution. A few weeks ago I tried building a small project for a client by writing bespoke blocks for custom logic and storing.
I found it was waaay easier and even waaay quicker to learn laravel to scratch than try to wrap my brain around the weird custom superstructure they built around React, their suggested approach on how you should write a version of each block for previewing, another for editing, some glue code between those that is not extremely clear how you should be interfacing, etc. Their developer guide is the equivalent of the "Draw the fucking owl" tutorial.
Even looking for exisiting examples, every one of the default wordpress blocks does things their own way, the whole thing felt over-engineered and extremely brittle.
Yup, fully agree. Thankfully for most of my client work I don't need WordPress theme-ing at all, so I have a custom plugin that disables that, and instead allows me to integrate into WP (so that I get all the WP core PHP functions as well) a PHP framework installation (for example Laravel) where I do all my data-and-front-end wrangling instead. It also supports replacing the front-end with a custom React app, if I wanted that, leaving WP as just the API and admin panel.
And as for letting customers edit custom data structures, I still roll with Advanced Custom Fields plugin for that, because it's 100x faster than making the equivalent functionality for the block editor. I do hope they simplify that API at one point though.
Honestly I wish they just offered an officially supported framework-agnostic headless solution on par with Block Themes. I was kinda hopeful when Automattic bought Frontify[1] some time ago, but for some reason apparently that went nowhere.
A drag-and-drop page builder was the right move, except Gutenberg didn’t take any cues from what was already out there. They didn’t reuse any ideas from existing builders which were already in their second or third generation, and instead went out on their own and built UI trash.
The problem is that WordPress lost the plot with its block editor, Gutenberg.
Automattic started to get more interested in money than they did in polishing their core product, WordPress. Instead of implementing a lot of these features into the core (which would then make room to actually make interesting plugins), they're acquiring companies left and right and delivering a new WordPress release every few months promising "100+ performance improvements", etc.
How come those "performance improvements" never actually do anything?
Not only that but WordPress ecosystem right now is extremely fractured because of this "block editor". It alienates more than 20,000+ themes because they're built on the "old" WordPress principles, and at the same time - nobody really wants to use block themes because it means starting from scratch.
I have played around with block themes as recently as a few months ago, and they've definitely gotten better than they were ~1 year ago, but they are only good if you know what you are doing. And, if you even have the patience and the will to make a custom site for yourself.
This is turning more into a rant of me than anything though, but maybe that's precisely the point, that's where WordPress is right now and the only thing I can see is that maybe Automattic is "afraid" to alienate plugin developers and cause a backlash.
I understand why Automattic needed something like Gutenberg. The external competition from Wix and the likes and internal from Elementor, etc, was existential.
However, after all these years, it’s still a usability mess for the end user and a nightmare for the developer.
Was it really necessary to shove React and that dreadful ecosystem down everyone’s throat? I mean, the hello world of a block downloads 50k files through npm, I shit you not. And you now have to deal with JSX and need a build step for the web, which is heartbreaking for me. We have PHP, which is superior as a templating language in every possible way, and it’s right there already.
Anyway, whenever I start a Wordpress project I’m faced with using the block editor or falling back to ACF. And honestly, neither one feels like the right choice.
> We have PHP, which is superior as a templating language in every possible way
It’s been a very long time since I’ve written any PHP, but even when I did write PHP pretty much full time this wouldn’t have been my impression. Tooling aside, JSX is exactly what I would have wished for PHP templating to be (if I had had the foresight to wish it). In fact, if I’m not mistaken, I believe better templating in PHP is the JSX origin story?
Don’t get me wrong, if you prefer PHP for templating, I have no quarrel with your preference. My gripe, insofar as I have one, is the preference stated in an objective framing.
Sure, preference is subjective. What is objective is that JSX is very constrained. Both because it lives inside another language (JavaScript) and by design.
It must only return a single element, you can’t add arbitrary attributes, its control flow syntax seems (subjectively) bolted on, etc.
When you’re coming from a language where you can print anything, it's very frustrating.
Some of this isn’t right or deserves clarification.
> It must only return a single element
Assuming you mean “return” as in a JSX expression in a return statement (though the same applies to a JSX expression in any valid syntax position), it can be any of:
- one Element (which may or may not correspond to any markup element, it can resolve to basically anything depending on implementation)
- zero Elements (<></>)
- a non-Element child-compatible expression (typically a primitive value in most implementations)
- any arbitrary non-Element expression (behavior will vary depending on implementation support)
- N Elements (<>…</>)
> you can’t add arbitrary attributes
This is entirely implementation dependent. Attributes aren’t even part of the syntax (they’re “props”), and many implementations differ on how or even if they correspond to attributes at all. The spec does not constrain arbitrary prop names.
> its control flow syntax seems (subjectively) bolted on
It’s actually the inverse: control flow is anything that can be used in a JS expression position; JSX is bolted on (extends) the expression syntax. Some implementations and/or libraries also implement control flow as JSX Element expressions (eg Solid’s For, Show, Switch/Match).
> When you’re coming from a language where you can print anything, it's very frustrating.
The only real limitation syntactically is that everything in a JSX expression must be an expression itself. This isn’t as limiting as it sounds, because functions can be expressions (with anything in their body, and can be invoked as an expression inline at their definition site).
It might help to think of JSX as more like an S-expression (as in Lisp). It can express any value (that the language can produce), but it can’t express arbitrary statements.
> Assuming you mean “return” as in a JSX expression in a return statement
I do. Right, but the <></> syntax still feels like a hack around a need to have just one node at the top of the three.
-----------
>Attributes aren’t even part of the syntax (they’re “props”)
What I meant was that this is valid syntax:
function hey ({ props }) {
return (
<div data-foo={ bar }></div>
);
}
While this isn't:
function hi ({ props }) {
return (
<div { bar }></div>
);
}
There are many situations in HTML where you want a plain string inside the tag, like <input checked>
-----------
> control flow is anything that can be used in a JS expression position
I explained myself poorly. We can use if/else outside the return statement, of course. It's JS after all. But inside it, which is where the JSX magic happens, you have to resort to things like:
{ isItTrue ? (
<i>yep</i>
) : (
<b>nope</b>
)}
-----------
>It might help to think of JSX as more like an S-expression (as in Lisp)
That's probably the biggest complement to JSX possible :)
I admire Lisp from afar, but could never stand the parentheses.
> Right, but the <></> syntax still feels like a hack around a need to have just one node at the top of the three.
It’s roughly analogous to an array (and in some implementations it literally produces an array). The “hack” isn’t around returning multiple nodes, you can’t produce (and therefore return) an expression of multiple anything without some container.
> There are many situations in HTML where you want a plain string inside the tag, like <input checked>
Some implementations do accept that (checked prop without any curly braces or prop value assignment), with roughly the same semantics (the prop is assigned a boolean true). React doesn’t accept it IIRC, but React has quite a few rules beyond JSX (as specified, and as used in other implementations).
> But inside it, which is where the JSX magic happens, you have to resort to things like:
You don’t! You only have to use an expression. This is perfectly valid JSX (assuming whatever is outside the outer curly braces is also valid):
> That's probably the biggest complement to JSX possible :) I admire Lisp from afar, but could never stand the parentheses.
It really is a pretty close analogy, not just a compliment. And in most uses, JSX is almost exactly akin to a Lisp macro (the biggest difference besides delimiters and host language semantics is that the “macro” definition is supplied by some arbitrary tooling external to the host language).
Sure, that’s reasonable if your only concern is echoing strings. Part of what’s appealing to me about JSX is that it’s capable of far more than string output (even in that’s ultimately all you’re producing from it). The thing (usually) produced in a JSX expression is a value, which can be any arbitrary data structure, and can be composed in any arbitrary way you like. Echoing strings—which is to say producing output as a side effect, out of band of a component’s return value—undermines that. It’s totally a valid approach (and makes perfect sense in the context of PHP’s rendering model), it just has a different set of capabilities.
I can see the reasoning behind Gutenberg, but the implementation is absolutely insane. Everything is needlessly complicated, there's no way to debug it, documentation is either missing or outdated, and so on and so forth. A large customer (who's been using Wordpress for close to 10 years now with a heavily optimized custom theme) wanted to use it, because it looked so shiny and cool, but in the end we had to put half a dozen people into what turned out to be a two year long migration process that's still not finished. At this rate, Wordpress will drop Gutenberg for a new editor before all that effort paid off.
The issue is that the block editor and classic editor have very different audiences.
In theory, the former is for the folks who'd use SquareSpace, Wix, etc. Non technical folks who want to customise everything in a 'user friendly' way and have absolute control over their site and its content.
Meanwhile the latter appeals more to agencies and large businesses, who have a bunch of users they want to only allow to post specific content/make specific changes, and a vision for what the site should be that they don't really want changed via random blocks and settings.
Gutenberg was meant to win over the former group and stop them going to SaaS based solutions, but ended up being a headache for the latter, which were arguably a bigger percentage of the folks using WordPress on a professional basis. Hence the ecosystem getting fractured like this.
I'm not a webdev by trade, so when I wanted to write a quick cute portfolio for my sibling I opted for ClassicPress. It's a fork of the last WP version that still featured the normal editor. Creating themes for it turned out to be straightforward thanks to the abundance of templates, tutorials, and examples available for these old-school WP themes. And PHP isn't so bad, too.
The only thing I found myself yearning for is more of an "as code" - i.e. having all of ClassicPress' config stored in a handful of version controlled files, rather than fragilely in a web UI. But for my humble needs, it sealed the deal perfectly. Boring is good!
I don't get the flak, your comment also doesn't explain why Gutenberg is responsible for all this. WP is by far, faaar the most popular website platform, a huge driver of profits for a whole ecosystem of (mostly not so great) companies yet it's open source and Automattic is not anywhere as profitable as it should be compared to this. It must be a hell of a hard job steering this ship and still be not scummy/as good-willed as this company still manages to be.
For me, it's confusing because my theme provides like 3 different block editors to choose from, and all seem broken in a way or another, so I am not very afraid to even click on the "Edit with (insert name) block editor".
> Automattic started to get more interested in money than they did in polishing their core product, WordPress
Company cares about revenues more about "polish" (which is highly subjective - for some polish might be rewriting everything to Rust, for others it might be fancier looking UI components), more news at 11.
Most plugins for WP should not be installed at all, period. Most have weird silly bugs or security issues, that are either due to handling user input improperly, or are just silly bugs, that one would think people would not build i to their code. But in WP land anything goes. And it has been that way for a long time. It feels like WP plugins are attracting lots of beginner developers, who would rather use a regex than a stored procedure to check for an SQL injection. That kind of level.
Even the usual guideline for how to write themes favors concattenation over composition, starting an element in one file and ending it in another, so that it really only can be used in one place, and cannot be reused. wtf. And most themes are blindly following this convention. It feels like almost intentionally encouraging shoddy work.
I wonder how much of this is because of PHP's legacy.
For a long, long time, most articles and tutorials on PHP contained glaring examples of SQL injection, not to mention the whole thing with `mysql_string` and `mysql_real_escape_string`, among others, and embedding your DB credentials in the same file that is served to the client.
Wordpress still uses and encourages patterns that weren't even considered unusual back in the late 00s. Same deal with phpBB if you want to modify that. I can only imagine that a lot of developers see the coding part of a plugin as a means to an end. You certainly won't see much of that in, say, Laravel.
The mere fact that anyone would have to check for SQL injections by anything other than using prepared statements at all is very descriptive of the WordPress ecosystem and the kind of engineering conventions it enables. It’s a sad state of affairs that this terrible insecure mess is the base of so many websites.
„Well it may be terrible but everyone uses WordPress, so I can’t be that bad, eh?“ - wrong. WP was in the right place at the right time, everything else is momentum.
Anyone without any qualification sells themes and plugins, and it shows. In the construction industry, there’s a lot of codes and safety regulations to prevent that and ensure proper practices; it’s a shame the software industry doesn’t.
Wordpress actually provides a database wrapper (I wouldn't call it an ORM) called WPDB, which can use prepared statements.
In practice though, I have found myself on more than one occasion just using PDO in my plugins. WPDB is slower, and its API is weird, like a lot of APIs in Wordpress land are.
Those aren't just the top plugins, they are also each accompanied by companies providing these plugins as paid products.
Yes, Automattic could provide a lot of those things out-of-the-box nowadays, and pay for the required development efforts, but that would probably kill the whole commercial plugin ecosystem around Wordpress pretty quickly. So this situation is kind of the extreme flip-side of what happens if you don't step into competition with your ecosystem suppliers, which a lot of other companies are being criticized for. I think Automattic is overall doing it in a quite fair way - Akismet, WooCommerce and Jetpack from the list are plugins/products maintained by Wordpress.
What I also wouldn't underestimate is the cargo culting that's happening in the WP plugin ecosystem. As the author noted, there are a few plugins (especially the one for "securing" the WP install) that are usually not needed, and don't actually do anything useful on modern WP installs anymore. But a lot of WP marketers love their list of curated plugins, and will drag them along to new employers/clients far beyond their expiration time.
Isn't this kinda expected? Most sites have fairly 'boring' needs, and hence the plugins they use solve 'boring' problems. Like a contact form, improved SEO or security, etc.
If you did a similar survey for the most popular plugins for almost any other CMS, I'm sure the results would be similar. Mostly normal business site logic, the shop system of the day (unless the CMS is for a shop itself), and some minor fixes to things people find lacking in the default settings.
For other examples, one of the most popular vBulletin plugins/mods back in the day was VB SEO, a paid SEO system that was basically the Yoast/AIOSEOP of its day, and one of the most popular XenForo plugins right now simply adds a bunch of BB code options for other video hosting sites and services.
Heck, even real life kinda does this. If you polled people about the 20 most popular home appliances bought in the last 10 years, the majority would be 'boring' things like a kettle, toaster, microwave, washing machine, fridge, etc. Nothing wrong with that, just that for most people, the most 'original' appliance equivalent would probably be a video game console, and the rest of their needs would be just the usual domestic house stuff.
I think the question this raises is: Is Wordpress an application or a framework? Because what it's like at the moment is a half-furnished apartment where it doesn't come with a kitchen sink, but does have a bed for some reason.
If it's an application, a lot of what people need doesn't come in the box.
If it's a framework, a lot of what's built in isn't necessary and it doesn't let users pick what flavour of wordpress they want.
>It struck me recently how this list of plugins I saw in the 2023 Annual WordPress Survey wasn’t full of fun and interesting plugins that do interesting and unique things, they mostly just fix boring problems that users shouldn’t even be worried about having to fix at all.
The word the author is looking for is "useful". The plugins are useful instead of exciting. When it comes to plugins to a CMS I'd have the former, thanks...
Sending emails, setting proper meta tags, creating forms, not having security vulnerabilities, undoing broken upgrades, caching, … are all features that a fully-featured, bloated CMS like Wordpress really shouldn't need plugins for.
It'd make sense if WP had a "small core, versatile APIs" philosophy, but that flew out of the window over a decades ago; it's extremely bloated these days and has tons of features, yet the basics are still missing.
>Sending emails, setting proper meta tags, creating forms, not having security vulnerabilities, undoing broken upgrades, caching, … are all features that a fully-featured, bloated CMS like Wordpress really shouldn't need plugins for.
You could say the same thing about Emacs.
Wordpress provides the infrastructure. It doesn't have to provide everything and the kitchen sink.
Please read the second paragraph, too. Wordpress hasn't been about providing "infrastructure" (what does that even mean, when essentials are missing?) for a decade at least.
It means "building blocks" to build different kinds of websites: blogs, brochure sites, personal website, business site, magazine style, portal style, and so on.
You can then add plugins for the missing functionality.
Also, what essentials" are missing? I've deployed it with 0 third party plugins (at most I've add Jetpack) several times, with no issues. So?
Or do you mean "your essentials" which could be different than mine? I could not give a rat arse about BS "SEO" plugins for example, basically selling snakeoil to suckers, as if anybody ever got even a nudge above in Google rankings because of those...
I think his point is more that most of them solve issues the CMS should address directly (in his opinion) or that should be better addressed outside the CMS (e.g. SSL and caching). The emphasis in that sentence is in the last part:
> they mostly just fix boring problems that users shouldn’t even be worried about having to fix at all
And I agree, to an extent: import/export should probably be rolled into core, comment spam shouldn't be the default (although arguably this just means comments should be removed from core), technical SEO should be covered by the CMS and editor (be that Gutenberg or Elementor) and WordPress should have a built-in way to handle forms and configuring e-mail sending.
>they mostly just fix boring problems that users shouldn’t even be worried about having to fix at all
Because the problems they want to fix aren't the problems I want to fix. I don't want to send emails with Wordpress, or do polls, or whatever. If we add the superset of features to the core Wordpress it would be a 1GB install, with a team of 100000 needed to maintain it.
It's not as if it's not already one of the most full featured CMS as it is, or can be used for tons of things without anything else out of the box, from a personal or business blog, to a full featured publication with multiple authors.
>import/export should probably be rolled into core
The core does have import/export.
>comment spam shouldn't be the default (although arguably this just means comments should be removed from core)
Not having comments in the core would be controversial to say the least. Not to mention against the TFA complain ("not enough stuff in the core").
>technical SEO should be covered by the CMS
It is, for the most part. The rest is SEO snakeoil the third-party plugins cover.
>WordPress should have a built-in way to handle forms and configuring e-mail sending.
Your tone and your conflation of what I said with what I cited the author as saying suggests you hold very strong opinions on this and you're only looking for someone to argue with, not an argument, so I'll refrain from further engagement.
Your answer appears like you want to bring psychological ad-hominems about tone and personal motives to this because you don't have a counter-argument, so I gladly accept you refraining from further engagement...
I also didn't conflate "what you said with what [you] cited the author as saying". As your quoting was meant as an endorsement of that argument, I responded to it. When you quote an argument you want to highlight from an article, expect people to comment on that.
I didn't say your opinion is wrong, I said I'm unwilling to engage with it because of how you are expressing it. That may be "ad hominem" but not an "argumentum ad hominem" because there is no argumentum. I didn't say your argument is invalid because you're abrasive, I said I'm unwilling to argue with you because you are abrasive, regardless of whether you're wrong or not. Ironically, inferring that I'm trying to insult your characters or misrepresent your motives "because [I] don't have a counter-argument" is an "argumentum ad hominem".
Your first comment stated that the author was wrong to expect "exciting" plugins because the plugins he laments the existence of are "useful". I cited the author to clarify that his complaint was that the plugins are only useful because of limitations of the CMS core. I agree with the author that some of those limitations should be addressed by the CMS rather than being left to plugins.
Fine. Let's look at what you actually said:
> the problems they want to fix aren't the problems I want to fix
This seems tangential. What you or I or the author wants is probably not a useful metric for what should be a feature. The author's argument seems to be that if these are the most widely used plugins and they exist to augment or expand on existing functionality, that should be done in core so the plugins don't need to exist. You can disagree with arguing based on popularity but "I don't need it" is not a productive argument.
> I don't want to send emails with Wordpress
This implies Wordpress doesn't normally send emails. However Wordpress core has plenty of places where it sends emails (or tries to, often barely succeeding because it uses the built-in functionality of PHP which usually ends up in junk filters). Even changing the admin email address involves a confirmation email. I can see an argument that being able to provide an email SaaS backend should be a plugin but SMTP seems like a reasonable option if sending emails is part of Wordpress core's standard behavior.
> [I don't want to] do polls
I didn't say polls, I said forms, as did the author. Most websites have forms, usually at least a contact form. I'd wager more Wordpress websites have contact forms than comments and yet comments are enabled by default.
> The core does have import/export.
And yet the Wordpress Importer exists as an official plugin and is one of the most widely installed. If the functionality is important enough to have in core and the plugin is popular enough to be this widely installed, that sounds like the core functionality should be extended instead of having a plugin.
> Not having comments in the core would be controversial to say the least.
Yes, which is why I don't see it being removed. But they should probably not be enabled by default if they're prone to spam and it would be less controversial to move them out into a plugin once they're no longer enabled by default.
> Not to mention against the TFA complain ("not enough stuff in the core").
The complaint isn't "not enough stuff in the core" but "vital stuff missing in the core". It's not about adding "more stuff" but about extending what is there with what people are clearly missing.
> If we add the superset of features to the core Wordpress it would be a 1GB install, with a team of 100000 needed to maintain it.
That is a slippery slope argument and catastrophizing based on conjecture. You don't define "the superset" but it seems to include more than the author or I listed as things that should probably be handled in core.
> [Technical SEO] is [covered by the CMS], for the most part. The rest is SEO snakeoil the third-party plugins cover.
The author acknowledges the snakeoil part, however the plugins do add some things that aren't covered by the CMS. It seems reasonable to add functionality like being able to provide OpenGraph meta data to core, no?
> Are forms and email the role of a CMS?
Clearly Wordpress is not "a CMS", it's Wordpress. Are comments the role of a CMS? Arguably forms are more integral to "a CMS" than comments and comments are just a special case for it. And as I described above, sending emails is indeed integral to Wordpress so setting a proper transport for them seems like core functionality.
100% on the blog post, but as for the comments here: Don't listen to the naysayers.
WordPress is crazy popular and rightfully so, already powering 40%+ of the whole web, like TechCrunch and the New York Times. And thanks to Gutenberg and especially the newly launched Full Site Editing, this number is gonna go up even more.
Anyone who's not using it is missing out big time.
Yeah, the creaky old Wordpress setup from 2004 is still better than all the other options out there. The nerdier and more unpopular the system, the fewer the number of blog posts.
But what I mean is: you point out that WordPress is crazy popular right now (in a thread largely critical of WP) and you post a comic showing it was good in 2004, 19 years ago.
I loved decentralised forums, when search engines actually searched millions of sites that were not walled and information could be accessed by anybody without social logins and paywalls.
Wish there was a better way to preserve internet culture and activity.
I used to love visiting random blogs. Every blog used to be so different. People would spend hours tweaking themes and layouts to make their blogs unique.
Now its all centralized apps and they’re all tested and optimized to hellto maximize engagement. The Walmart-ification of the web.
I attempted to work with WordPress and its plugins in a commercial scenario.
Whenever we hit a tiny corner case with a theme, something we believed should have functioned well - The whole project failed.
So yeah I am not taking on any Wordpress projects ever again.
I just tell people to use Wix and or Shopify and don't try to run an ecommerce site, it is too difficult for them.
These are the nightmare of WordPress sites. Someone builds a house of cards out of a pile of plugins, and then I'm asked "Why might it cost $$$ to upgrade my WordPress plugins?!?". Well sire, because plugins can throw in breaking changes, and an upgrade may take 2 minutes an work perfectly, or it might introduce a corner case that breaks something. And you don't have any automated tests to detect this breakage, so someone has to check by hand. Or forget a corner-case, it may completely break part of your site because a (commercial) plugin developer decided to rewrite and get rid of a feature you depended on [true story].
I try not to touch anything beyond a WordPress landing/marketing site, but every so often one comes bundled with another project or I give in to a sob story...
This is arguably what's so dangerous about a plugin ecosystem in general. On the one hand, you can quickly implement a bunch of useful new functionality at the drop of a hat, and that's obviously incredibly useful for non technical folks.
But at the same time, you then often end up dependency hell, and realise that any changes going forward will break something or another that your site depends on, leading to many, many sleepless nights. God help you if you're one of those folks who installed hundreds of plugins, because an upgrade often meant 'revert everything to default, then hope at least some of your plugins had equivalents for the next version'.
It's why I'd recommend anyone who can do so to only use their own code for a WordPress (or other CMS based) site, and keep the third party stuff to popular plugins you know will get regular updates.
Between Squarespace and Shopify it's really hard to argue in favour of Wordpress these days, yeah. In theory WP can do everything, but it needs a full-time PHP dev (and these days, also a full-time react dev for Gutenberg) to baby sit it and keep up with vulnerabilities, incompatibilities and all the other stupidity of the Wordpress ecosystem.
You just limit yourself. I have built database-style wordpress sites with custom taxonomies/types using just my own glue code, theme templates and Advanced Custom Fields (and ACF is just there for the backend experience mostly). It's also obviously not the best choice for everything, but some of these sites I built 10 years ago and they're still going without major issues.
Unless you have a good solution in place that abstracts away the CMS, and triggers automatic (near-instant) redeploys, that's usually not a good idea.
Your marketing team(/person) will have to do many dozen changes a day on your landing pages, and you don't want them having to wait for changes to appear on the website.
A base WP setup that is managed via version-control + WPs normal live CMS is still one of the best CMSs out there IMHO.
Maybe "landing page" wasn't the correct term here.
> I would really like to see examples of this.
I almost struggle to come up with a non-example for this for any profitable tech company.
Look at the sitemap of e.g. Solarwinds[0] or Hashicorp[1]. Both have thousands of sub-pages with different marketing copy as content to capture as much organic traffic as possible and to convert paid traffic as good as possible. That marketing copy doesn't write and update itself (or at least it hasn't until recently).
If you look on most job boards you will also find many positions that contain "SEO" in their title. While some of them are more rosy "SEO management" positions, if you squint a little bit, you'll see that in practice those people spend a good chunk of their day in their CMS (likely WP) to create new pages and updating existing pages based on conversion tracking data. That also usually doesn't have a lot to do with "incompetence", as that process is rarely something where you can one-shot the right solution. More realistically you'll just have to try out a lot and see what sticks (both with search engines and people).
You probably need a headless CMS of some kind so the client can manage it. I've used decap/Netlify CMS, and it's fine, but it's clearly not anyone's priority anymore.
Someone interested in building the next generation mobile first Wordpress?
Preferably starting with a iOS App. Already checked out WebFlow and PhoneFlow, Notion, Drupal, Typo3, OnePage.io and many other Content Management Systems.
But neither incorporates the ideas that I have for a next gen CMS. If this sounds interesting to you feel free to reach out to me over at Apple FaceTime or Messages- available under hello@stefanbayer.com
After working WP for quite a few years the problem as I see it it that it 'needs' to be all things to all people. Can't code? Not a problem. WordPress.
Before even considering working with a client with a WP site I have to look at what plugins they are using. If they don't have a developer on board (or at least a competent one that built it originally) you know that that it will be stacked with 'useful' plugins. And this is the bit where the issues arise as working out the provenance of each and every one of them and whether they are still supported and/or won't break the functionality of another plugin is pure guesswork. Case in point enabling a nondescript plugin on one client's site broke the main image slider.
> MonsterInsights Google Analytics — I sort of get the idea of a plugin that helps you install Google Analytics. Really, it’s just a snippet of JS you put on the page, so I wouldn’t use one myself, but not everyone is comfortable editing theme files. Then this puts an analytics dashboard right on your site, which again I sorta get, but I’d rather just use the dashboards at the horse’s mouth rather than re-created ones
That's exactly one huge point why I do not work with Wordpress on new projects.
I use for example Contao (https://www.contao.org) because it already have everything to build a full website. Yes I also use plugins in this system but it really enhances the core system with some nice features.
To me Wordpress seems to be CMS torture and I do not really understand why so many ppl got hooked on this system.
Probably because alternatives like Contao didn't really mature until 2010 or later, by which point Wordpress was already massive enough to have user groups and conferences everywhere, and could afford to just coast by on its momentum even as the product kept getting worse and worse.
FWIW, I recently used Wordpress as a headless CMS, with a Next.js frontend that gets pinged by webhooks from wordpress to invalidate caches etc. I haven't really found any headless CMS that's easier than wordpress for non-technical users to post content. And I get to write the front-end in Next.js so I get to skip most of the plugin shenanigans in WP :)
The "top X" of any huge platform is going to be boring. While I agree with some of his criticism, the modular nature of WordPress is what makes it great AND messy. These are good things.
Wordpress gives PHP a bad rep. PHP on its own - absolutely fine when used correctly. PHP in Wordpress however, well...it's crap. They've got the most convoluted and poorly structured PHP codebase I've had the misfortune of working with.
A well maintained, modern PHP codebase is a complete non issue, but Wordpress is unlikely to ever have that.
huh, was working with wp projects few years ago daily.
what a mess the gutenberg was to transition.
For example:
They added all kinds of adjustments on to the right sidebar, font color, bg color, and many many other but no way to disable them.
No, the customer can't have these settings visible, the site will look like raimbow after one year.
Customer's should only be able to see simple bold, underline, link, h1...h5 and that's it.
It's the css that puts the right colours there automatically...
totally wrong way of doing sites with multiple people making content into them (not tech savy people)
And not to mention... the right side panel of a page editor does not contain different sizes for mobile... and to clarify, there was no way to hide those options about less than few years ago
Wordpress doesn't really have a place in a modern toolchain.
You want a blog? Pick a static website generator (eg. Cobalt, Zola, etc)
You want a CMS? Pick a CMS (eg. Keystone, Payload)
You want an ecommerce? Pick an ecommerce (eg. Sylius)
Wordpress used to be the only barely decent option, it became insanely popular and people are still using it out of inertia, ignoring a massive list of crappy defaults and security issues they need to patch up.
Doesn't have a place for who, developers? Maybe. But your average company or person needing a blog has no idea what to do with, or what even is a static site generator. Most people do know of WordPress however, and how easy it is to use.
If you're only making websites for other developers then what you say makes total sense. But I'm afraid that's not the audience WordPress is meant for.
I agree with blog and website generator. But CMS like Keystone or Payload would probably not run on cheap shared hosting. There are for example small non-profit organizations that are not going to use VPS.
I still don't get why did they had to reach for such a needlessly complex solution. A few weeks ago I tried building a small project for a client by writing bespoke blocks for custom logic and storing.
I found it was waaay easier and even waaay quicker to learn laravel to scratch than try to wrap my brain around the weird custom superstructure they built around React, their suggested approach on how you should write a version of each block for previewing, another for editing, some glue code between those that is not extremely clear how you should be interfacing, etc. Their developer guide is the equivalent of the "Draw the fucking owl" tutorial.
Even looking for exisiting examples, every one of the default wordpress blocks does things their own way, the whole thing felt over-engineered and extremely brittle.