Do you mean WordPress? Sure, of course it shouldn't escape critical scrutiny, but people actually sneer at it (and PHP generally, and worse, at PHP programmers).
Well, in fairness the WP codebase is horrific. I used to write everything in PHP, and once thought it a good idea to build a system in WP because it was user friendly. I needed some custom auth plugins and a custom theme.
Having fought with a poorly documented, inconsistent and generally badly-designed codebase for a few months, I'm not sure I'd agree that WP is undeserving of some sneering. It is one of the worst made things I have ever seen.
PS: I no longer develop in PHP, and haven't seen the WP codebase in about three years so perhaps it has improved.
WordPress is easy to start using, is fun and rewarding, makes people feel they've managed to get something done, works out of the box.
That is what competing systems have to beat. I do think that our own django CMS https://django-cms.org is a better system than WordPress - more elegant, more secure, more extensible and scalable.
But it's not enough to be proud of our beautiful internals, we have to give the ordinary, non-expert user a good experience too, and make them feel in charge of the system from the start. That's why we admire WordPress and want to beat it (and who would want to beat something that they sneer at - it seems a low ambition!).
For many people it's "log in to cpnael, press the wordpress button, done". this is what other systems need to beat, and... without the cooperation of major hosting companies, they won't.
get install scripts in to control panels like virtualmin to get rolling on adoption.
We have a Django installer in Virtualmin (maybe only in the commercial version, but I think we tend to put "developer" tools into the OSS version, as well...so it might be in all versions; there's 100, or so, installers in the commercial version and only a handful in the GPL version). I was unaware of Django CMS, and no one has requested it, as far as I know...we pretty much build what our customers ask for.
We welcome community contributions of installers, and those always go into the OSS version of Virtualmin, as long as the person is willing to help maintain it long-term, and it is generally usable on a wide variety of our supported operating systems without too much effort (e.g. it works without needing a super new version of the language). Adding such an installer does put the app in front of about 100,000 users (which is roughly our current installation count of Virtualmin GPL), so that's cool and probably is a useful use of time/effort for someone wanting to make a web application more visible and more widely used.
We're working on better support for multiple versions of Python, as that's also a problem for more widespread adoption of Python apps (and Ruby, and Node, and Perl, etc.). Most rely on very, ridiculously, new versions of the language, whereas PHP apps almost always have a low barrier to entry that matches what an old version of CentOS shipped with. So, users don't just need to install the application or framework, they also need to install a personal version of the language it is written in. That's a bridge too far, for the vast majority of beginners. We already support multiple PHP versions, as that was a priority for many of our users, but we're just getting started looking into stuff like rbenv, plenv, pyenv, etc. for private versions of languages.
The problem of needing very new versions of the language currently leads to a lot of our supported non-PHP apps being unsupported on the most popular systems, without some extra hoops to jump through; CentOS 6, which still has more active installs than anything else, can't run many modern Ruby, Python, or Perl applications, without installing a newer version of the language. SCL provides newer versions of some of those, so it's not insurmountable, but it's still a leap for many non-technical users.
Anyway, it's worth being aware that using the latest and greatest language features is fun, but it's also limiting reach. (Even once we automate all of this for other languages than PHP, Virtualmin is still running on a tiny number of the servers in the wild, relatively speaking.)
The number of people using any non-PHP apps is very, very, very, small, so it just doesn't get a lot of attention from us or users. One of our favorite customers is a developer in the Django community, so we added things at his request, but I think he uses a custom deployment and so our stuff doesn't get a lot of testing even from the fellow who requested it and helped us develop it. I would like to put more resources into it, but it's a chicken and egg problem. No customers want it, so it doesn't get a lot of attention, so people who do want Django support see that we're not very serious about it and don't use it or contribute to it.
I'm glad to hear Virtualmin is working well for you. If you have problems with Python stuff in Virtualmin, feel free to let us know. The squeaky wheel gets the grease...and not many people squeak about Python/Django support in Virtualmin. As far as I can tell there are literally thousands of times more WordPress users than Django users (just to put it into perspective).
People I know who have used Django praise it, but WordPress's ecosystem is in another league entirely.
Real-world example: I needed to build a restaurant website in as little time as possible.
A Google search for Wordpress Restaurant template gave me everything I needed (I went with one from ThemeForest).
The same search replacing Wordpress with Django doesn't return anything relevant :( (it does give me several paid ads for Wix and other site builders).
Edit: mgkimsal also has a point. It's ridiculously easy to get Wordpress up and running with most hosting providers.
Edit2: the article mentions the setup issues. Docker containers sound like a way to overcome that one, but the ecosystem barrier will remain.
Docker containers are not a way to overcome difficult installation for the kind of users deploying WordPress en masse. They're (still) often on shared hosting, in a lot of cases, using whatever control panel their host provides, and not only don't know how to use Docker, they don't have the capability to do so on the server. Even most of the folks with a VPS aren't on board the Docker hype train just yet. (Docker is cool and all, but it's not how people outside of our bleeding edge bubble are doing things, yet.)
It's worth underlining that the only people in the world that give a fuck if a codebase is a tangled mess are developers. Everyone else is solely interested in ease of use and budget concerns.
Its true, but its indirectly connected to budget concerns. Long term, a good code base will be easy to fix saving a ton of time effort and frustration. Thats why we usually do give a fuck. Technical debt is a pretty accurate metaphor.
That is certainly the orthodoxy of our times, and yet I am strongly skeptical in this instance. If you adopt an open source CMS the expectation is that the core and plugin dev teams will handle the overwhelming majority of code maintenance work. This leaves your team to focus on maintaining whatever customizations were coded for a particular project. Ergo code cleanliness outside of your own repo should be largely irrelevant to the project budget.
> This leaves your team to focus on maintaining whatever customizations were coded for a particular project
And if the API with which you must interact is poorly structured and documented, then this becomes harder. Furthermore, a messy core codebase makes projects harder to complete (as was my experience building custom auth for wordpress).
What about not having to patch a security bug every five minutes? I very much doubt the messy codebase has no impact on WP's poor security track record.
Sorry, but the fact speak for themselves. Wordpress itself (excluding plugins) has had more than 10 CVEs this year alone. That's more than one per month!
As an ex-user myself, who built the site and only installed a couple of plugins, I moved my organization to another platform because I was sick and tired of having to babysit what should be a solved problem by now.
"apparently bug free" - not at all! By solved problem, I mean like we've solved bridges; they fall occasionally, but I don't feel the need to call my loved ones before each crossing.
My preferred solution would probably Movable Type, but since my org can't afford it and we don't need fancy formatting, it's Nikola + Coil CMS. Easily editable by non-techies and yet there's no code to attack on the site - it's all statically served by Nginx.
We've decided that remote code execution bugs should be a solved problem class now? Fascinating. I'm sure the sendmail dev team will be delighted by this news.
Considering that the last RCE bug in Sendmail seems to have been a decade ago, I'm really struggling to understand your point. If anything, it seems to reinforce mine.
That's true, but even though there are plenty of tangles in the WP codebase it's not hard to do some pretty advanced customizations via plugins/themes.
> I'm not sure I'd agree that WP is undeserving of some sneering. It is one of the worst made things I have ever seen.
You mentioned custom auth plugins and custom theme - did you build those yourself, or use third party ones?
One of the biggest issues I have is that the more popular a plugin is, generally the worse it seems to be from a code standpoint (I'm talking about understandability, testability, performance, readability, etc). Yes, it works, but... if I need to extend it... it seems like it was written by and for people who do not understand programming (and yes, I realize that's generally exactly what's going on).
When you try to do a large WP project, you're suddenly dealing with a dozen or more separate plugin authors/companies, all of whom have different styles and competency levels, and some of whom break other code (unintentionally almost always). Trying to 'support' that is a logistical headache, on top of whatever else you're trying to have the system do.
I spend 90% of my time in 'real' languages like Java, C#, and Python building 'real' web apps/services and I still go to Wordpress if I need basic CMS functionality. It's incredibly easy to build a theme or plugin for and the deployment pipeline is pretty darn simple. Granted, if you were average Joe user and went installing plugins and themes from the darkest corners of the 'net your site would be absolutely hosed, but keeping it to the basics I've had very little performance issues and have been able to have a couple of sites withstand some major traffic spikes.
Maybe it's because I just haven't forced myself to get good and fast w/ Django, but when I need a CMS and the project is almost entirely about how it looks or some functionality that is solved by a well regarded plugin I just head straight for WP.
That being said, I 100% agree that the codebase is horrific when you're used to writing modern PHP (even worse when you're used to other languages, period) but it is such a known quantity it's hard to move away from it unless it can be solved by using something like Squarespace, etc.
> It's incredibly easy to build a theme or plugin for and the deployment pipeline is pretty darn simple
I disagree, I found writing custom auth and theme to be nightmarish compared to other frameworks and CMSs because the codebase is so poorly documented and illogically structured. It probably took us three times as long as it should have done to "complete" the project. Having subsequently played with some other CMSs/frameworks like October (based on Laravel) and Django, wordpress looks somewhat inexcusably bad.
> I'm not sure I'd agree that WP is undeserving of some sneering. It is one of the worst made things I have ever seen.
It's not so poorly made that it's unusable. Even from a development perspective.
I've seen quite a few beautifully-engineered projects that failed in some critical, unresolvable way or (more often than not) were just plain unusable.
The entire world is built on shitty infrastructure that gets the job done.
Makes it quite unmaintainable. Yes, beautifully engineered projects can fail, this is uncontroversial. The difference is that something well engineered is easier to fix, maintain and iterate upon.
I remember that I was snobbish about my Django skills... with my college buddy who would build Wordpress sites for a buck or two here and there.
The guy is in Chicago right now and gets a lot of business from engineering firms. He is doing phenomenally well, he gets about 30-40k from (what appears to be) 20-40 hours of setting up fairly basic things with Wordpress.
WP built a culture, which mostly works, not just a product, which - by any reasonable standard - is utter crap internally.
Once you build a cultural monopoly, it's damn near impossible for a second mover to dismantle it. You have to wait for a new niche to colonise, or for WP to implode under the weight of its own awfulness.
A new niche is hard to imagine in blog land, at least while we have today's web. And awful as it is, WP isn't quite so awful it's likely to implode. If it was, it would have done it by now.
Your friend is making money because he's thinking like a business person who can offer a service, not like a developer who primarily thinks about tools, not cultures.
Among, say, the top 10 most used languages, PHP is easily the worst.
I'm sure you can learn a lot from PHP/Wordpress, but everything has opportunity costs. You can learn better from better languages and frameworks.
My shop does Python, Java, C and PHP. I know very good programmers who happen to write PHP for a living. They are the ones sneering at PHP the hardest.
They're also the ones bringing PHP into the modern world and making it much harder to sneer at.
There are some plain-crazy things about this language, but there are also some plain-crazy things about other popular languages too. It's like we forget that JavaScript was absolutely reviled for over a decade. PHP is undergoing a JavaScript-like transformation, though it will never get that kind of popularity because of the lack of client-side browser usability.
Maybe it's just me, but isn't JavaScript still looked down on? There's a reason languages are being written on top of it, and lots of frameworks to patch up the terrible usability of it. Just because it's popular doesn't mean it's great.
Yeah, somewhat. However, despite frameworks like Node, JavaScript is a client-side language. So even if you fuck up horribly with it, the damage you cause will be minimal. Not so with PHP.
Yeah it's definitely improving. But last I checked the PHP internals team was very reluctant to change anything, even plain-crazy stuff, to maintain backward compatibility. In PHP, if a bug sticks around long enough, it becomes a feature.
I'm not a purist, if you're making money coding PHP more power to you. Around here there are a lot of businesses hiring people to make them Wordpress sites. But an aspiring dev asks me what language to learn I don't recommend it.
You've definitely nailed the problem. It's all about backwards-compatibility. Most of the plain-craziness I see day to day is in the Array methods, which certainly is annoying.
There's also some crazy defaults with json_encode which you actually need to send a flag to disable to get valid UTF-8. JSON_UNESCAPED_UNICODE, I am looking at you...interestingly enough they set the default to not cause buggy JSON parsers people use to blow up. Not a choice I would have made, but I guess they like to be nice to their users. It would be nice if their documentation for this function gave a more prominent message about this.
To address your second point though, I wouldn't advise that anyone learn _any_ language specifically. I would have them address concepts directly and try to be language agnostic. JavaScript would be the closest thing just for employability reasons, but it has way too many JavaScript-specific quirks for me to recommend someone to base their career on it.
I didn't start with SICP, but going through the first three chapters is probably the single thing that kickstarted my transformation from hobbyist programmer to professional. The next was Eloquent Ruby and then Clean Code.
Entering a growth market early and appealing to beginners can get you a lot of traction and mind-share.
Being easy to get started with is better than being easy to use overall because of human cognitive biases.
You can coast on that initial traction for a long time and remain successful because people will become "fans" and tie their ego to the tools, especially if they started using it very young.
No one gives a shit about security.
Success does not have to be correlated with providing value if you target the less informed.
