Making Django CMS as easy to install as WordPress
django-cms.org
django-cms.org
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 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.
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.
You can run `wp-cli core update` to update the core WP files. It can also update plugins.
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.
2016 Joomla is as easy as WP to update, and easier than WP to install.
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.
I think my own recommendation progression has been something like (starting from my early programming days till now):
- My own homebuilt CMS
- A standard CMS like WordPress etc
- A SaaS solution like SquareSpace or Shopify
I really feel like the managed solutions are just that more convenient in the long term, also for the clients own sake.
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.
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...
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.
Most unmanaged "hosted wordpress" packages are shared hosting, which is junk for a serious business website.
Or if you would like to compare it with actually working on the site as a developer rather than just as a content editor, then it would be https://www.django-cms.org/en/blog/2016/02/16/build-a-websit....
What further improvements would take it right up to, or even past, WordPress levels of ease-of-use, in your opinion?
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.
5. Same with Blog -> Add New Article.
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.
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.
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-....
Your feedback has been very helpful and is much appreciated.
We're on https://www.divio.com/en/#intercom amongst other places, but that's the easiest way to speak to us directly if you like.
Thanks again.
But they know WordPress.
Are there text-based alternatives to your video?
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.
A SaaS website builder and host like Squarespace, Wix, or Weebly.
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.
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.
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.
Minimal plugin usage is a solid recommendation.
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 find it's a pretty good trade off if you don't need a heavily customized site.
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 :-).
See eg:
https://www.netlify.com/blog/2016/02/24/a-step-by-step-guide...
https://www.netlify.com/blog/2015/11/02/a-step-by-step-guide...
https://www.netlify.com/blog/2015/10/06/a-step-by-step-guide...
https://www.netlify.com/blog/2015/10/15/a-step-by-step-guide...
(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.
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.
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!
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.
No. Rails & Django have vast smaller attack surface than PHP's default.
Doing that is pretty much impossible in Django.
There's a lot to learn from WordPress and PHP.
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.
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 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.)
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.
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).
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.
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).
Wordpress users have a poor security track record.
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.
If it's something like Squarespace then what's really happening is you're paying someone else to babysit it for you.
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.
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.
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.
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.
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.
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.
That guy taught me well about my being snobbish.
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.
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.
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.
Also, an exploitable XSS in your web application can be just as damaging as a server compromise.
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.
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 started out learning PHP on a LAMP stack on an old laptop, and reading C tutorials online. Probably my best move was working through SICP.
If they were math-inclined and weren't worried about immediate employability I'd recommend SICP even though Scheme is irrelevant in industry.
But if they wanted to make money as a web dev as fast as possible, JavaScript makes sense.
Ninja edit: yep. (http://asmblah.github.io/uniter/demo/interactive.html)
So you could run a PHP VM on top of a Javascript VM in PHP.
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.
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.
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.
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].
[1]: http://codex.wordpress.org/Installing_WordPress#Famous_5-Min...
Have you tried Mezzanine? I heard that was even easier to set up, and might be a better candidate for a transition to 1 click.
To do Django you have to know Python, which is a big assumption. For Wordpress you need basically zero programming knowledge.
Also compared to Flask, Django is much more complicated by making you adhere to their MVT (Model-View-Template).
We even have a tutorial series especially aimed at non-Python programmers: https://www.django-cms.org/en/blog/2016/02/16/build-a-websit...
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.
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.
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.
I'm not being sarcastic, everything is a tradeoff, usually you have to cut corners somewhere.
- 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.
These days, for the audience Wordpress serves, there is no competition. Not even close.
I'm snobbish about them, too.
It's just better to stay away from it. It's not about being snobbish. It's just pointing out the truth.
A large part of the problem comes from the many, buggy plugins you can one click install from within wordpress.
But isn't that the main benefit of Wordpress - the huge amount of plugins?
For me, it's for my handful of non technical users to be able to publish posts and have a central repo for sharing event information.
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").
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.
pip install aldryn-client
Otherwise, both https://www.django-cms.org/en/blog/2016/02/16/build-a-websit... and the Guided Tour https://www.divio.com/en/academy/aldryn-cloud-django-cms-gui... will help.
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.
Before I understood hooks & filters as publish-subscribe? sure. Afterwards? No way.
Do you want to know what's dreadful? Having a content team that needs to build 10k pages of content in a Rails site.
Do you know what's not dreadful? Having a content team that needs to build 10k pages of content on WordPress.
The latter can be supported by just me. The former? I don't even know.
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.
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.
So the answer is yes, in a word.
Does it come up with full email installed?
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.
...and then there's the Python 2.x/3.x mess...
Beaverbuilder is the most talked about modern page builder at the WordPress meetups I attend.
Try to build a homepage layout like airbnb.com with your tutorial and again with beaverbuilder. You will find a huge technical difference.
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.
- < 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).
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!
People need categories, e.g. (not me): https://groups.google.com/forum/#!searchin/wagtail/category%...
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!
I played with django tag-it and maybe there is a good way to combine it with this wagtailmenu https://github.com/rkhleics/wagtailmenus
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.
Thanks for your attention!
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 asking, I don't have any real experience of docker)
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.
That sounds really interesting and something I think a lot of devs would be interested in.
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!)
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.
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.)
Meanwhile, my Django sites have response times in the 10-20ms range. (And that's without caching.)
[1] https://github.com/ronaldbradford/schema/blob/master/wordpre...
[2] https://codex.wordpress.org/images/2/25/WP4.4.2-ERD.png
[EDIT: Corrected myself about the number of KV tables]
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?
That's where the meat is. Literally, if you're an e-commerce deli.
I'm not terribly concerned about WP performance, it's just a blog, after all - it's the security issues.
Isn't that the crux of the whole NoSQL "revolution"?
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.
We won't reject comments unless they are offensively rude, spam, wildly off-topic or otherwise significantly problematic.
We can withstand a little bit of criticism...