Hacker News Reader

Comment by gtf21 | Hacker News Reader

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.

View on HN

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!).

> WordPress is easy to start using

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.)

I've got the regular virtualmin (free) and I don't see it in there. :(

Oh - yes, there's a "Django" installer, but not the Django CMS I was referring to.

Yes, it's a small number, but I'm doing my best to help grow it with my client base, and then their client base, etc.

Thank you for the work you all do on Virtualmin.

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.)

Totally agree with you

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.

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.

I hear you, and yet WordPress usage numbers speak a lot louder than our grumbling about messy codebases.

Wordpress doesn't have a poor security track record.

Wordpress users have a 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.

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.

Or I've simply dated myself. :/

I am curious what is this great platform that you've moved to which is apparently bug free?

If it's something like Squarespace then what's really happening is you're paying someone else to babysit it for you.

"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.

For anything non-trivial, a poorly written code base and/or poorly implemented database schema/layer becomes a liability, both in time and money.

It's a spectrum, where that liability is only a net negative past a certain point. Most WordPress users don't reach that point.

99% of the small business on the web is trivial. They never get the point to worry about code liability.

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.

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 correct, but it's an unknown unknown for most of the people using Wordpress. They're not even aware that it might be a problem.

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).

> 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.

Late reply here but I built them myself, and it was painful.

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.

Reply on news.ycombinator.com