WordPlate: WordPress on Composer with sensible defaults
github.comJust reading this again gives me a backflash of the horrors of working with WordPress. If you haven’t seen the source, you don’t know just how god-awful the code is - and it just won’t die, because of all the ecosystem traction it has.
Even the PHP developers have chosen to ignore WordPress in language evolution considerations, as the WordPress community refuses to do accept kind of progress for their project - they still use the unsafe, outdated mysql-API without parametrised queries, for example.
Whatever you do in 2023—if you can avoid it, don’t use WordPress as a CMS.
There's much more to WordPress than the ecosystem. If we just think of it as a legacy tool that is only limping along because of the plugins, we will forever be perplexed that it continues to exist.
WordPress is the FLOSS alternative to Wix et al. It is the only practical software that enables people to create and self-host an online presence without having to type a single line of code, and without being beholden to a large centralized platform.
No, a static site generator that requires knowledge of Markdown and a few lines of bash doesn't count. A CMS that requires you to hire a professional to even get started doesn't count, either. It might seem strange to developers like us, but there are lots of people out there who are simply allergic to code. They can use PowerPoint and maybe even Photoshop, but show them a blank terminal and they'll just freeze. WordPress, on the other hand, can be navigated with a bunch of point-and-click, drag-and-drop, buy this and add that and change the options a bit. Just like PowerPoint, it barely works, but it works.
Very few people in our startup bubble seem to care about these "I want a website, but no code please" people, and when we do we often treat them with contempt. How hard can it be to copy and execute a few commands, after all? But apparently that market is large enough to attract a sustainable ecosystem of plugin and theme sellers. WordPress has this market completely cornered. It won't magically disappear just because it's built in crappy code. Understand the users, on the other hand, build a good alternative, and that billion-dollar market might become yours. :)
php's success is tightly connected with LAMP, namely apache mod_php and mysql/mariadb.
it wouldn't be hard to put together the base of wordpress in python on top of django. but hosting companies for decades cared only about mod_php and had no one click uwsgi/fastcgi solutions.
although this still doesnt answer why wordpress became king of the hill in the php ecosystem. was textpattern/drupal/joomla/etc that much worse/harder to use?
in the end wp just looked a tiny bit more professional and an easier name to remember for the masses. this technical dept will be paid for many years to come.
Anecdotally, yes Joomla and Drupal were much harder to work with and get them to look "nice".
Using other static website generators and CMS would be easy, but I beg to differ with Gatsby, Sanity, Vercel and more.
1-point-click installations failing, to failing standard templates, tutorials that are only for version 2 and not 3, because that's a video right now.
Talk is cheap, but execution is where it is.
> Understand the users, on the other hand, build a good alternative, and that billion-dollar market might become yours.
Isn't that the entire point of Ghost?
The installation guide for self-hosted Ghost assumes that you have at least a virtual private server, and gives you a bunch of commands to type into a root shell. By that time, you've already lost 90% of the people who would have chosen WordPress.
I thought Ghost was pay only?
Its written in node js though right? You can run php and mysql almost anywhere you want. Even the most basic hosting setups are pre configured for this. Apache is preinstalled on most cheap shared hosting.
That's the thing.. if you want to take down wordpress it should be something current wordpress users can easily install on their current hosting with zero extra config to do. No terminals no server settings to deal with.
A wordpress install is literally drag and drop the files onto the server with ftp and open the web address. Enter some details for the mysql dB via a ui and that's it.
After that there are thousands of themes and plugins that let you do anything from ecommerce to a drag and drop blog without much effort.
The "run everywhere" advantage is eroding. These days you can get container based hosting that can run anything for cheap too. It's not quite as easy for the non-technical user yet. But I suspect it will get there.
Even developers and tech people are having difficulties with installing Wordpress, but that's just my experience. So I don't think it's that easy.
> WordPress, on the other hand, can be navigated with a bunch of point-and-click, drag-and-drop, buy this and add that and change the options a bit.
Can it? I can write code but I'll be damned if I can figure out how to make something that doesn't look like a fourth grader in an Intro to the Internet, 1995 Edition class made it.
There's no clear cut alternative CMS to use, that's the issue.
If you own a wordpress site for your business and you want to change your dev or agency then you will have no problems finding people who understand WP and can work on/fix your site. It might cost you but you'll have no issues finding people to work on it.
Use anything else and you'll be hunting down people who can and want to work on it.
The other major issue is, the paid plugin ecosystem is vast in wordpress and because of that many problems can be solved with a plugin. The conversation typically goes "If this were on wordpress we'd buy this plugin for $xx and we'd be done in a few days, but it's not so we can build it for $xxxx and it'll take at least 2 weeks."
Client hears that and ends up on wordpress next redesign.
Code quality ultimately doesn't matter to site owners so long as the site works.
Except they dont. Leveraging 30 plugins makes the sites a constant hack target and perform piss poor in SEO page speed test, etc. That lets fix it with plugins attitude works for entry level sites, but if you actually are profitable and competitive its more trouble than hiring someone to build a lean site, even if using WordPress for content in the backend. Less is more.
By the time you've reached 30 plugins of actual required functionality that effects page speed and existing caching solutions can't help you then yeah you probably need to build it custom, but there's a big old gulf of time before you reach that point where WP will serve just fine.
What's the alternative? I am not a creative type and I've been desperately trying to find something like a CMS that is simple enough that I don't have to think about it and featured enough that I can have things like personal profiles behind a login (for a brownie troop). WordPress seems like the same nightmare it was when I first looked at it however long ago but so do all the rest. Is there something better?
processwire.com. You have to build your front-end pages using whatever html/css template you want, but moving over to Processwire from wordpress was a breath of fresh air.
Thank you! I'll take a look. I've been playing with Ghost for the last 30 minutes (based on a comment below) and that might be my move but I'll definitely look at this too.
Craft CMS is well worth it.
> If you haven’t seen the source, you don’t know just how god-awful the code is
And yet, it runs 50% of all websites and 30% of all ecommerce websites.
...
Apparently it is not god awful. If running 50% of the web is godawful, anybody would want their software to be that much 'godawful'...
Empty elitism contrasting the actual reality of life and business...
Just because we don’t have a better choice doesn’t make Wordpress a good choice.
If another choice was better, it would break out in the last 25 years of the Internet. All kinds of frameworks, cmses and actual SaaS services with 'better code quality', 'better security' and 'better programming paradigms' competed and attempted to take its place. If after 25 years, none of those 'better' ones was able to prove itself !actually! better to the end users in any visible way, then it means that WordPress WAS the better one.
At this point you will definitely think "Oh, but the people dont know about good code quality".
They don't. And they don't have to know. They know what reflects on their websites, businesses, actual livelihoods. Those who use WordPress are not disattached MBAs managing gigantic organizations. They are people whose lives actually hang on those websites and ecommerce sites. What the software does actually dictate their income, their livelihoods.
For that reason they absolutely don't care about any esoteric programming paradigm or code quality which is !supposed! to impact their livelihoods greatly, but for some reason, it just doesn't. Definitely not to the degree that the proponents of criticism like yours think it does.
Only WordPress came forward as the software that cares about those end users' websites, businesses, livelihoods, by prioritizing them instead of 'good quality code' or programming paradigms and protecting backwards compatibility as if the existence of the world depended on it.
Whereas all the other competing software and even actual services including large tech giants on the other hand, literally played with people's livelihoods by introducing backwards incompatible versions in the name of 'better code and programming' - breaking the websites and shops that those people's lives depended on.
And it turns out that you can break someone's website or ecommerce site by introducing backwards incompatible updates once, twice, and a third time you wont be able to do that because that person will have moved on to a software that doesn't play with his livelihood like it was a little hobby project.
That's precisely why WordPress won. While in mid 2000s all the competitors were breaking their users' websites by pushing out backwards-incompatible versions, WordPress fought tooth and nail to protect backwards incompatibility.
The result is trusting users and a gigantic ecosystem of plugins and themes that allows anyone to do literally anything they want. People became able to just click a button to install a plugin and make literally complex features happen.
What was happening on the side of competitors during that period? Well, they were forcing people to write entire freaking modules just to add one measly form on their websites. Because, 'coding paradigms'.
That's why the flower shop owner somewhere in Oregon runs his local flower business on his WordPress site and the notable anime blogger somewhere in Tokyo is on WordPress more than 15 years. WordPress treats their websites with care, knowing that those sites and shops are actually those people's homes on the Internet, and refrains from breaking anything or doing anything that could impact those people negatively in the name of 'better paradigms'.
Speaking of better paradigms, is there any yet?
Back in mid 2000s OOP was the end-all-be-all. Everything had to be OOP. All the cacophony even forced WordPress to introduce objects everwhere around its code. Because, 'better paradigms', right.
And then a few years later suddenly functional programming is much better! Or, half of the programmers say so. Suddenly everyone is going in the other direction, whereas the die-hards of OOP still insist that it is 'the thing'.
It was just a few years ago that hooks in React were going to change everything. Everybody! Move to hooks! Then it just turns out that hooks aren't so good after all. Literaly 2 year fad. Also everyone has to move to React or some other bloated framework, because, you know, you have to have a 'modern' frontend, right. Then suddenly people start saying that maybe not everything needs that much dom manipulation after all, and rendering everything on the server and serving the user something that his or her device can handle is much better. Who would have thought. But all of these cacophony forced even WordPress to adopt some React. Because, 'modern', you know...
So this kind of programming fads even impacted WordPress, but WordPress still spent the effort to avoid any of those fads from breaking people's websites.
And that's why its 50% of the web and 30% of all ecommerce today. Because it prioritizes its users and their livelihoods. As opposed to programming fads and elitism.
...
Make no mistake - this paradigm does not only cripple the competitors of WordPress. It also cripples software industry in general, including tech giants. Living in our own world, thinking that the paradigms we have in programming are all important for everyone as opposed to just a fraction of our modern tech jobs, we prioritize the wrong things instead of prioritizing the actual users of the software and their livelihoods. Leading to literally crippling people's websites, apps and kicking their livelihood in the butt, losing them to whichever ecosystem that does not do such neglectful and out-of-touch things. An excellent example of this is shown by Google. It turns out even being a top tech giant does not allow one to avoid the repercussions of not prioritizing the users and instead playing with their livelihoods as if they were pet projects.
https://steve-yegge.medium.com/dear-google-cloud-your-deprec...
You repeat the same things over and over again, but I’m afraid I didn’t make myself clear enough: this is not about Wordpress not adhering to some coding standard. All those shop owners and bloggers you talk about have been affected, often badly, by crass vulnerabilities, SQL injections, malware, and security issues in obscure features enabled by default. In a lot of cases, this was the direct result of straight-out incompetence on behalf of the Wordpress maintainers and plug-in authors.
Wordpress is a single, glaring, liability. It indirectly prevents improvements to other people’s code; encourages proliferation of outdated and insecure code outside of the WP ecosystem; and causes increasing friction with the rest of the world (just look at projects like this one, which attempts to contain all of Wordpress‘ weirdness as much as possible). Just because Wordpress filled the CMS niche decades back and has a huge ecosystem moat now, still doesn’t mean it’s a good solution. It’s a chicken and egg problem, and all this fussing about caring about their users misses the point. Other people care about their users and deliver rock-solid software too, they just don’t fit in your narrative.
This isn’t about adhering to some highly ideal, but protecting those very people you care about.
I’m not going into the rant on cloud providers you seem to veer to, however. I’ve also made my points in other comments already.
> All those shop owners and bloggers you talk about have been affected, often badly, by crass vulnerabilities, SQL injections, malware, and security issues in obscure features enabled by default
That goes for all software that reaches a certain usage. There are no exceptions, including WordPress competitors.
Is there any actual study backed by actual data which demonstrates that WordPress is any more vulnerable than ANY other software that is widely used? Like, taking into account Windows computers that may be rarely connected to the Internet or taking into account how the entire Linux server ecosystem is run by sysadmins and not end users like WordPress? And then comparing the security cases in all of those software to the WordPress and actually demonstrating by data that WordPress is more vulnerable?
OF course not. All this criticism stems from the fact that WordPress security situations are more frequently encountered and publicized instead of any objective comparison. Which should have indicated that the entire ecosystem has a very good practice of vigorously tracking, publicizing and fixing these vulnerabilities and that should have been a point of praise, but no. Instead, baseless criticism is directed at it without taking into account that it is used in HALF of all the websites on the planet and even more importantly, actual end users.
Additionally most of those vulnerabilities come from the plugins in the ecosystem. Not WordPress. This is without counting in the fact that WordPress is hosted mostly on consumer web hosts whose security may affect the software itself.
And there is a very good reason for that - WordPress allows users freedom to do whatever they want. More than allowing it, people DEMAND it and they get it. Because that's how they can do what they want to do with their website or shop. Therefore its pretty common for a user to configure his or her website in an insecure fashion despite all warnings, guides and setup wizards that advise against such things. You cannot prevent people's freedom in their own website when they are hosting it themselves.
In contrast, Wordpress sites and shops that are hosted in managed services run without such security issues. Neither CNN's website or Reuters' website that runs on managed WP hosting gets hacked. Nor the millions of websites that run on other managed services.
There is a tradeoff in letting users do what they want and limiting what they do. Letting users do what they want looks like it introduces risk, but it also enables anyone to do anything.
And that's precisely why all those users are STILL on WordPress. Including the ones who got their sites hacked multiple times. They didnt move on to a 'more secure' software. They didnt move on to a 'more secure' SaaS, they didnt move anywhere.
> In a lot of cases, this was the direct result of straight-out incompetence on behalf of the Wordpress maintainers and plug-in authors.
This looks like singling out WordPress ecosystem in totally discriminatory fashion. How was the security situation with Windows? Top tech giant's software? What about actual intelligence agencies that conduct actual cyberwarfare and spend trillions on it?
All of them got hacked. All of them got security vulnerabilities. Despite the latter being a very specific, very narrow band of activity to boot. Nothing like WordPress enabling innumerable things to be done on its platform.
> Just because Wordpress filled the CMS niche decades back and has a huge ecosystem moat now
If WordPress was not good enough, it would not have filled the CMS 'niche' DECADES back and it wouldnt have a huge ecosystem now.
Leaving aside that it sounds outright absurd to call 50% of the web and 30% of ecommerce 'niche'...
> Wordpress is a single, glaring, liability. It indirectly prevents improvements to other people’s code; encourages proliferation of outdated and insecure code outside of the WP ecosystem
All of those are patently false. Sorry, but if you dont know enough about the ecosystem, dont make grandstanding statements on it:
The majority of the plugins in WP ecosystem do not interact with WP code directly and instead use hooks and filters. Thats it. Nothing else. They are freaking hooks and filters that allow you to do things with whatever passes through them. So there is nothing about 'Wordpress code enabling insecurities'. In reality, WordPress actively encourages people to use hooks and filters and to avoid doing anything directly with the WordPress code itself.
...
At this point Ill leave this discussion. You are basically ranting on literally scarce knowledge of the topic you have very strong sentiments about. That's not a basis for rational discussion.
A lot of Wordpress' problems are negative externalities that impact others more than the site owner and there is no liability for the site owners if their compromised site starts serving malware, SEO spam or leaks their e-commerce orders DB with all customers' details, thus such impact is not considered when choosing this disgrace of a platform.
Same goes for Windows. Same goes for every single major tech service. We read major security flops that expose millions' data from every major tech service every other day. Why should WordPress be singled out for anything other than just baseless elitist ire.
> this disgrace of a platform
It looks like this needs to be hammered home: That disgrace of a platform is running 50% of the web and 30% of all ecommerce websites. And every year it adds 3% on top of those percentages.
If 50% of the internet runs on something, its not the platform that runs it that's the disgrace - its the baseless elitism that targets it. The very emotional nature of the selection of your words demonstrate the irrationality of the criticism.
...
If its good for CNN's websites, its good for anyone's website. That's that.
> Same goes for Windows.
Windows has significantly improved since its early days - the Windows you're talking about would be at best unpatched Windows XP.
> Same goes for every single major tech service. We read major security flops that expose millions' data from every major tech service every other day.
Disagreed. Find me any tech service anywhere similar to WP's scale that can be compromised in a fully automated manner and where the exploits are of the same kind over and over again? Wordpress is Windows XP scale of vulnerability in 2023.
> Why should WordPress be singled out for anything other than just baseless elitist ire.
I'm not sure anyone is singling out WP? Every stupid data breach gets called out. The problem with WP is that it's prone to the same kinds of vulnerabilities over and over again - outdated, bad development practices/standards that make writing secure code difficult and a language/runtime that is itself flawed in its most common configuration (uploading a malicious file is a non-issue in every non-PHP application because your app server doesn't automatically execute said file - except in PHP where if the file ends in .php and is in the web root your server will happily execute it).
> That disgrace of a platform is running 50% of the web and 30% of all ecommerce websites
A significant chunk of people smoke tobacco, doesn't necessary mean it's good for you. As I mentioned previously, if the drawbacks of WP mostly impact other people and there isn't a clear liability path to the original operator, those drawbacks won't be priced in and thus if WP appears cheaper it will be popular.
> Windows has significantly improved since its early days - the Windows you're talking about would be at best unpatched Windows XP.
Same for WordPress.
> the exploits are of the same kind over and over again?
There is nothing that anyone can do for websites that people put up and abandon. They are not updated, and they would naturally get compromised.
> Disagreed. Find me any tech service anywhere similar to WP's scale that can be compromised in a fully automated manner
Find me any totally customizable service or software that is under your own total control, which you can just set up anywhere on the Internet as your OWN property and abandon it if you would just feel like it...
> I'm not sure anyone is singling out WP? Every stupid data breach gets called out
There are multitudes of comments that specifically single out WP in the post's comment thread. Including this very thread that you are on.
> The problem with WP is that it's prone to the same kinds of vulnerabilities over and over again
That's just flat out false.
> outdated, bad development practices/standards that make writing secure code difficult and a language/runtime that is itself flawed
Ah, its not just WordPress animosity, its also PHP animosity. Which, runs 80% of all websites on the planet in turn. And with hollow arguments of 'good practices'.
There absolutely isnt one single software that gets THIS widely used without noticeable amount of security cases. This includes 'good practice' software.
And again, I said this before and Im saying it again: WHERE is that objective study that compares WordPress with other software in regard to vulnerabilities, taking into account 'good practices' and use cases? Like taking into account Windows computers that are scarcely connected to the Internet or taking into account how the majority of Linux servers are run by sysadmins and not end users?
Nowhere.
There is one universal, dumb concept of 'security vulnerability' and it applies universally without taking into account anything. As a result, the random website that a site owner has abandoned getting compromised by an NON-UPDATED plugin is the same with a freaking internet-wide used web server software getting hacked or a major tech service leaking millions of users' data out.
Totally un-objective.
> (uploading a malicious file is a non-issue in every non-PHP application because your app server doesn't automatically execute said file - except in PHP where if the file ends in .php and is in the web root your server will happily execute it).
No it doesnt. Dont make up falsities. PHP executes files how you configure it to. Another case of configurability and total customizability. If you give the users to customize something, there will be those who customize it in bad ways. Its as simple as that.
> A significant chunk of people smoke tobacco, doesn't necessary mean it's good for you
Unintelligible comparison. Totally absurd.
> if the drawbacks of WP mostly impact other peopl
They dont. You are literally projecting your subjective opinions that are totally free of any objective, data-backed comparison.
> those drawbacks won't be priced in and thus if WP appears cheaper it will be popular.
That doesnt even make sense. All the legal liabilities of site owners, ecommerce site operators, any kind of business person are on them. They dont go away because some software is open source. And if all of those people are still on WordPress, it means that there is no such 'drawback to be priced in' as you so baselessly claim.
...
It just ended up as another string of uninformed, personal & subjective opinions posing as truisms. No data backed comparison, no self-contained, coherent logic, just bashing on what's popular. You even proposed things PHP doing certain things because people CONFIGURE it so as 'bad things'.
I'll just remind you that the case of WordPres is the same with any case in which you give people total control and total customizability - some people will f*ck up some segment of it whereas multidudes more people use it properly. It wouldn't be any different if you gave people totally customizable cars.
Ill leave you to your subjective biases at this point. Baseless arguments actually only backed by elitism and hate of what has become popular...
> Same for WordPress.
Not as much - WP favours backwards compatibility (or is it laziness?) even when doing so impacts security.
Another problem is that the environments Wordpress targets are inherently vulnerable - while it's not WP's fault directly, they do nothing to warn people against using them nor outright stop supporting broken, insecure configurations.
> There are multitudes of comments that specifically single out WP in the post's comment thread. Including this very thread that you are on.
I was talking about publicized data breaches in general. But if we specifically talk about CMSes, I'm not sure anything else beats Wordpress and similar PHP-based CMSes of that era when it comes to not just the amount of vulnerabilities, but especially the nature of them - the same, dumb, basic problems resolved in every other language (including modern PHP with a framework such as Laravel) repeated over and over again.
> WHERE is that objective study that compares WordPress with other software in regard to vulnerabilities
Someone posted the following excerpt of the Wordpress codebase: https://github.com/WordPress/WordPress/blob/master/wp-includ... which appears to be some custom attempt at simulating SQL query parameterization instead of using the actual, database-driver-provided function. If this is indeed the purpose of that function and it is indeed used, then I'm not sure there is any valid excuse for this in today's day and age.
Someone else mentioned password hashing still relying on MD5 - if that is actually true, I'm not sure that is excusable either? I haven't done PHP for many years now, but surely even if the native functions aren't available, couldn't they use a "polyfill" such as https://github.com/ircmaxell/password_compat ?
I'm sure there are many other issues but frankly the first one should be enough for any competent developer to run away.
> No it doesnt. Dont make up falsities. PHP executes files how you configure it to.
I was with you until this, but now I think you're arguing in bad faith.
Yes, if you want to be pedantic, PHP and your web server execute files like how you configure them to. In practice, the environment where the vast majority of Wordpress sites are deployed (your typical shared hosting environment) will execute anything that ends with .php and is in the web root.
This is inherently a legacy PHP problem (which WP encourages by supporting it) - no other language that I know of does this by default. If I accidentally store a malicious file in Python, Ruby, Node.js, etc applications, the worst that will happen is that I serve it back. At no point what so ever the server itself will execute that file.
Yet in the PHP environments Wordpress targets, this is a massive issue which means every single feature handling file uploads (both in WP core and any plugins) should anticipate your server's misconfiguration (maybe it's not limited to .php files, but .html files too?) and try to protect against it, eventually failing and then you get yet another Wordpress vulnerability.
WordPress uses the PHP-mysqli extension. The PHP-mysql extension is unused since WordPress 3.9, quite some years ago. You might mean PHP-pdo is advised. Can you explain why it is better in this regard?
Also $wpdb->prepare() uses parametrised values. Not everywhere in WordPress core is it being used. Most plugins use it for direct queries (not that common), but I don't know if the plugin team refuses plugins when they are not using it.
Read this article for a primer on why PDO is a vastly better choice: https://phpdelusions.net/pdo#why
And the fact that it’s 2023 and we’re somehow ok with the biggest web application there is not using parametrised queries in its core completely stumps me. Time and time again, SQL injection attacks in Wordpress or it’s plugins pop up. PDO with parametrised queries simply eliminates this issue.
> PDO with parametrised queries simply eliminates this issue.
True, but plugin authors not caring about using them is the primary issue, and that doesn't change just because wpdb uses a different API under the hood.
No, but nobody will encourage them to. Wordpress has fostered an ecosystem of bad practices that is mostly resistant to change.
>Also $wpdb->prepare() uses parametrised values.
They appear to be a hand-rolled PHP version of imitation client-side parameterized values, not the actual database library ones.
https://github.com/WordPress/WordPress/blob/master/wp-includ...
Wow. That is so much code just to avoid calling mysqli_prepare(). And they insist on using a weird printf inspired syntax instead of ? or :field.
I suppose it's pretty battle-hardened by now, but I'd be afraid to ever touch that code for fear of introducing a SQL injection.
Why would you change a successful product just because the "language evolves"? PHP is so successful precisely because it lets all the legacy code live.
To the contrary, with each PHP iteration, "bad code" is executed faster with fewer energy utilized.
It’s not because the language evolves - which it does - but because Wordpress is built on bad patterns, abuse of legacy features, and simply heaps upon heaps of bad code.
This leads to PHP itself having to make bad compromises for the future to keep the Wordpress code of millions of websites running; this leads to developers wasting time trying to accommodate Wordpress in plugins and themes; this leads to new developers growing up with bad standards and outdated practices.
I’m not complaining Wordpress doesn’t follow the latest trends or won’t add arrow functions everywhere. I’m complaining they actively block the way to the future, like a senile senator with lots of unmerited influence and decade-old opinions.
It's hard to understand for me why Wordpress core maintainers and developers decided to not uplift developers working in the WP ecosystem and in the result improve all plugins and themes codebase. Just simply providing a few well documented plugins with modern coding practices showing how things SHOULD be done would to wonders, adding to that good documentation introducing guidelines and standardization, good API for admin interfaces would gradually, over time change WP ecosystem.
Instead it's just wild wild west, code review is a pain because every plugin and every developer working with WP has radically different structure and coding practices approach.
In regard to WordPlate project - I can guarantee that huge amount of plugins and themes won't work correctly with this modified, non-default project structure.
That's a cheap, emotional and factually incorrect statement.
Thank you, I'll happily keep working with WordPress.
No, it’s not. My statement is grounded in years of working professionally with CMS systems for customers at an agency, as an engineer helping out our marketing department, and maintainer of a popular niche CMS.
If you’re happy with Wordpress, by all means, keep on going. My critique isn’t targeting you.
The code is awful, but some plugins are even worse. And the database schema... such a nightmare.
I have the luxury to be able to refuse Wordpress projects. In fact whenever I can I replace Wordpress with Django.
Django is also my go-to idea.
WordPress is plain crazy.
Marketing people insisted on WordPress so we reluctantly put it off in its own isolated network and expected bad things to happen. And, they did...
- WordPress consultant hired by marketing people while "editing the theme" introduced an infinite loop which caused OOM killer. That's when we learned you can point-click your way to editing actual php code in the admin web interface! Complete and total chaos and anarchy.
- Content manager "upgraded the SEO plugin" which downloaded from the Internet some hot-new code which used some language features beyond the version of php we were running, and bam, the whole thing was 500s, and everyone freaked out!
- Content people messed up the syntax editing the theme trying to change contact info in the footer, site wouldn't load anymore, they panicked and reverted the whole theme back to the stock default, and then ops people had to help them resurrect from the daily git check-in of the 1gb docroot they set up after the last time this happened.
It's a rough ride all around...
Yes, WordPress gives administrators the ability to change their theme, edit theme and plugin code (which can be disabled in wp-config.php in two lines and should probably be standard if you're setting up a WordPress website for somebody), and make changes to their website — that's why their administrators.
You should probably think about giving certain users like 'content people' the 'Editor' role if you don't want them doing administrator stuff like editing the theme file directly.
I'd imagine most CMSs where you give your client full administrator access can cause issues with them doing things they shouldn't, like blindly upgrading plugins.
Which SEO plugin gave you that 500 error? Most WordPress plugins have a 'Requires PHP' header that specifies the minimum PHP version required and refuses to install otherwise.
> - WordPress consultant hired by marketing people while "editing the theme" introduced an infinite loop which caused OOM killer. That's when we learned you can point-click your way to editing actual php code in the admin web interface! Complete and total chaos and anarchy.
Fear not, you can also introduce infinite loops with a good old code editor and ship through FTP or git or whatever. Also work with different CMS and languages.
Who was responsible for setting user roles on that site ? Who gave admin access to a consultant without having a conversation with ops ? If there's an op team, why isn't there a staging environment for that site ?
> - Content manager "upgraded the SEO plugin" which downloaded from the Internet some hot-new code which used some language features beyond the version of php we were running, and bam, the whole thing was 500s, and everyone freaked out!
Content manager shouldn't be given admin rights to a Wordpress installation. Why did op team allow content managers to upgrade software ?
> - Content people messed up the syntax editing the theme trying to change contact info in the footer, site wouldn't load anymore, they panicked and reverted the whole theme back to the stock default, and then ops people had to help them resurrect from the daily git check-in of the 1gb docroot they set up after the last time this happened.
Isn't that also one of op team's job ? Manage backup and restore ?
Seriously, you can replace WordPress with Joomla, Drupla, Ghost here and the story is the same.
> Fear not, you can also introduce infinite loops with a good old code editor
Well, when a developer writes code in an editor, they probably are working in a development environment with tests and version control, etc.
Why is there a web editor that changes the application's own running code? And why in the world would I expect that that would exist, and be on by default, for me to have to go and figure out how to turn off?
> > Fear not, you can also introduce infinite loops with a good old code editor
> Well, when a developer writes code in an editor, they probably are working in a development environment with tests and version control, etc.
This can be done with WP, but you are totally right and I should also have pointed out that the consultant should have asked for a staging environment or at least set up his modifications on his local copy of the site. He/she worked on prod and that's a big no-no.
> Why is there a web editor that changes the application's own running code? And why in the world would I expect that that would exist, and be on by default, for me to have to go and figure out how to turn off?
Ah, I think I now see where you are coming from. but:
> Marketing people insisted on WordPress so we reluctantly put it off in its own isolated network and expected bad things to happen. And, they did...
Well, if op team was aware of WordPress's reputation (and rightly so) it's a little bit on them to preemptively mitigate some of the risks especially if marketing team isn't aware of it. I suppose there wasn't enough hands on deck to do so deep enough at the time it happened or maybe office politics got in the way, etc.
Anyway, some security practices for WordPress suggest to change some file ownership (so only sysadmin can do maintenance work for core, plugins and themes via wp-cli), see https://wordpress.org/documentation/article/hardening-wordpr... which lead me to suggest that git may not be the best option for backup (since it doesn't preserve user ownership). Something like Borg, Restic or a file system based backup/veam/etc. is a better option.
> Why is there a web editor that changes the application's own running code?
Well, in the before time, it would give anyone running the site the ability to modify theme/plugins if they didn't have access to FTP.
Totally agree, I don't see any reasons to keep this around. But any plugins or themes can add a section in the dashboard with a web editor able to modify anything the webserver can modify, so... it's mitigation more than prevention if themes and plugins upload aren't locked.
I hope I am not coming off too strong ? I would likely do the same kind of mistakes if I was asked to host a django something.
> Isn't that also one of op team's job ? Manage backup and restore ?
Yes, and that's what they did. But it seems a broken design when it takes all that to change some copy in the footer.
Yeah. Big workflow failures here. The person who changed the code doesn't have a revision system in place or the skills/knowledge to put the site back up after such a minor edit :/.
How do you even reliably version-control something that relies on editing its own code?
There's some confusion here. WordPress themes and plug-ins don't rely on the built-in web editor. That's why it can be safely disabled.
What that guy did is no different from sshing into the prod server, live editing a Django plug-in and refreshing the browser.
Version control of the plug-in won't protect from that. But it's a handy tool to manage regressions.
Rolling back changes and editing a live plug-in are different problems.
Fwiw at a previous job we found that using blog vault backup gave us reasonable backups - a way to migrate setups (restore to new host) and workable (if a little clunky) staging environments:
In addition:
Helped by providing a more reasonable editing experience (for a website - not "just" a blog).
Both of these are paid. I think I would have preferred a managed host that provided backup and staging - but that would probably cost a little more (cash, fewer hours) - than basic php+mysql web host.
Other than those two - I think we got rid of all third party plug-ins, except for a theme or two (different theme for different sites).
Made wp just about manageable.
Personally I still can't stand the wysiwyg "works 90% 80% of the time) editor - but then the marketing people were responsible for updates - and with wp they could do it themselves.
Why do you give non-devs the ability to upgrade PHP plugins and edit theme syntax, shouldn't that be the site admin handling? Why are you not using staging to test? These don't seem like WP problems :/
For better or worse, part of the appeal of Wordpress is ease of use for non-developers to update their website. Most small businesses definitely don’t employ a dedicated site admin/developer - if they had to they wouldn’t bother with a website. In fact, it looks like that’s the way things are going - pushing small businesses into walled gardens like FB, Insta, Wix, etc. And I don’t blame them, that’s probably the right decision for most businesses.
"part of the appeal of Wordpress is ease of use for non-developers to update their website."
Seems like in every HN thread regarding Wordpress this is brought up, but later the thread fills up with horror stories of sites being melted down when non-technical users are left to manage these Wordpress sites. Just my two cents, but that supposed benefit of Wordpress seems more like wishful thinking.
> Seems like in every HN thread regarding Wordpress this is brought up, but later the thread fills up with horror stories of sites being melted down when non-technical users are left to manage these Wordpress sites. Just my two cents, but that supposed benefit of Wordpress seems more like wishful thinking.
Nah, it could also mean we don't hear about all the Wordpress running without problems.
Personally I think it's a HN meme now, like the Signal thread with half the comments about Matrix.
Until some random violation gets the page suspended or removed. Had this happen a couple of times, latest was a result of changing over from Facebook Ad manager to Meta Ad manager (or whatever they call it) which triggered the suspicious activity, give us your Govt ID busllshit.
Sorry Facebook, you can go and... you know what!
Probably because in many cases the assumption is that the dev and main editor are the same person?
It's not a great assumption anymore (since many WordPress installs are now set up by agencies and dev teams for non technical clients), but it's likely a holdover from the days when most people installing it were also the main designer, developer, content writer, etc (read, bloggers).
Why can a "theme" editor edit application code? Why do I need a developer in order to change what it looks like? Why is plug-in code not sandboxed? These are WordPress problems.
At the end of the day, if you tell me that WordPress is an application framework, that themes are code and plugins are dependencies, then okay -- devs own it and there's code reviews and staging environments and deployments and migrations and all the rest.
But if you tell me it's a CMS so marketing people can have a blog, I just ... thought it would be simpler.
> Why can a "theme" editor edit application code? Why do I need a developer in order to change what it looks like?
Because CSS, because HTML tags are rendered server side and that H1 should be a H2 or that tailwind div soup is funky, or the company team member pages needs ACF to keep tracks of member profiles because editing the page by hand takes too much time,etc.. webdev :/
The other option is things like Elementor or Divi which aim to give content team the ability to modify layouts (and even links to dynamic elements in db) but it's a whole another mess (but it wouldn't be your, yeah !).
Someone at WP is aware of it though, hence all the work on gutenberg and front-side editing (FSE) which ultimately should turn WP into a complete headless CMS.
> Why is plug-in code not sandboxed? These are WordPress problems.
Definitely ! Wait until you have a plugin breaking wp-cli so you can't deactivate it... rm wp-content/plugins/foobar-plugin -rf to the rescue.
> At the end of the day, if you tell me that WordPress is an application framework, that themes are code and plugins are dependencies, then okay -- devs own it and there's code reviews and staging environments and deployments and migrations and all the rest.
> But if you tell me it's a CMS so marketing people can have a blog, I just ... thought it would be simpler.
Yeah, if marketing just wanted a blog and no forms to collect resumes, polls etc. I'd have given them a ghost or a very reduced/amputated WP and signed binding agreements that no plugins or themes would ever be installed on it.
Web development is plain crazy and WordPress adapted itself to that?
I found Craft CMS to be WordPress made by sensible people. Well worth the licence. You can simply disable admin changes in production, or set fine grained permissions.
You could have avoided all of these problems by having a developer set up a staging environment, version the site in Git and disallow file editing on the site.
Fair enough, and now I know.
But would you also agree it's a totally insane capability, let alone default, for a CMS to offer a web interface to edit its own running application code? With no VCS integrated or rollback mechanism...
I was too naive to know I should look for a thing like that to disallow.
Yes, those are totally legitimate criticisms.
IMO WordPress' big flaw (and key asset) is its commitment to backwards compatibility. The upside of this is that it was very easy for people to pick up and deploy it on PHP hosting in the 2000s, leading to its massive growth. The downside is that, as a WordPress developer, you're saddled with sticking to decisions made years ago.
It's definitely not your fault that this is unclear, the WP.org documentation does a poor job of explaining the pitfalls. After 5-10 years of working with it you come to understand the weird kinks...
Sorry for piling on your comment.
What advantages does WordPlate have over Bedrock[1], some of whose packages WordPlate also uses?
Found some discussion here, but tbh it's a little light for me not to think that NIH syndrome doesn't come into it?
Wow, Wordpress still use MD5 hashes for passwords? That's really taking backward compatibility with old PHP versions too far!
https://github.com/roots/wp-password-bcrypt#readme https://core.trac.wordpress.org/ticket/21022
Assuming you use unique passwords for your services, I think the crackability of a password isn't too big of a risk. You need to find a password dump somewhere for a specific website. I'd wager that most WordPress instances have only a few (if more than one) users in their database, you won't easily find a WordPress dump with a million passwords in it.
With an admin password you can probably upload some executable code, but if you can find a database dump online I doubt you'll have too much effort exploiting a WordPress plugin anyway.
You do realise 70% of the web is powered by Wordpress, including huge communities and platforms? That most people do not, in fact, use unique passwords per service? That password dumps are easy to find online? That haveibeenpwnd is a thing?
Just because Wordpress plugins are notoriously bad quality, you absolutely shouldn’t be lax with password security.
It's not about backwards compatibility. It's about sheer incompetence of the WordPress developers.
I have never seen such a badly coded mess.
I ask every downvoter to prove me wrong. I'm sure none of them have ever seen any piece of WordPress code (or documentation, or anything else).
Adding composer to WordPress isn’t gong to fix it. The problem is more fundamental - WP was conceived as a blog engine and has proven itself constitutionally incapable of truly moving beyond that frame.
* features People say that “you can just add a plug-in” for whatever, and that’s true. But so many things that should be core are not (advanced custom fields, forms) and other features have no place in modern WordPress (comments). Gutenberg is an incomplete answer to page builders. While the page builders are impressive, they still have a pretty substantial learning curve.
* cost I’ve been using WordPress for over a decade and it’s fallen woefully behind other CMS’s. Recently I spun up a site for a client and the plug-ins cost over $1000 just to get them going. That isn’t _WordPress’s_ fault, but it doesn’t help.
* speed WordPress inexplicably gets slow after about a year unless it’s managed by someone with masters-degree level skill. It’s like the system gets tired. The caching plug-ins help, but why doesn’t WordPress offer better caching itself?
* deploying Recently, I decided I’d had enough. I was doing a one-day build for a small marketing site and it took two hours to deploy because the “yoast” plug-in broke the WP CLI’s ability to search and replace the database for URL’s. Not to mention that source control is a nightmare because people can install their own plug-ins from the dashboard.
I’m writing an open source visual page builder for Laravel. It fixes the problems I see with WordPress for building marketing sites. Think of it as a blend between the visual ease of Webflow and the programmatic power of Laravel. By default, it’ll run off of SQLite (but any sql db will work), so they’re awe only two things living outside source control - the SQLite database and the uploads folder. That makes managing transitions from dev to production an absolute breeze.
I’m very excited about it! It should be ready for beta testing in a few weeks…if anyone wants to give it a shot, let me know.
Best of luck on your cms - I must admit I think the future lies with something like deno/fresh (https://fresh.deno.dev) or astro (https://astro.build) along with cdn/edge computing.
> Recently I spun up a site for a client and the plug-ins cost over $1000 just to get them going.
I think that's the wrong way around - you/your client could buy stuff costing a thousand dollars because of the huge wp ecosystem (however dysfunctional it may be - I once looked briefly at how to write and sell a wp theme - and quickly moved on to different pursuits). Now, how much value did you get from that? That's one of the big draws of wp.
Im sure your new system will cover 80% of that - but what about the themes and plug-ins someone else needs?
I’ll check out fresh and Astro!
As far as costs go…
Beaver builder - 250 Custom fields - 100 Faceting - 100 forms - 150 Import/export - 100
It doesn’t take long to get to $1000!
The new system I’m working on will be extensible for various needs using new composer packages. So if someone wanted to write an obscure form handler, they could trivially add it to Prodigy as well.
> I’ll check out fresh and Astro!
Please do - but note that those are typescript frameworks/systems - not php!
I'm not saying "don't build stuff in php", just that for me, if I was going to throw out support for wp themes and plug-ins - I wouldn't see much point in staying with php and similar architecture to wp. But for those comfortable with modern php it might be great.
I'd be interested in your page builder. Can I get in on the beta?
Yep! Just shot you an email back.
Sounds like you're building exactly what I'm currently looking for. I'd love to give it a shot as soon as your beta is ready.
Shoot me an email -
Stephen@bate-man.com
and I’ll add you to the list!
Congrats on releasing, we built something similar (WP/composer) for our stack, you can see the details here: https://docs.altis-dxp.com/getting-started/
A lot of this seems to be change for change’s sake. Creating something non standard for anyone used to working with wordpress for no big benefit. The main benefit of wordpress is the compatibility and the number of people who know it inside out. To be honest it smells like a project by a bored agency wordpress dev who would rather eat their own head than code another custom theme so spent a few weeks throwing this up instead. Every big wordpress agency has devs like this.
This is exactly my thoughts when I came to my current agency and they used bedrock. It was way more complexity and hassle than help.
Favoriting this for any possible WP project in the future, thanks. Would want to take a closer look to see how it compares to stuff like Roots’ Sage project.
I’m glad I’ve been able to develop on https://wagtail.org/ for the past few years though. Usually such a pleasure to work with.
I always wonder, at what point is it easier to just ditch Wordpress completely and instead spend the time to add an admin theme that looks & behaves like it for familiarity of users, and maybe add whatever magic functions your favorite framework might be missing.
This isn't a critique, I use WP intensively, and we heavily modify and extend it as well, but the familiarity of the team (in dev, seo and content) is pretty much the only selling point, because we shut down most extra features (feeds, rpc, json-rpc, emojis, gutenberg, comments etc etc etc), use a complex varnish-setup, do image optimization etc outside of it and most plugins aren't really good, so we roll out something custom instead. Getting rid of it it isn't an option for us because we're so committed and have built so much custom stuff around it, but with a green field, I'm not sure.
I think you answered your own question, the familiarity for users (seo & content) which is "end-to-end no-code" is massive (especially once extended with user-facing plugins). And you're not even speaking about making the move to Gutenberg yet. Just too much value there.
Yeah, certainly, but that's what I meant to address by making your framework's backend look & feel like WP and adding e.g. shortcodes to it and having a media library that works the same way (but doesn't suffer from WP's clunky bolted-on attachment).
Gutenberg isn't a thing for the folks I work with, nobody there likes freedom (freedom only leads to errors!), everything is form-based (ACF is slow but it works, and here, too, it's not users setting up the fields, it's developers) with a few shortcodes to pull in special elements.
I'm not complaining, I like building tools and solving problems and using WP allows for plenty of both, but in hindsight WP is slowing us down, I believe. Of course, it's hard to predict the scale of things when you start, so having something you can quickly iterate with is useful.
what familiarity? every single plugin's dashboard/admin page looks completely different.
Somewhat of a facetious argument, like saying the posts and site settings pages look completely different.
It's not to say there aren't some that say sod it and have their own UI library. But quite a few leverage wordpress admin styles and conventions (such as the wp_list_table).
But the quality is all over the place, much like with composer packages.
Why remove RSS? It’s one of the best features.
Any alternatives for Wordpress?
Yes many.
Craft CMS. Statamic. Expression Engine.