So, a reasonable question to ask is what can I recommend to non-technical people when they need a website quickly and inexpensively that won't make me feel like I'm setting them up to get owned?
Also what advice should I give to WordPress users to help them improve security, other than the rather useless and bratty "don't use wordpress lol" answer? I'm a security professional and I follow the constant stream of "lol WordPress exploit" articles, but proactive security measures for WordPress are a bit outside my usual enterprise infrastructure work.
I still, currently, recommend WordPress, despite its flaws.
I don't recommend doing ecommerce (directly) with it, or anything that could gather sensitive information, but for "just a website" with a bunch of cool stuff, WordPress is pretty much impossible to beat for the sheer amount of "cool stuff" you can do without ever writing code. The plugin ecosystem is tremendous.
The automated updates, so far, mostly stay ahead of the curve on exploits in the wild. We have a large pool of users to draw information from (thousands of servers running all manner of web apps), and we're far more likely to see exploits of systems that are harder to update; Drupal, Joomla, and especially a bunch of little apps that have tiny market share and small maintenance teams and cranky update processes. Having an easy and automated system for updates is just incredibly valuable for security.
What really needs to happen is everyone making web applications needs to start shipping a command line client for updates, that is safe/reliable enough to be run from cron. Best of both worlds: you don't need the app files to be write-able from the app itself (which is one of the big security concerns raised by this post) and you're always running the latest version even on systems that aren't being worked on daily. There's still the command line element to the problem, but it could be mostly automated away by control panels and installer tools (of which there are many).
There are a lot of forgotten CMS installations out there, and those are the biggest security problem, IMHO.
> I don't recommend doing ecommerce (directly) with it, or anything that could gather sensitive information, but for "just a website" with a bunch of cool stuff, WordPress is pretty much impossible to beat for the sheer amount of "cool stuff" you can do without ever writing code.
Yes, basically don't store anything like this in the WordPress database. There are tons of services you can use, like Hubspot for forms, that allow you to abstract all of these things away from your site and still use WordPress.
Unfortunately this doesn't solve the problem that WordPress needs to be able to write to itself. It's game over once every skid in the world can pop a web shell in /var/www.
> I don't recommend doing ecommerce...or anything that could gather sensitive information
The problem with this kind of thinking is that if I can get remote code execution, or even just content control over your no-ecommerce-or-sensitive-information blog, I can have a great time. Sure, it's not as valuable as CC info, but the potential for malware distribution, credential phishing (password reuse for the win!), various kinds of social engineering, or even just as an anonymizing host to hide illegal activity, is still huge.
Several years ago. We briefly used it for our company website, in between OpenACS and Drupal 6. But, it was short-lived, maybe a year, as it was just incredibly difficult to maintain and enhance and the various bridged in applications led to a really inconsistent user experience (multiple notifications configurations, etc.). I've heard from customers that it has improved, but I haven't had reason to look at it lately.
But, I'm glad to hear they've improved the update experience; though I can't imagine how it could be easier than WordPress, since WP will update automatically with no user intervention, if you let it. Easy and reliable updates are perhaps the single biggest security feature, if the team behind the project is pro-active about security bugs.
And they're only going to get better. Ten years ago a funded company might have done much better rolling their own CMS, but nowadays I agree whole-heartedly that managed solutions are the way to go and I believe ten years from now this conversation will be even shorter.
Have you actually ever thrown up a SquareSpace site? I think even GeoCities WYSIWYG editor was more friendly (and capable).
SquareSpace maybe fine if you're limiting what you're trying to do to _exactly_ what's in the template, but figuring out how to work their system otherwise is hours of maddening, (poorly or) undocumented hell. I threw up http://www.pateshop.nyc/ for some friends and it took a full day.
It would have been faster if I'd just wrote the site myself. It's not even that great -- to get the nav/ux requested I had to compromise a lot to what SquareSpace could deliver.
I don't think someone unfamiliar with HTML and CSS would have been successful.
>Have you actually ever thrown up a SquareSpace site?
Several actually, and didn't have much trouble with the WYSIWYG. Worth noting though that the websites more or less fit into the existing templates, but you can also do your own work there.
>It would have been faster if I'd just wrote the site myself. It's not even that great
Well, the parent was asking
>what can I recommend to non-technical people when they need a website quickly and inexpensively
and "make your own from scratch" isn't really an answer to that at all...
> So, a reasonable question to ask is what can I recommend to non-technical people when they need a website quickly and inexpensively that won't make me feel like I'm setting them up to get owned?
Get them to use a hosted WordPress solution. So many times I see people hire someone to set up a VPS with a customised version of WordPress and then think it'll just run itself and stay secure.
I'd be extremely interested from a wholly self-interested point of view to know what you think of http://demo.django-cms.org/ (for an out-of-the-box demo of django CMS), and whether you'd find that as quick to get to grips with as WordPress).
I just spent 8 minutes, and I still haven't figured out how to edit the text of a blog article on the demo site, or create a new post with any body content. All I see is a form for editing article metadata and lead, no matter how I try to get at it.
1. Blog -> Article List -> (Title) doesn't do it.
2. Blog -> Edit this article doesn't do it.
3. Double clicking on article text only lets me edit single paragraphs at a time. It doesn't seem to let me add or re-order paragraphs either.
4. Blog -> Article List -> Add Article doesn't let me create a post with body content.
The Help section in the sidebar with mini video introductions explains that.
See step 6 (using the Content Wizard to create a new weblog article for example, including body content) or step 7 (which explains how to switch to structure mode, another way to add and/or rearrange body content).
Existing body content can be edited simply by double-clicking on it while in edit mode.
The question is whether this is just a case of understanding the basics of a different paradigm, or something that could be made more intuitive.
Thanks for the feedback, and thanks for taking the trouble to look at it.
I spent another 15 minutes with the structure editor, and I think I understand the content model now. During my first encounter it was very difficult for me to discover why when I edited an article, I only saw metadata + lead-in, but not content. I now understand that the content is a series of content blocks that I can edit and rearrange in the structure editor.
Looking at the "A Shifting Reef" demo article, it's still somewhat surprising to me that a document containing a lead-in, a paragraph, a blockquote, three more paragraphs, and an image can't be edited as a whole document. Instead, it appears to be treated as an array of [pagemeta], [text], [blockquote], [text], and [image], all of which must be edited separately.
My understanding is that if I wanted to move the image up two paragraphs, I'd have to:
1. Open the Structure Editor
2. Create a new, empty text block below the image. Save it.
3. Open the text block before the image, cut the last two paragraphs. Save it.
4. Open the bottom text block, paste the two paragraphs. Save it.
If I lose my clipboard between steps 3 and 4, I lose content. Similarly, if someone visits my site between steps 3 and 4, they see broken content. Django CMS has a strong enough reputation that I'm completely willing to believe that I'm being dense and missing something fundamental here. I'd really appreciate your insight as to what I'm doing wrong, and what the expected workflow is. Because right now, that all seems unreasonably convoluted and unsafe for rearranging an image or blockquote amongst text.
I guess this would be less of a problem if I could somehow see a stack of all the structured content editors for a given articles, and change them all at once before saving, but I can't seem to find anything like that, either.
That doesn't work; I can't seem to split the text block to put the image between two paragraphs. In the demo, on the "A Shifting Reef" article, how would you place the image between the paragraph starting "The facts relating" and "Taking into consideration"? They're both part of a single Generic Text block, so my only option in Structure Mode appears to be putting the image above the entire 3-paragraph text block of below it.
If I wanted move an image around inside text content, should I be using the CMS Plugins -> Bootstrap 3 -> Image widget inside the text content editor, instead of doing it in the structure editor? Or should I use CMS Plugins -> Filer -> Image? Why are there two ways to add images to my site?
I'm not being willfully obtuse here; I'm genuinely failing to accomplish common, content-centric editing tasks. The structured content model of Django CMS looks really interesting and powerful, but its usability and discoverability seems pretty difficult for me. I'd highly recommend running some usability tests and observing real people interacting with Django CMS and competing platforms to see where people get stuck and what wrong turns they take. Jakob Nielsen has a good article on usability testing at https://www.nngroup.com/articles/usability-101-introduction-....
It is totally unusable for anybody who ever has seen the easy usability of WordPress. Please do yourself a favor and build a few sites in WP to understand how WP works and why it is so successful.
I am writing this not to attack you, it is a real life experience I had with many clients - they just look at me when I ask them to try Django CMS, asking "really???".
I would like to have them to use anything that has django under the hood, but they always take the WP road when given demo setups and some time to experiment.
Wagtail changed that, people seem to understand the Wagtail interface much better, but it is seriously lacking basic features. You at least understood that people want categories - call it taxonomies and allow multiple ways to use and edit them. Ah, just use WP for a few ways to understand how powerful that concept is.
Wix is a terrible answer, their business model is built around ripping off the ignorant, as far as I can tell. For example they'll charge you $150 for a domain name, and their service offers no method of exporting your website when you eventually decide to get a real host.
I can't speak to the quality of Weebly or Squarespace but I'd never use them, the cost is a few bucks more per month than a Wordpress site and I don't see how their services add any value for that extra cost.
How does wordpress.com deal with plugins? Do they have managed/curated distribution systems? The more I learn about this, the more I feel like core wordpress is reasonably sound, and the problems mostly arise from plugins.
> what advice should I give to WordPress users to help them improve security
It requires a bit of knowledge and a commitment to managing the deploy, but: disable write permissions for the web user to the WordPress directory (excluding the upload folder), whitelist endpoints in nginx/apache, set up IP whitelists for /wp-admin/, minimize plugin usage.
This is going to reduce the user-friendliness of the WordPress install, but it's going to immediately increase the security by leaps and bounds. If you can't exploit plugins, can't access the admin pages, can't modify PHP files, and can't hit exotic endpoints, it's much harder to compromise WordPress.
Or just let WordPress users just be users. Abstract the management of WordPress away from the CMS.
Have their access be just the content and limited/filtered by role. The built-in roles need virtually no tweaking.
We have our WordPress sites as git repositories and build via CircleCI, Ansible and Composer. For Multisite instances we use Composer and Satis and keep the themes in their own repositories and use tagged releases to manage our multisite build using CircleCI and Ansible again.
We use two-factor auth for Wordpress login (currently Duo on non-multisite installs). Nobody gets to install plugins. Nobody writes files into folders manually.
How do you handle the database in your git Repositories? I'm asking because I never found a good solution for Version control of Systems like Joomla and WordPress. Optimally I'd like to be able to install and Setup a plugin on my Dev machine, then push that to production, as I would do with, for example a Rails App.
We only version the wp-content folder. We have automated db backups that we retain in multiple locations on a schedule.
Our hosts let us duplicate the db various ways between staging/prod and we just do a copy and search+replace for local development. We used to use WP DB Migrate Pro for that last part but it is buggy to the point of nonfunctional now.
So yes, you do have to do plugin setup/site configuration on dev, staging and prod. I don't see a good workaround for that, but the duplication of work leading up to production has allowed us to catch problems before hitting production.
I've been telling people to host wordpress sites on Dreamhost's Dreampress. They handle core updates for you and they'll help you out if it all goes wrong. I'd also say use Shopify you're doing eCommerce. It's a pretty excellent platform, and you've got this whole army of developers devoted to reducing the security issues of Wordpress while making sure that sales keep going through.
I recommend to people that Wordpress would be a good fit for to have it hosted on Wordpress.com. You get the ease and familiarity of Wordpress with less pwnage. It's free, but $6/mo gets you the use of your own domain and no ads.
I find it's a pretty good trade off if you don't need a heavily customized site.
"what can I recommend to non-technical people when they need a website quickly and inexpensively that won't make me feel like I'm setting them up to get owned"
Good question. I recently had a brief look at a site a friend hosts with wordpress.com - and after that my "old" recommendation of going with a standard wordpress.com-hosted wordpress without extra plugins is pretty much out: it looks like with their move to a javscript/api/spa-based admin they've managed to alienate quite a bit of the theme-developers and/or left them behind -- so now there are two admin-pages (the javascript spa and wp-admin.php) -- and neither work perfectly for legacy installations...
I was already a bit sceptical of wordpress.com hosting due to the limitation on custom themes, and the hurdles needed to hop through to make a new theme that can be used with a wordpress.com hosted site...
All that said, plain wordpress along with a modern php-version and the wordpress-cli still looks like it's an option. The major caveat is that as soon as you get a "wordpress hacker" to "enhance" the site - security appears to go out the window (feels like a third of the traffic on the full-disclosure list is still wordpress plugins. Rarely wordpress core, though).
With that dismal news out of the way, ghost.org + ghost.io hosting does look quite reasonable for a blog (basically what you get with "plain wordpress" anyway). It looks rather unsuited for anything that's not just a blog, including a full image gallery (there are plugin/themes, but ghost is explicitly not a content management system, and doesn't really have any real media management to manage uploaded images in galleries etc. Perhaps ghost.io + something like 500px.com is a possible fix).
Other than that, I have a good impression of netlifly -- but being focused on static sites, it might be a though sell for someone that would really just want "a simple wordpress that works and looks beautiful". I'm not sure, I've only toyed a bit with it, and enjoyed their various excellent "using netlifly with X" blogpost (a really shining example of corporate marketing if you ask me - I don't think any other startup/kickstarter/company mailings manage to reach near the nice quality that netlifly seem to reach effortlessly (a typical indication that a lot of effort is put in, btw :-).
(They're all mostly the same, and don't go into much depth, but probably gives a fair idea of what Netlifly is and is not).
[ed: Another option might be to get an account with Sandstorm, and host either Ghost or Wordpress along with (maybe) some kind of gallery - or just some form of wiki:
It's the cheapest, most capable, most user-friendly CMS available. It has the largest community, which means it has the best support and greatest plugin availability.
There's nothing wrong with running E-Commerce on Wordpress also, as long as your payment solution does not include storing sensitive data such as credit card numbers in the database.
"How do I improve security" is a question too in-depth for a forum comment. You need to spend some time researching that using your favorite web search, in my humble opinion. Just keep in mind there is not one cure-all solution.
> There's nothing wrong with running E-Commerce on Wordpress also, as long as your payment solution does not include storing sensitive data such as credit card numbers in the database.
This is just not true. Suppose I get write access to the content your Wordpress site is serving. Now I can replace, say, the Stripe (or any other managed payment solution) JS and HTML with my own, to save the CC info and forward the unmodified request to Stripe. Game over.
Just to gather some of the other comments together, if you're a Django developer already, then you're used to more difficult deployments.
So anything that goes in the direction of easier (WordPress-style if you wish) deployments is going to be a big bonus for the Python/Django developers who are already committed to the language or the framework, and is going to be a big win for the service that can provide it.
I don't think I am giving away any of grand secrets if I say that that's what we're doing (and trying to do more of) - be a first choice for Django/Python developers.
For the Django developers, it doesn't need to be as easy as WordPress - it just needs to be easier than the other options (which seem to begin with hammering bits together by hand until you have a working server, sometimes).
(That may not be enough to bring in users who may have gone for WordPress, but that's a further ambition.)
In the meantime, easiness really is important, which is why I think there is so much to learn from WordPress's success, but ease-of-deployment is definitely not the only thing that's important.
For example, I don't think it's an unfair comment to say that one flaw WordPress has is security, and that Django/django CMS/Aldryn are much more secure, and that alone should be something people think about.
Or: there's more to hosting than dumping some files into a web server's directory. New deployment technologies such as Docker make it possible for a Django site built on Aldryn to be taken away and hosted somewhere else in minutes - being able to migrate your deployments if you wish to isn't an eye-catching advantage, but it's really valuable from a business point of view.
Or yet again, Docker makes it possible for a cloud hosting platform such as ours to be way more than just a hosting or deployment platform. It's also a development platform, with tools that integrate the desktop and the cloud and make the work of the experienced application developer easier, not just that of the non-technical person who wants a new site.
Anyway, that's a slightly long-winded way of saying that the lesson from WordPress is extremely valuable, but the way it applies to Django doesn't mean that we have to compete on WordPress's terms!
I don't see why Django CMS will be more secure than WordPress or other way.
From a coding point of view, the more people works on it, the more chance the security issue will be noticed and fixed. Rails, Django or any framework in general always have security issues at some time.
The issue of WordPress is come from the easy to use. The ability to install plugin require write permission from the user that run WordPress.
Second, many WordPress plugin expose executable-php file in plugin folder that is invokeable via hitting directly that url.
So if Django CMS has that ability, allow downloading 3rd-code and run it, I'm not sure if it's more secure than WordPress.
WordPress is just as secure as any Rails or Django app. Bug happens, people fix.
Shopify's EmbeddedSDK does plugins (or "apps") very securely, but it comes at a development price. Instead of getting write access and running code on the server directly, you basically interact with an API via an embedded web page. Basically an Iframe. The API is more secure than getting to execute arbitrary code; but it is more restricting as a developer. Not perfect, but much better.
It's ironic that what's behind WordPress's fabled ease-of-deployment (i.e. allowing third-party code to be downloaded an executed) is also what's behind many of its security weaknesses.
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.
Installation isn't even half the battle. Updates are the killer thing in the Python world that even seasoned Django devs (raises hand) get wrong every so often.
Sure, you can `pip install -Ur requirements.txt` but will it work? Do I need to set up continuous integration? Testing servers? What happens when there are backwards incompatibilities between elements?
As things are you need a Django dev on staff to run a Django website. There is no dev-deploy-dump process that Wordpress "designers" get to enjoy. It's constant.
To really compete, Django (not just Django CMS, IMO) needs environment monitoring, testing and upgrading baked in. Many will argue that it's not its job —and they aren't wrong— but nobody else seems to be willing to do this in a way that anything but a seasoned programmer capable of running.
No matter the author's contention, PHP apps are still much easier to install which is pretty much the sole reason for PHP's original and continuing popularity.
Exactly - every £2pcm shared hosting plan allows PHP, you need to actively look elsewhere for something "more exotic", and know what you should be looking for to begin with...
This is a great contribution but it seems to be tied to a single vendor, and subject to the vendor's pricing.
This is fine, fair, good etc. It is not a criticism of the service, but when digital ocean offers a one-click install of django-cms or mezzanine etc, I think we'll know it is in the mainstream.
I love python, and Django is awesome, but to claim that the paid for Aldryn Cloud comes close to the WordPress.org 5 minute installation [1] is stretching it.
It's not just about the time taken it's about the almost complete flexibility of any web server anywhere.
The Aldryn Cloud is if anything similar to the WordPress.com setup where you just fill in a form and they handle the hosting for you.
But WordPress.org had their 5-minute installation sorted out 10 years ago.
N.B. That now along with the installation you have a complete choice of what language you want your entire system in. The amount of work that has been put into translation by WordPress and making sure that the entire rather huge ecosystem can be translated is phenomenal.
They have some pretty good automated system testing for security flaws in the plugins that are submitted. I've witnessed what happens when one fails. They send you what the problem is and how to replicated it.
Bare in mind all of this has been done through open source code with what I'd say is still done with companies that are run with very little greed. You won't find Mark Zuckerberg here answering questions on HN, but Matt Mullenweg has long been giving answers on here [2].
The trickier part is deployment, which is where WordPress (all PHP, really) truly shines for ease-of-use - and this is where our Docker-based Aldryn Cloud platform intends to bridge the gap, by making that just as easy for Python/Django users.
Shouldn't you compare Django CMS to Wordpress, not pure Django? If you want to do code changes in Wordpress, you need to understand PHP + Wordpress conventions as well.
To be fair, Django doesn't make you adhere to that pattern and you can use Django any way you please. Django has a lot more "in the box" than Flask and I will agree that I think it's more difficult to get started with.
Not to mention that Django is a framework and WordPress is an application. It's like comparing a box of Legos with a box of unmolded plastic and then declaring that the former is easier to play with.
To continue with the analogy one might say that Django comes with the molds but you have to know how to use the furnace and how to make the bricks without them turning out crappy. Much greater potential because you can make whatever you want but also higher barriers to entry.
Yea you are correct. Just saying when you read a Django tutorial and they say a "View is not a View", meaning that the Django View is different... that is not exactly newbie friendly.
I'm not so sure, I understand Model-View-Template much better than I understand Model-View-Controller.
And for a real beginner, what a view is doesn't matter at all; what matters is how quickly they can start to feel they understand what they are doing with the system.
So your argument from personal knowledge is why something is easier or harder :)
Here's my experience: Having attempted to do semi-meaningful things in both a few years ago, I can tell you that hacking on wordpress and figuring out its internals (as a newbie in php) vs hacking in django (as a newbie in python) that the django experience was orders of magnitude more effort.
To be fair to Django, their concept of View is closer to what it meant originally, before MVC was adapted by Rails et all. And if you're a complete newbie, you don't have any preconceptions of View anyway. It's only a problem if you come from other Web frameworks.
They're talking about Django CMS, not the framework. It's a CMS just like WordPress. You don't have to know programming if all you need is a simple page, a blog, or the likes.
I am a Python/Django developer. I am not a WordPress fan, but I am not above recommending it to people, provided that they understand what they are getting into. This is what I generally tell people...
- WordPress as an 90/10 solution: You can get 90% of what you want for 10% of the effort, and you don't have to be a programmer to get most of the way. It is that last 10% that will suck 90% of your time, and it won't be pretty. In fact, it will probably be terrible and (as a developer) you will feel very icky about yourself when it is done. If you can be satisfied with getting close-to-but-not-quite what you want, then you will probably be happy with WordPress. If you are very particular about that last 10%, then you will probably be in for a world of pain. It may end-up costing just as much (or sometimes even be cheaper) to go with a custom/Django solution in those cases.
- WordPress works well as a basic publishing platform. That was what it was designed for, and that is it's sweet spot. It isn't however ideally suited to application development. The further you head down the path of trying to make WordPress behave outside of the standard content publishing paradigm, the more painful and difficult it will become.
- You absolutely have to stay on top of security and updates. If you aren't willing to spend that time, then you will end-up paying for all the time you saved when you set things up by having to deal with security fallout.
I recognize the appeal and place that WordPress has in the marketplace. I also recognize that people that need it are not my target clients. I have learned that my sweet spot for development is to fill the niche where WordPress isn't a great option.
Gosh if you can show me a system that non-technical people can install, load up with plugins, and start building sites with right away, I'd happily start telling people about that instead.
These days, for the audience Wordpress serves, there is no competition. Not even close.
I have had the exact opposite experience. As long as you install one of the common security plugins (and not much else), then you're fine. And all those plugins do is ensure things like strong passwords and auth retry lockout.
A large part of the problem comes from the many, buggy plugins you can one click install from within wordpress.
While that is mostly true, the amount of available plugins is one of the main selling points of WordPress. So if you have to avoid plugins altogether to stay safe, or don't need the plugins to begin with, you're probably better off with something saner (like bolt CMS).
People (product, marketing, and so on) also always demand to install plugins (usable multi-language support, "SEO features" and all kind of things).
Oh, and you'll also need some kind of caching plugin, because all that plugins are making it insufferably slow.
And you want to keep it up to date (and plugins!) and fast, because security issues and worms taking advantage of it always lurking around the corner.
I've got plenty of bad experiences with WordPress. In my opinion, in the long run we would have been better off with our own custom solution (we maintain our own proprietary PHP framework anyways, and we had code that would have covered most of the requirements. Management will always insist on WordPress for "saving time").
I'm snobbish about Wordpress too, but it also keeps obnoxious web marketing people out of my hair and busy with their site. Long as they don't go too overboard with plugins....
I really want Aldryn to succeed. I have tried to test it out, and my major issue is documentation and not so clear UI.
For example, it's not clear to me how can I clone project I created on Aldryn and work on local. It's been about 10 minutes I am clicking around, still can't figure it out. Do I have to use Mac app? Can I work on as usual Django project on command line and just do git push when ready? Even docs here isn't clear to me http://support.divio.com/hc/en-us/categories/200815715-Local...
Btw, that django cms demo with Aldryn boilerplate is kick ass.
Edit: After lots of clicking, I found how to install aldryn client.
If you're having any trouble getting to grips with it, don't hesitate to drop us a line - on our live help system if you wish: https://www.divio.com/en/#intercom
The only truth about Wordpress being so successful is its theme availability. Envato can for sure be responsible partially for its success.
It's not that Wordpress is good, or great or that much extensible. One could easily look for ExpressionEngine or Craft, if that would be the case.
But if you want a 1-click install, plus slap a 50$ theme on it, and your stuff to look pretty good, Wordpress is a viable solution.
However, if you want to customise stuff yourself, things become really dreadful very quickly. Anyone saying otherwise, hasn't done so.
All the other stuff, about any of its "goodness" as addressed here in the article, is basically the author doesn't knowing any better, what a real CMS is supposed to do.
It's not especially difficult to customize a wordpress theme. At some point people who are not developers need to hand the reigns over to developers.
I often see posts from people asking someone to teach them PHP in a few days so they can modify their Wordpress install, and I think why would anyone who's spent 2 decades learning how to do these things for their bread and butter want to do that?
If developing is your career then you've got time to learn, and if you don't got time to learn then pay someone who's made it their career.
Do you see real economic opportunities in the Django-CMS space that will lead to people investing effort in it and improving it to the point where it is an option for the kind of people who use Wordpress?
At the moment, the WordPress market economy is based largely on small margins over very large quantities. django CMS definitely isn't in that space, or even aiming for it, right now.
In the meantime though, we know that django CMS is a serious choice of Python/Django agencies and large corporations and other organisations.
You can see django CMS mentioned in job advertisements on a regular basis.
A surprising number of large corporate websites use django CMS.
There are numerous businesses in Europe and the USA that are django CMS specialists, building websites including CMS components for their clients, all based on django CMS.
django CMS is a free open-source product, but has paid developers working on it full-time.
Finally, it's sufficiently well-known and well-used to warrant the creation of Aldryn, a cloud deployment platform that was built around serving django CMS (even if now it also serves Django more widely).
Again, it's not the scale of economy that exists around WordPress (but then what is?), and there are many things that we hope will grow over the next few years, such as a thriving marketplace of not just free open-source but also paid-for addon applications, and even competitors to Aldryn.
Today you can go to GoDaddy, rent a VPS relatively cheap, fire-up a Wordpress install and be up and running with a website and full email service for a small business inside of one hour.
Attempting to achieve the same with Phython/Django/Django-CMS on something like a Linode is an exercise of frustration.
I love Python/Django yet, more often than not, I have no choice but to point people towards Wordpress.
I know both systems and will not fight for one or the other. I will try to summarize the most annoying points in both systems.
Many things in WordPress are brilliant, and none of the Django content management systems got that right. Every WordPress user can very quickly learn to actually manage their content with taxonomies (categories, tags, or custom made ones), and then build e.g. a menu or special pages for a category very easy out of that categorizations. This is brilliant.
Also the hook system is great, so easy to add and combine pieces of code, one of the reasons for that enormous amount of plugins (of course not all of them are of good quality, ahem).
Also the extremely easy extension via custom post types and custom fields allows to build a lot of things very quickly. Try to build dynamic models with Django - a major limitation that is seldom talked about, but very important. This is one of the most boneheaded Django dead-ends that I have hit - how can a system that is build for dynamic content generation make it so hard to dynamically define and generate models? There are some approaches, but you are getting into 'fight-the-system-mode' with all of them, because that boneheadism is build into the basic design of Django.
Of course, the code base of WordPress is very old and a constant source of trouble, if you are depressed, go and read some WP code, you will have fun, I swear! But it must be said that it is really great how the WP devs keep up backwards compatibility - you can run and update the system for years without worries, this is very important for a cms!
Django devs did not understand that. So many people are lagging behind with updating their Django apps / projects, because the django devs missed this most important point! So many changing things, stupid little things, but breaking and mutating like a radioactive godzilla, you see the results in a universe of incompatible django apps. They missed completely that it is a good thing to "never break user space", really a problem here. Do not change the API! Thanks god they started to do that LTS thing now, so there is some hope now that serious enterprise business will take a look at Django.
Luckily WordPress now has automatic updates, so admins do not have to panic so much. Biggest problem, of course, is that annoying dependency on MySQL, I hate it, and I also hate the catastrophic generation of sql queries - and do not even try to look at the mysql query log when you install the super-bonehead-ultra plugin by mister uberhaxor!
But caching is mandatory anyway, or even better, export to static pages. Do not even put that WP on the internet - let authors write to an isolated environment and export all the pages into a static cache after updates. Do not allow comments.
If only all these great WP ideas were implemented on top of Django, that would be perfect.
But all the existing Django CMS are extremely far away from the easy WordPress usability. Like WP was made by artists and all the Django CMS made by bureaucrats. Wagtail has some future, but is still missing many, many features, also I see some problems with the content model, having to define a new model for each new type of content will not work in the long run - they are hitting that annoying Django design limitation here - it is not a framework build for dynamic models (eat that absurdism!).
There must be something inherently wrong with Django that it seems not to be possible to build a feature-rich CMS that tops WP easily - everything that exists is extremely beyond the state of the art, unfortunately, and I wonder if that has some reason connected to Django. Any PHP project would have millions of plugins after such a long time (working and compatible) - meanwhile you can be happy if you find a Django app that works out of the box with the latest Django release, lots of bitrot. Even the demo apps sometimes do not work, try to run the mezzanine 'drum' hacker news clone. This must be a management problem, but I do not understand these things, however that problem exists and it is annoying. You are riding high he Django train, but fall deep with non-working apps all the time, this can be even worse than the WP plugin hell.
WordPress is technically inferior, but there are so many brilliant ideas in there.
Django, technically superior in any way, still misses anything like WP, none of the CMS come close to the WordPress experience.
In other words: there is still room for innovation!
Just compare for yourself, looking at any of the Django CMS in 2016 will be like a time travel back to 2010.
Today I hope that some people will re-implement WordPress with Elixir and the great Phoenix framework. The Django Channels project will not be enough to survive that.
This is a fascinating analysis. I'm the CTO of the agency behind the Wagtail CMS (https://wagtail.io) which you reference. People like NASA, Google, Peace Corps, PBS run sites on Wagtail but I'd use WordPress for my friend's 5 page site because:
- < 5 minutes to organise cheap hosting
- automatic updates
- zillions of themes
- someone else can fix it when it goes wrong
I hope Daniele and his colleagues at Aldryn will help with quick cheap Django hosting (they do Wagtail too!). But I'm not sure that Wagtail or Django CMS will ever be the right choice for this use-case. Of course you _could_ build a WordPress equivalent in Django, using postmeta-style key-value tables that abuse relational database theory but allow plugins to define their own content types, and maybe someone should. Our effort is going into building a CMS which helps implementers of non-trivial sites do the 'right thing': keep their content structured, clean, related, filterable. Create once publish everywhere!
There's a lot to learn from WordPress but I don't think 'dynamic models' are the answer for situations where you have more than one developer (there's no guaranteed parity between developer and production environments) or lots of relations (postmeta-style tables have ugly joins, weak integrity checks, poor performance).
It would be fantastic if Wagtail had anything similar like the WP taxonomy - content organization idea, this is the only part missing on the way to a real WP killer.
This is not only about ui - giving users the power to build menus via the ui is great, but the real thing that happens is that people have a great way to actually _manage their content_ - for an experienced WP user it is easy to add a new category menu, add some special section for a limited time or completely restructure a site, etc., this is possible because of how they implemented the usage of taxonomies and how you can structure your site with menus and category pages based on that taxonomies or pull the content with a simple WPQuery. This is very powerful!
If the answers in this thread are right and it is only possible to implement this usecase with custom model classes for each category, then this is a serious design limitation that should be considered. I hope there is another way doing that and I simply missed it, if there is, please make a blog post about it, I beg!
It's about the ideas. I do not want to discuss WP vs. Django on the level of technical details, I understand the context, I understand the code and I know where WP is used and where Django and such a discussion is nonsense.
BTW I would love to use Wagtail for all projects, but easy handling of catregories (lots of them) is very important for long term content segmentation.
Most of the sites we build on Wagtail use taxonomies / categorisation, either with a foreign key to categories defined as snippets, or with custom model classes for each page type, as you describe. You're right that Wagtail has no 'native' equivalent of WP's Categories, and perhaps that's a mistake. You're also right to focus on ideas and usage over technical details; we fall into this trap too easily.
I'm very interested in talking more about this, but without derailing the topic. Please email me on my first name at torchbox.com.
I'm a dev who came from the Rails world to a primarily Wordpress one in my current gig.
Wordpress still has some pain points for me (schemaless database) that are only half-solved for me with plugins (mainly ACF Pro and Post To Post Links) and a lot of code. I've basically built a request router and ~MVC into Wordpress several times over, but not something I'm satisfied with enough to release to public.
Most of the practices that we're used to elsewhere can be applied in the Wordpress space.
Our build process relies on GitHub, Composer, Satis, CircleCI and Ansible (and we use Homestead locally). We use modern hosts who are amenable to git deployments so we don't have to use sftp. It took some work to get to here but it's easier. Honestly it's far easier than most of what I've had to deal with in the Rails space.
Wordpress, for the right kind of sites, can be great to develop on. Truly great. And it's always great for content creators. I have yet to see another CMS deliver half that experience for content creators. Please, show me one -- so that I don't _HAVE_ to use Wordpress anymore.
This gig has been interesting though. I see it as an opportunity to bring saner practices into the WordPress space. If anybody is going to LoopConf and wants to have a beer and a chat, let me know.
Keep the plugins to a minimum and you'll have a great time.
I agree. A lot of folks have worked on the latter but I haven't seen much of the former and had to build it myself.
In both cases what I did was highly specific to the spec of the WordPress site. I've yet to come up with something generic enough and well-built enough that I'm comfortable sharing. That's a problem with the WordPress ecosystem in general I think.
The key moment to understanding Wordpress was realizing that its use of hooks and filters are the publish-subscribe pattern. You can just hook the `parse request` action and then do whatever the hell you like as long as you make sure that the `query` (and ultimately `wp` object) that comes out at the end of the process doesn't have something unexpected in it (tricky!)
I would say not currently. If anything, I'd say that Docker can make creation and deployment of complex systems more complexed. There's various tools (and work on docker itself) to attempt to simplify this, but I'd say the tooling isn't quite there yet.
This is exactly where Divio comes in with the "Aldryn CLI" and "Aldryn Desktop App". The mentioned tools allow you replicate complex setups with a few simple clicks on your local machine, without having to learn the whole architecture of Docker & co.
We'd love you to try it out for your feedback, it's a huge effort for us and it's been great to have the encouragement of the Django/Python communities, but when we start making traction with WordPress and PHP users we'll know we're really getting where we want.
I'll give your platform a try soon. I've exclusively made wp sites because it is quick and easy to accomplish what I want, as long as it is simple.
If you want to make traction with the wp crowd, you'll need a website redesign. Go to wordpress.com and there is literally a button that says "create website". Your website says "lifting django into the cloud". What the hell does that mean? (I know what it actually means).
Sign up and deploy a site in the cloud? No... I just want to make a website. I don't want to deploy and sign up. etc. (I know its the same exact thing, your marketing will just have to change.)
Wordpress really screwed up by having a schema-less database. Everything in the database is a key-value pair. This means actual relational operations now need to be performed in PHP, instead of letting the RDBMS handle it. This significantly slows down the CMS, and so you have 1-2 second page response times.
Meanwhile, my Django sites have response times in the 10-20ms range. (And that's without caching.)
"Everything is a key-value pair" is flat out wrong[1,2]: There are four key-value tables (commentmeta, postmeta, termmeta and usermeta), but most of the meat of Wordpress is stored in regular tables.
if you're just using WP as a blog engine only, with basic functionality, you're fine. that's what it was built for, and shines.
wp_options is a key/value table, and seems to be abused a lot.
storing "transient" data in wp_options - what's up with that? why not at least have a 'transient' table, separate from the table that stores my ... options?
and... when you've got plugin systems that store everything in postmeta... it's hard to do "normal" relational queries. woocommerce seems to be a good example of this - order info in postmeta?
"find all orders in tennessee with more than $10 tax"
can only be done with multiple self-joins on wp_postmeta.
Perhaps they shouldn't have built it that way, but in my experience most plugin authors use what's provided, and what's provided makes them jump through hoops to do basic stuff, and is not well suited for larger scale apps (but people get suckered in to it anyway because it's "easy to get started"). Who do you blame for these decisions/mistakes? WP? Plugin authors? End users?
Putting even a very short lived cache in front of it basically removes the issue. But perhaps asking people to understand, for example, nginx micro-caching, defeats the purpose of WP.
I'm not terribly concerned about WP performance, it's just a blog, after all - it's the security issues.
I wiped the caches on my largest recent Wordpress (very complex, post2post links and all archive pages including home page are generated via lookups to metadata tables) site and the response time was 28ms.
Only if you conflate "NoSQL" with "pretend everything is Redis".
That's why the term "NoSQL" (or even worse: "non-relational") is often pretty much useless: many people think it refers to one category of databases like SQL/relational does.
So I critiqued the Aldryn Cloud solution and Django CMS's approach on the Disqus comments on their blogpost and it was swiftly rejected. This product is far from the values of open source Wordpress is built on.
Got it. I saw that a newer comment was approved so I assumed mine was rejected. Apologies for that! I think the newer comment that was approved was probably just from an account that wasn't moderated.
Also what advice should I give to WordPress users to help them improve security, other than the rather useless and bratty "don't use wordpress lol" answer? I'm a security professional and I follow the constant stream of "lol WordPress exploit" articles, but proactive security measures for WordPress are a bit outside my usual enterprise infrastructure work.