The complicated futility of WordPress
coderjerk.com
coderjerk.com
One option is ClassicPress which has forked v4 of WordPress but I'm not 100% confident that they will stick around. Apart from that, there are limited options out there that can replace the multisite features of WordPress. All I know is that the future of WordPress will be what Automattic want to do with it and I don't think they'll care if nobody outside of wordpress dot com uses it.
Automattic could create a PluginV2 system with tightened security and new requirements for plugin developers, then put a plan in place to deprecate and remove support for v1.
They can't afford it, and most people don't want it. I think history shows that taking flexibility away from something popular because of its flexibility is not good business. At least you can install a plugin now and completely sidestep this awful 'site builder'. If that goes away, hoo boy.
[0] which were then massively refactored, twice.
> WordPress is used by 65.3% of all the websites whose content management system we know. This is 43.3% of all websites. [1]
And these numbers have been growing for years. In other words, WordPress is and will be widely used for a long time. So I’m not sure WordPress really needs saving. :p The number of OSS contributors has also been growing. So the project itself hasn’t been stagnating either.
Disclaimer: I’ve been a WordPress contributor and work for Automattic.
PHP code is not sandboxable (ignoring the ability to disable functions), AFAIK. Is it? So plugins do have complete (read) access over the entire code, the secrets in the config files, the database etc.?
Not allowing plugins to directly execute PHP code would either fundamentally break the wordpress plugin model or require an interpreter for a turing-complete "wordpress plugin programming language", right? That would kill any performance, especially on uncached wordpress instanced, even on PHP 8, wouldn't it?
People said the same about JavaScript, and yet smart people figured out ways to do it. For example: https://github.com/googlearchive/caja
PHP may be particularly challenging to sandbox, but it's not too much for talented engineers to figure out.
As a near-last resort, a secure PHP subset language could be developed.
Is this something you came up with on the spot? I haven't come across this idea in communications literature and a cursory search only brings up other types of bundling in economics/business/strategy.
I think Wordpress needs something like better defaults. You are so dependent on picking a good theme and it seems really hard to tell what’s going on in the theme world.
The overhaul that came with Gutenberg was painful and it took almost two years to catch and fix all the bugs, for example with embedded videos. But as of 2022, I am happy with Gutenberg and it feels intuitive.
I know a few guys who could never make the necessary switch in their heads and hate Gutenberg with a fury of thousand suns, though. All of them are over fifty.
Now, Substack has even more intuitive and amateur-user-friendly editor, but a much more limited set of options.
I guess that WP wants to become "one to rule them all". This means that they strive for even bigger adoption rate among users. FSE is the direction of that. I can totally understand that professional developers are feeling frustrated with the way things are going in WP ecosystem.
When Gutenberg was introduced it produced more pain that good things that it has brought at that time. A lot o money is floating around WP and investors want to get their share of the cake. Did you notice all of the investments in WP or plugins that have changed their owners?
Take a look at WooCommerce. I guess that it is much easier to do some of the custom code than to reinvent a wheel. Not to mention learning users on how to do something in a totally different environment.
Agreed, if you have a dedicated engineering team, but most non-tech companies that need basic websites don't...so in that context, Wordpress's admin UI is a big gain. It's familiar to users and provides media management functionality out of the box. The vast majority of CMSs have terrible/non-intuitive admin UIs and limited functionality. Leaving aside Gutenberg and the rest of the garbage pile that is Wordpress, the admin is the primary selling point of Wordpress IMO.
Things like copy/paste from Google docs with keeping all of relevant the styles and links works. And I guess that a bunch of users is doing that - using WP as a platform for distribution of content.
Especially when you add custom blocks specific to their site needs
Having a classic editor plugin has nothing to do with characterizing people as crufty throwbacks who can't learn new things. Many people are in the business of their business and don't care to learn the next new-greatest-software every few months.
The designer can, within the structure and strictures of Wordpress, build a site with all the whizzy things the client wants, and they can charge $X for it. A developer can do all of that as well, but they will probably need a designer as well (see above parenthetical), and it will cost $X * 2.
The counter to that is, "well, just build a good templating system and tweak that for other clients, and you're good." Which is true, and that's why there are lone PHP developers out there who make a decent living with a stable of clients.
One of the worst aspects of Wordpress is dealing with the infuriating and opaque reasons why a particular site is slow. A relatively simple site can be maddeningly slow for any number of reasons, and finding them is like searching for a contact lens in a full bathtub.
I mean, I get it. I've written some stuff that screws the pooch performance-wise, and the solution isn't immediately clear. But with WP, and with enough installed plug-ins, the reason for the slowness may simply be "in order to work with WP, there is a lot of back-and-forth with the DB amongst all these plug-ins," and there ultimately isn't anything you can do about it.
WP is amazing that it does so much and works as well as it does, but let's not pretend it's not a bit of a faff sometimes.
If performance is a real business concern (and when is it not?), hire developers, not designers.
Hire developers, not WordPress developers. Because the latter will push WP onto a project where clearly the downsides, like performance, outweigh the benefits. But the latter may pick WP when it is a good fit.
Here's a question: suppose that you want to use WordPress as a starting point for a CRUD app with some basic permission controls, the ability to dynamically add content and maybe even write your own search logic which respects those permissions.
Example:
1. Upon opening your site, you'll be presented with a list of Foos
2. Each Foo will have a description, a configurable amount of maximum Bars, and a summary of how many Bar instances have already been added, as well a location on a map below the list (a pin, think Leaflet.js)
3. Upon logging in to the site, you'll be able to open each Foo and see all of the Bars under it
4. In this list you can click on a Bar to open its view, which shows all of the data added it: typical stuff like text, numbers, dates, times etc.
5. With the appropriate permissions, you can either edit the Foos/Bars that you have access to, or edit all of them as an admin. As a user, you can only view them.
(just an example that i made up, vaguely like a CRUD that i created in PHP with one of the regular web development frameworks)How would you go about that? Are there any resources that you would recommend?
For example, if one were to use Slim, they'd look at their documentation: https://www.slimframework.com/docs/v3/
Similarly, Laravel has pretty decent documentation for developers: https://laravel.com/docs/8.x
Whereas with WordPress, i don't think that there is such an informative, guided resource for implementing things like that: https://wordpress.org/support/
A lot of it seems to focus on how to maintain installs of WordPress or how to work with its built in concepts (like pages/posts/etc.), but there's nothing along the lines: "Here's how you're supported to mess around with its internals in an idiomatic way and introduce custom views, validations, persist the data in the DB and add whatever you need to cover what constitutes a business process". Maybe i haven't dug inside of it enough.
Are you just supposed to hack things together with a custom theme or custom widgets, custom post types and storing most of the information into custom fields that are attached to the post? Why does the documentation have such a lack of PHP in it, then? Is there a separate set of developer docs somewhere?
Actually, i wonder if there's some super lightweight boilerplate theme, that attempts to do almost no styling and has very basic layouts, to be used as a boilerplace, e.g. what the likes of Skeleton are for CSS: http://getskeleton.com/
We're working on switching to wordpress for the volunteer organization I work at. Right now all the "information/kinda static" content is on wordpress with pages and posts. Its a win, anyone with permission can edit. Our custom application isn't there and has its own separate database and code. We're thinking of moving the whole thing into a sort of plugin, but we're very symphony based.. Which we like
This is a nice approach - getting to leverage WordPress for the typical use case at which it is good, using something bespoke for the more advanced use cases. I've actually done something a bit similar in the past (the particular app i made used Lumen which is essentially stripped down Laravel, but the concept was close enough).
It's just that many made WordPress seem like a pretty much universal tool and while i've seen some pretty advanced things be done with plugins, i personally didn't quite feel like it's well suited for certain tasks where you'd typically reach for a general purpose web framework instead.
The PHP side of WordPress has been very stable for over 5 years at this point. All the new stuff is happening in JS unfortunately...
Slim and Laravel are both proper application frameworks specifically designed for your use case. That's why they properly document all of the CRUD use cases. However, they don't do CMS stuff at all.
If you absolutely need a working CRUD app to live inside of a CMS, then your best bet would actually be a Drupal module with a custom entity type. However, that requires you to actually know the ins and outs of Drupal's Entity and Field APIs, which are rather overengineered[0]. On the other hand, if you do manage to figure all that out, permissions are relatively easy to hook up, forms are just filling out an array, and you get Views support basically for free.
[0] In Drupal's defense, they're a CMS, so they need to support use cases like letting users define custom node types and custom fields on those types. This makes the interface for interacting with Entities way more complicated than an ordinary CRUD app needs.
This was also a sneaking suspicion of mine after diving into some plugins and seeing how they work, e.g. things that definitely aren't pages/posts beings stored in those tables in the database regardless, hinting that maybe the base functionality needs to be stretched out a bit for custom use cases.
When we picked WordPress back in ~2012 as our CMS it was because of how simple the editing of post/page content was compared to the alternatives. The majority of our content editors are student assistants, graduate assistants, least tenured faculty member, etc. People who aren't that technical and also have a dozen other things that are their actual job, unlike updating the departmental website which just got dumped on them.
We've done a ton of work with our theme and in-house plugins to keep WordPress super simple/basic for them, overwriting and undoing a lot of what core has added over the years. Most of the site editors find Gutenberg too complicated, so we're running the Classic Editor plugin in a ton of our sites. Our content editors just want to come to a CMS, have a text box where they can add content, add heading tags, links, images, use some of our shortcodes (from custom TinyMCE buttons) to add some styled components to their page. They don't want a full-site editor, they're not remotely qualified from a UI/accessibility perspective to be messing with anything really than just the base content of the page.
There's lots of options if you just want Markdown but this isn't enough for heavily branded business websites where you need to check how complex pages will look before they go live, like if the h1 text in the header line wraps weird or is hard to read against the header background image.
Edit: I get that CMS projects need to make money by the way but the lack of vendor lock-in is a big upside to WordPress.
Netlify CMS might be an option (https://www.manuelkruisz.com/blog/posts/custom-previews-next...)?
https://www.sanity.io/studio is open source, but some parts of the CMS aren't I don't think.
Possibly there could be an adapter to use Sanity Studio w/ Strapi?
https://strapi.io/pricing-self-hosted "Free...Up to 3 default roles"
https://strapi.io/blog/introducing-strapi-enterprise-edition...
Sanity.io doesn't seem to be fully open source: https://github.com/sanity-io/sanity/issues/978
"You can only run the Studio connected to the Sanity hosted backend. There is no option for connecting the Studio to another backend."
If you want a wordpress replacement though, there will be a big learning curve as it's a general-purpose CMS, not specifically for blogs.
What features does that impact?
If the only limitation is 3 roles apparently, then admin, manager, and writer could be acceptable for most companies.
If you're wanting a bit more flexibility from a code-perspective (and you don't mind TypeScript), I've found Payload CMS to be a great option to build out a page builder as you've described using their "blocks".
https://github.com/payloadcms/payload/blob/master/license.md - "Payload is free to download and install—and free to use for Personal Purposes. We are passionate about Payload, and we hope that you will enjoy it, too. A valid license is required to utilize Payload as detailed below"
https://prismic.io/faq/product - "Proprietary, not open source"
Would this model work for you, or would you like to see changes to our current model?
Can you explain how the licensing works here? If it's open source, couldn't you modify it to allow more admin panel users? Can you self-host with no reliance on other hosted services or paid licenses?
If combining with a static site generator you can find craftcms hosting for $5/month.
I understand that open source things can increase reach of the product, but that's at the expense of proper software support.
Let's accept some proprietary software in our lives. Sometimes these have demostrated technical superiority.
Lots of open source projects offer premium support.
> Let's accept some proprietary software in our lives. Sometimes these have demostrated technical superiority.
Sure, but let's not pretend proprietary vendors know more than open-source projects and contributors. Also, if your product is ultimately the content itself, it's an enormous risk to hand that over to third parties that want to take control of it. You are explicitly coupling yourself to the success of the proprietary software vendor.
And yes Craft’s schema is pretty complicated.
(And while not particularly “Crafty,” I use a paid plugin, Doxter, to manage my CMS code in Markdown, with the use of shortcodes.)
The performance issues mentioned by others are realistic, but if you put it behind CloudFlare, they’re totally reasonable. While Ghost is a much more popular use case for newsletter publishers like myself, I prefer the customization capabilities of Craft to forge a CMS experience I’m comfortable with.
You could run a dev server and port forward the preview if necessary.
I'm not affiliated with them at all. Was just very pleased to find how polished it is for a self hosted, free product compared to the other $499/mth proprietary options in the space.
They have pretty useful API parameters for transforming images. But my initial instinct is to say that you'll have to do custom data processing in the front end or somewhere else, since the API it generates just mirrors the structure of your database. The nice thing about this approach is that you can always remove Directus from a project and your database will function as normal.
They also have pretty use docs which you can check out for your usecase:
https://docs.directus.io/reference/introduction/
edit: I should also add that you can add your own custom modules, but I never really explored that too much.
Don't think there are live previews, but I might be wrong (people can create custom modules, like plugins, and I haven't checked in on it for a year or so).
One use case we made is a place where a non-tech savvy marketing manager at a chain of retail stores can enter/edit the store info & deals for each location. Then the info & deals then get updated on the stores' app, website, and on site displays from a single UI.
Wikipedia/Wikimedia does not have nesting: each page/topic is its own top-level article without hierarchy. Meanwhile BookStack, another open source wiki platform, does have hierarchical organization.
https://docs.stackbit.com/conceptual-guides/modeling-storing...
You basically run "lektor serve" edit your site locally in the backend and then once you are done you click "publish" in the backend and it copies the site to the webserver via scp (provided you have the ssh credentials).
Simple and effective. For anything more sophisticated I use grav CMS
It’s written in modern PHP and provide a simple UI to edit an manage your site. No database is needed.
WordPress with a plug-in that spits out the static site? E.g.:
* https://wordpress.org/plugins/simply-static/
Edit/update via GUI, generate the static site, view it locally, rsync it to your hosting provider.
I feel like this is an unnecessary and inflammatory swipe, typical of coder-bro culture. Both Drupal and Wordpress are open source tools that have survived for years, are built on tested and long-lasting languages, and serve the people who both build and use them.
Everyone is always crying about how nothing ever stays the same, and and the same time, how the-next-new-thing-ism is ruining the web. And then there is this comment thread with every other response trying to push some ostensibly better and easier thing that stands no chance of surviving more than a couple of years, because CMSs need communities to keep them alive.
I am a proud member of the Drupal community. I struggle with it sometimes, but it is still amazing at how much you can accomplish with core and contrib modules. And don't forget, some organizations need a giant, clunky CMS. We're not all building websites for cutting edge, VC-backed, brochure-based unicorns. My clients need a framework that has legs to stand on for the next decade to come.
It's a reminder that if you build something that people really want, how you build it doesn't matter, as long as you have plenty of duck tape at the ready.
https://www.cvedetails.com/product/4096/Wordpress-Wordpress....
Just for what it's worth, I haven't experienced any intrusions at all on my WordPress site since moving away from a free shared host 3 years ago (and even then, I don't even think WordPress was the culprit there).
"SQL injection due to improper sanitization in WP_Meta_Query", fixed in WordPress itself:
https://bugzilla.redhat.com/show_bug.cgi?id=2039317
https://github.com/WordPress/wordpress-develop/commit/c09ccf...
Plugins are categorized separately from WordPress on the CVE website.
I think a lot of CMS stuff start at first principles of "OK you need posts, and all this other stuff" but really Wordpress seems to be currently structured around the realization that the hard stuff is all the things that aren't shared between WP instances.
I don't care about billing random hours to fix a footer. If anything, I program all my sites so that global options like these are ALWAYS easily editable by the customer. That's not my business model.
It's just frustrating when the user wipes an entire section, because they decided that "oh, I can change that font here".
Despite recent changes, Wordpress remains the best choice for the type of websites OP and I are building, I believe. That said, I would absolutely pay for a Dev version of Wordpress mantained by Automattic that would get rid of all the "easy to use" fluff by default.
With a user that has more power than what they understand, they will break the layout and blame the developer. You then have to go look at what they did.. and as it is in a GUI and not in code, it will be much harder to troubleshoot and thus fix for a reasonable price.
My clients fuck up their WordPress websites all the time. Revisions and incremental backups solve that issue. Nothing we can do to stop an adventurous website owner on a Friday night after 2 glasses of wine.
Thankfully most of my clients stick to what they do best: run their business and leave the website editing (not content creation) to us.
WP is trying to head off Wix and other "full site editors". I don't blame them but I won't use the new tools as I've already implemented my own solutions.
I’m thrilled they’re lowering the bar to manage sites and stay competitive in the marketplace. It’s enabling new businesses and filling a fresh pipeline for us.
WP isn’t limiting us at all. Build pipelines, bundlers, edge workers, js frameworks. It’s all the same. I don’t have to try to sell the advantages of a new CMS. And as a bonus, we already speak the same language as I’m building them a tailor fit WP that they’re already familiar with.
I consider myself fairly decent at design (though I'm far from an expert), and I was amazed to see how at odds virtually every theme on there was with what I consider good design, particular from the UX perspective.
Most of them are so bloated they take forever to load and they have an absurd amount of animations.
I've just given up on the idea of taking the easy route here, I can't in good conscience have the first look that people have of my business be a bloated, over-animated mess. Gonna have to build it from scratch.
If anyone has found themselves in a similar situation I'd love to hear what you did.
Developing a marketing site by hand is almost never the right choice for an early-stage startup. Pretty much everything else on your to-do list is a more useful thing to spend your time on than hand-crafting a marketing site.
As for why you would choose them over WordPress, please just read the conversation. I was replying to somebody who had already tried to start with WordPress and gave up on it.
Part of being a good dev is knowing which tool to use (and when to not use a tool) and how to get the most out of the tool.
I don't think that it's very economical to provide smaller instances than that for most cloud hosts out there.
The WordPress download is 20MB compressed, 63MB uncompressed, containing almost half a million lines of PHP spread across over a thousand files (~16MB; around 55% code, the remainder blank or comments), over half a million lines of JavaScript in over 500 files (~25MB; around 67% code), a couple of hundred thousand of CSS in 700 files (~7.5MB; around 75% code), and the odd spot of other languages. (This is in languages where more code fairly directly means slower, even if faster code can claw that back; whereas in compiled languages, more code just means slower compilation, and runtime performance is comparatively uncorrelated.)
That’s not particularly lightweight.
Conceptually WordPress isn’t lightweight, either. I’ve never used WordPress myself, but I’ve seen three people using it, and in each case they were being drowned in choices and data fields, using two or three fields out of the thirty or more fields it was shoving in their faces; and the themes and plugins and such made matters considerably worse and more complex; and a lot of that complexity didn’t seem well-structured, though my observation has only ever been brief.
And this misses the point. Many/most businesses gain zero business value from a website.
Most businesses don't need a bespoke website. They need a website that looks like every other business website, allows marketing to throw a new whitepaper up every couple of months, and maybe allows people to send marketing/sales an email from a form.
That's it. Nothing more.
Most businesses don't need a $100,000 website. They don't need an optimized UX experience. They simply need a "good enough" web experience because not having a web experience is considered a faux pas even if your web experience is a gigantic waste of your time and brings no value to the business.
A Wordpress hosting company is perfect for this.
I've done several websites at the low 6 figure range.
I've seen a lot of work go into fine details. To me that's fair: good design is just a lot of tiny tweaks iterating toward something simple, and that's what the designer I work with does well. If that makes the people we're working for feel good, then yay.
If it helps, most of that cost actually goes into data modeling, migrating/ cleaning the data, training users on the admin system, or connecting the site to an ERP and writing functionality to render that data. Or requirements gathering, process documentation, publication strategies, or whatever.
Another side is that most of the off-the-shelf stuff I see won't pass our a11y audit. Which is important to me not just from an ass-covering direction but because I really think that blind folks ought to be able to use the web.
As to the author's point, just locking down what users can do should be good enough. I've been crapping out WP sites in an hour for my musician friends, and my hope is that full site editing gets good enough that I don't need a theme, just a good plugin.
But yeah, in general you're right. I tell folks that they should concentrate on finding some good content, and then the rest of the crap doesn't matter.
I've seen it happening a thousand times: businesses asking for extremely intricate websites (despite better advice), only to fail to deliver the content they needed room for and having to hire copywriters for fluff. At some point they don't care about money anymore, it's all about the thrill of the bike shed.
The reason why it's bigger than other publishing tools, is because there's almost nothing out there that has the deep network of plugins that can do almost anything.
Sure, the backend of spaghetti PHP, HTML, MySql and endless backdoors and security issues are a nightmare, but there are really not that many alternatives to what Wordpress can do.
And that's why Automattic is doing such a good business by basically hosting Wordpress and cleaning up and whitelisting more and more plugins. It makes perfect sense.
We tried to implement a plugin where Events in WordPress would be triggered, evaluate Conditions and then execute Actions (Send email, Trigger Webhook at Zapier, Update fields over the triggered record, etc.)
Turns out, WordPress is not architecturally ready for this much evolution. And that's when we got disenchanted from WordPress and went to hunt on anything else.
You are basically describing how every WordPress plugin already works via filters and actions (collectively referred to as hooks).
It's impossible to differentiate "Create a post" event from "Update a post"; they propagate the same event. Every minor change on the post also triggers this event type, along with others. Therefore, leading to scenarios where "On post creation" and "On update, this field of this post" would lead to the same workflow triggered. As an Automator, you don't want to trigger the same workflow for another event that you didn't intend to. Our idea was to use the Conditions to judge if this workflow would run or not, but...
We hit another roadblock; another issue was that when an event is triggered and conditions are to be evaluated, WordPress doesn't include in its payload the previous state of the fields, so if you want to do a "diff" (so you can tell which field values change) you then have to store the current state somewhere to be able to do such a "diff" to compare.
We then had two roads:
- Re-tool the core of WordPress with the functionality (with a lot of PHP hackery) that would enable us to run workflows the right way.
- Relying on the existing API and end up with the same feature set that Uncanny Automator plugin currently has.
So, instead of reinventing the wheel, we just dropped the idea.
`post_updated` passes the old and new values: https://developer.wordpress.org/reference/hooks/post_updated...
I'm the author of a sizable WordPress plugin (in terms of LoC and integration with WordPress) and nothing you are saying is making any sense to me.
When the function is called, all of these hooks are triggered. To identify what the user was doing (post creation on the first time? post updated? is the status being updated?), unless you have many conditions (potentially nested ifs), it's a cumbersome job.
For example, a user wants a workflow every time the post is sent to the Trash. When a post is sent to the Trash, three things happen:
- A hook is triggered because it's sent to the Trash.
- The updated status one is also triggered (Published -> Trash).
- The Updated post one is also triggered, because yes, this is an update.
Yes, these are different hooks, but these do come from the same function. We tested two other plugins similar to ours and found minimal automation capabilities; we speculate this is because of the reasons I just exposed.
If you check out the source code for wp_insert_post(), you'll find many do_action(). When clicking the "Add Post" button, the post is created at that moment (so it can reserve the permalink, etc.); by the time you save the post for the first time, in reality, it's being updated, not saved for the first time as one would believe.
This is just a single example, but these software design decisions make it not that straightforward to create an automation plugin. By the way, that function calls many others inside, functions that trigger hooks by themselves; therefore, you'll have many workflows trigger attempts many times per second, just by saving the post.
EDIT: Clarity.
--
[0]: https://developer.wordpress.org/reference/functions/wp_inser...
Check out the source code of wp_insert_post() [0] on line 4407, you'll see three hooks that trigger: "edit_post_{$post->post_type}", 'edit_post' and 'post_updated').
Then after that, these other ones trigger unconditionally: "save_post_{$post->post_type}", 'save_post' and 'wp_insert_post'.
For the cherry on top: wp_after_insert_post() is called, with several other hooks on their own.
Try to evaluate each configured workflow whenever every one of these hooks triggers. Your WordPress installation will get slow in no time.
Somebody designed this function this way, and that design is inhibiting effective WordPress automation.
--
[0]: https://github.com/WordPress/wordpress-develop/blob/5.8.1/sr...
This "hacked-together" situation is not their fault in the sense that they have lacked engineering. I'm sure Automattic has some world-class engineers there. However, their codebase lags by years because of their legacy users. From a business perspective, they are hands-tied because any breaking change will bring hate towards them.
Their userbase is too big to make any significant change, and Gutenberg already fragmented their ecosystem badly. They will need to create a new next-generation product from scratch, just like JetBrains does with Fleet instead of IDEA.
For a more technical answer, I already gave detail at: https://news.ycombinator.com/item?id=30185809
What "backend spaghetti" ? What endless backdoors and security issues? https://www.opencve.io/cve?vendor=wordpress&cvss=critical&se...
I also want to add this is a good example of why marketing should probably just be using tools like Insta, Twitter, FB etc to get their message out. Now if you actually have a good company blog w/ good resources than that's different but I think that's more the exception than the norm.
Would you be willing to elaborate this position? I disagree that only being on social media is sufficient for marketing a service/product/organization.
Social media channels can be used to link content to a website, where there is far more control over how the information is presented (e.g. with embedded documents, testimonials, contact forms, and more pictures that can't be added as easily to sical media). You also have more control over the content on your website, on the low but real chance that you lose control of your company's social media accounts due to an unexpected reason.
So if the marketing team at acme co want to sell customers on their new line of coyote-seeking anvils, what is the point of having a website if they can't update the site with all the features of the new anvils? If they can only put the updated copy on Facebook and Instagram, then they will actively avoid linking to the site, since the copy there talks about the v2 anvils that don't have the new vision based coyote acquisition targeting system.
I've worked in similar roles, and I don't like having to always be involved every time marketing needs to tweak the copy on a page. However, that led me to improve the site infra so they could make those changes themselves rather than wait for a developer to do it for them. And unsurprisingly, removing the forced delay and friction allowed them to vastly improve the page, sales noticed that they were getting more inbound leads. Turns out that having to reach out to another department was causing marketing to delay or cancel minor changes since "it didn't seem like a big enough difference to bother IT with". Telling marketing that they should only be using social platforms sounds like a good way for a developer to talk themselves out of a job, since then accounting will start thinking "why are we even paying this expensive salary if our customers aren't even visiting the site?" Sure I have the engineers typical disdain for marketing, but I do realize that it is a useful function and a necessary evil.
Personally I found Drupal to be a much better system for their use case, to provide client 'content editing' that does not disrupt the front end design (allowing user to edit content but limit novice users changing styles or branding).
Drupal has got quite a lot better over the past few years but gets overlooked as it has a bigger learning curve.
Anybody can create any kind of module for Drupal, but in the case of the Gutenberg and NFT modules, only a small minority of sites are actually using them.
If someone at work told me "yeah you could write an ERP in C# ...but excels ecosystem is just so much greater" then I'd be a bit confused.
It’s a malleable tool, but at some relatively early point you’re fighting against it more than you benefit from it over something like GP suggests. Just slows you down and erodes confidence.
WP is best if you have no or limited dev resources.
Honestly, I was skeptical of Wagtail before developing blocks to work with their StreamField concept and diving into how clean and clear the Python models can be written as well as how all the data is clearly typed. Our team has decoupled implementations where we use Wagtail's GraphQL API and a modern Javascript frontend, along with traditional Django template driven sites. The ecosystem for Wagtail and Django is larger than you may think, but you are correct it that may take a few weeks to build out some integration that could have been plug-and-play in the WP plugin ecosystem, I usually take weeks to vet any off-the-shelf plugin and look into all of its code anyways.
> the ecosystem of WP seems to be a magnitude greater
Define "greater", right? WP has more plugins, but many of them don't work, or are vulnerable, or throw in a bunch of random messaging and nagware, or slow down the site. In one sense, the Wagtail ecosystem is a lot smaller but what's there is of a higher quality. It's the old "Macs don't get viruses because they don't have the market share to warrant the attention" phenomenon.
You can touch your nose two ways right? You can just reach up, or you can contort your arm and reach around your head. Working with Drupal very much felt like the latter.
I had to jump through so many hoops to do everything. Just one example: If I wanted to turn off a Preview button in one part of the site, the code in that view had to check what application was running, or ALL the preview buttons in the whole site would disappear (i.e. there was no app scope). Drupal databases were hairy balls of complication, but that's the case with every system I've looked at that has to support "every" use-case.
With Django you just build what you need and you're done. It's very straightforward. Your code and your data model can stay really simple. I built out whole sites really fast with it, even when I was a relatively inexperienced developer.
It's not about the size of the ecosystem, because with a tool like Django it's really simple to just build what you need yourself.
That said, this model works best if you have access to at least one developer. If you're not willing to cough up for that, you're at the mercy of things like WordPress.
A few years ago the CTO at that media company looked to slash costs. They have a bunch of newspapers all over the world, and they had just acquired an Indian software development agency with experience in WordPress.
You can see where this is going.
Soon, a programme to launch WordPress globally to every publisher as their CMS.
But of course you would be allowed some flexibility. You could bring your own CDN if needed, you could bring your own frontend to read off the API, you could harness some identity management system for login, you could even build your own content store.
At that point "using WordPress" just became modifying Gutenberg. I feel sorry for the staff still there who have to constantly fight against Automattic's clear direction in building a Squarespace competitor, to build a tightly locked down and limited editor against the frustrations of the rest of the WordPress ecosystem.
WordPress is great, if you realise what WordPress wants to be, and don't fight that.
This is not the case at all. The HTML generated by the core blocks is much cleaner than what is generated by most page builders out there, and the new (site) editor just makes use of them.
However so much of what this author says resonates more than I care to admit. I have a good relationship with WP but I worry about the future.
I remember doing a lot of work with customizations integrating WP and phpBB specifically, which ended up earning me an unreasonable amount money for a 16 year old. I have a certain fondness of WP but it’s heyday has long past coinciding with the abandonment of the independent internet. I greatly worry about its future mainly because it’s demise would represent the end of an era.
Perhaps the backlash to centralized social media will provide an avenue for a platform like WP to see a resurgence, but Automattic would really need to make a conscious effort to pivot with the changing times if they want to ride that wave. It won’t be the Wordpress as we’ve known it but (hopefully) the ethos remains. I wish them all the luck.
I'm working on a site right now for a big company that's moving to VIP. We have 7 plugins, 2 of which are from VIP, and then 4 that the company I work for wrote and now maintains for use across all of our clients. Everything else is custom. The theme is 100% custom.
When orgs choose WP, they do it because they want the interface to reduce training costs, and the platform to reduce dev costs because they can take that codebase to dozens of different consultancy agencies and have them pick up where the last people left off.
Whether it's there or not, I have no idea; I only use WP for my personal site, which runs on templates I kludged up myself years ago. But my less-technical friends? If they have a site it's usually something built with some kind of sitebuilder. Gutenberg's trying to serve their needs.
I recently upgraded my WP sites to 5.9 and nothing really changed at all. Because the theme I'm using does not opt-in to full site editing. This whole post seems to be a knee jerk reaction that isn't based in reality.
TLDR: Nothing has actually changed for this person or their clients
If you can make a powerpoint presentation with MS PowerPoint, why can't you make a website that way?
Sure page builders reduce the need for a FE dev, but then the user needs to understand CSS. Is that a win? Pay someone else $100? Or spend half a day trying to figure out CSS? I see basic questions in (FB) WP groups all the time.
And what about UX basics?
All that said, and to your point, from a web vistor pov, most sites are too bloated, too complex, etc. And all that visual shite on your small screen? Who wants that??
Current solutions are far from perfect but I never want to go back to that.
Do you ever publish your web content as PPT? Written a web app using PPTX?
Maybe we can make websites as easy as powerpoint? If we can't make it work with HTML and CSS, maybe they need to go?
I'm not saying we have to write all of it manually, but if you want to easily integrate it with other systems (php scripts,, templating engines, ...) it needs to be human readable.
Dreamweaver, contemporary with FrontPage, took a better approach and was loved by many designers much longer (tho by now everyone probably uses Sketch and Figma).
(My best guess is that -- content management systems inherently suck, and that Wordpress is one of the few successful ones precisely because it did not set out to be a content management system.)
> Every year that passes without extinction doubles the additional life expectancy. This is an indicator of some robustness. The robustness of an item is proportional to its life!
"The Lindy effect proposes the longer a period something has survived to exist or be used in the present, it is also likely to have a longer remaining life expectancy"
Writing PHP isn’t that hard!
I've been pretty happy with Gutenberg. It has some pain points - notably around block recovery - but it produces sane HTML, its CSS payload is minimal, and there's no frontend JS at all (at least in the default blocks).
You don't get the millions of features of those other editors, but it's those same features that make them slow and cumbersome. I think Gutenberg strikes a good balance. It's the first page editor I don't hate.
Please do not invoke the Amazon Godz, who will take this open source stack, spread it across a score of services, shoot it full of IAM, and give us AWS ProwDress.
> Sites that have been painstakingly, designed and built, reviewed and refined to the last detail every step of the way with stakeholders on the client side, optimising UX, legibility, performance and upholding the client’s brand can now be squelched in an instant by someone 3 months into their job who prefers yellow.
Completely agree. Back when I was building w/ WordPress, ACF was the best choice for building layouts because you could provide only as much flexibility as you wanted the client to have. You could give them lots of power to easily update their content but constrain their ability to ruin the design. I gave a short talk at a WordCamp about this exact benefit of ACF over page builders (at the time).
We ended up hiring a student who just typed the solution himself...
"From the beginning [using wordpress for complicated non-blog sites] has felt like a hack – WordPress is, and always has been a blogging platform at heart," but once WordPress decides to "pull away from this use case completely" [wait, what use case?] to "move the platform to a fully fledged site builder"... that's the problem? Because it sounds like they're intending to be moving toward the OP's use case, not away from it?
Can someone explain what i'm seeing as tension here?
Blogging
> toward the OP's use case
No, they have moved toward general purpose site building, not focused on _blogging_
Did I misunderstand? I don't think so. OP says:
> I build websites for a living. Lots of them. These websites are designed by a team of designers who design complex, bespoke, heavily branded layouts. I take those designs and my team of developers and I turn them into corporate websites, generally for medium sized industrial clients.
> Sometimes the websites are big brochures, sometimes they have complex functionality. Sometimes both. They run to hundreds of pages and posts, composed of multiple layouts, templates and using, typically, 20 or more discrete modules, each configurable in multiple ways by the end user when the sites are ultimately turned over for the marketing staff of these mid sized companies to edit.
> Many of them use WordPress as a CMS. From the beginning this has felt like a hack
OP does not describe what they do for a living as blogging or providing blogs. I see OP saying that they always used WP as a general "CMS", for "websites" that may be "big brochures" or "have complex functionality", which are not mainly blogs. Right?
To answer your question, though - I believe OP's major concern is that the direction WP is heading gives the _client_ more control over the website structure and design rather than the original designers & developers. Making it less useful for their more rigid requirements and corporate environments.
I don't think it's fair to say the core team isn't doing much to improve or prevent degrading performance — they performance-test every PR: https://developer.wordpress.org/block-editor/contributors/co...
There's also a performance team (for general WP performance, but also covering the editor/JS) that meets regularly and posts minutes. https://make.wordpress.org/core/2022/02/01/performance-team-...
Page performance from sites made with WP's block editor is pretty good compared to other editor plugins too, which probably matters more than editor performance (more people generally read a site than write it): https://wptavern.com/gutenbergs-faster-performance-is-erodin...
In 3 years they haven't fixed a simple issue like backspace jumping. For example, if you write a paragraph, then backspace to clear it - when the block is fully cleared you jump back to the top of the page rather than the block above it.
In other words, Gutenberg is not native to the editing experience. It's actually laughable how bad it is if you look at something like Ghost[0]. It's day and night difference in editing experience.
Another example is when you start adding "blocks" like CTA buttons and such. Why does the editor need to constantly render those elements in the editor itself? It completely bricks the writing experience. And I tried a lot of things, including switching browsers.
Some of my problems were resolved by removing plugins, but overall I have just decided to use Classic Editor[1]. I can, at the very least, write out the entire article and then switch to Gutenberg to style it the way I like.
It's stupid, but at least it works.
[0]: https://ghost.org/
Perhaps, but it's never been a great idea to use editor plugins at all.
> There's also a performance team (for general WP performance, but also covering the editor/JS) that meets regularly and posts minutes.
Gutenberg is about to enter its 6th year of development while the performance team has only just formed and is yet to contribute anything meaningful in this capacity.
Rant incoming...
I would love to be involved with the performance team (it's what i've done for 15 years), but the problem of funding open source comes up. Key members of the team are Google employees and therefore paid to work on it. I by contrast am a solo developer with responsibilities, and every hour I would spend on the performance team is one that I can't spend on earning money or with my loved ones.
And in the end who benefits from the performance team? Every business who needs better performance. Automattic for not having to fund the work. The incentives don't align.
I say this having written a plugin that speeds up WordPress AJAX requests by 30-95% (dependent on the request). I'd love to open source it and it'd be an ideal contribution to WP... but it's taken a year to get this far and there's more to come
It works, and I appreciate that it’s free but I’ve always hated working with it.
If someone made a node based equivalent (so I can at least use a modern templating language) that supported comments I would be all over it.
The commenting system is the only real reason I stay. There’s nothing else I can find that doesn’t necessitate stitching multiple services together just to get commenting that I can find.
And as for being able to spin up a local dev version for casual edits — horrid DX! I wonder whether a big reason social media has stolen our online interactions over the years is because there are few (no?) blogging platforms that support comments?!
Wordpress atm is the quickest way to whip up a website for any objective needed.
Bullshit.
Static HTML template + Azure Static Web App/Netlify/... is definitively faster and cheaper to setup.
I am a developer who runs multiple wordpress sites for small businesses.
What about Netlify? I've seen and heard about generating static websites, but honestly I have no idea where to start, what technologies are needed, how easy or how hard it is to explain the customer how to edit their own websites once ready..
That's why you set the intern's role to editor.
edit: ah, it's a laravel package.
I think there are more productive alternatives for most people like Kirby CMS, Craft CMS that have great docs and focus on the CMS part very well.
I had to severely lock down most of the functionality to keep them from shooting themselves in the foot and it reflecting bad on me.
I cannot even begin to fathom the level of cringeness from this assertion. If you think like this you should not be doing client work.