At the best one it only took 3 separate SQL Injections which got their database dumped and two defacements to make them decide to go back to one of the big CMSes. If you go complete custom, you do it at the cost of repeating other people's mistakes.
The CEO of that company took it upon himself and put the custom dev budget, and then some, into an actual site security company.
They did nothing much but keep the cms and it's plugins updated and have the traffic filters coordinated with current best practices.
Of course they printed nice reports of all the updates that were installed and through that the threats prevented, in case the customer thinks that because the carpet is clean they can fire the cleaning lady.
Content management is very much a domain specific problem which generic CMSs like Wordpress and Drupal solve poorly. For example, have a look under the hood at Wordpress's database schema and you will find that it is ill-equipped for anything more than basic blogging (which is its main intention in the first place). Building a custom CMS that meets a company's business requirements does not mean writing everything from scratch. High quality frameworks exist in just about any language you can imagine which provide abstractions for handling user authentication, prepared statements, XSS mitigation, session handling and a whole host of other items. As with any software development, the quality of your software is tied directly to the quality of your developers. The "big CMSs" will not stop a poor development team from making bad decisions.
>The "big CMSs" will not stop a poor development team from making bad decisions.
Depending on the Project they absolutely will. Consider the economic context this is happening in.
There is a staggering number of companies that can harden and secure a WordPress or Drupal Installation. They have scalable workflows that allow them to keep the attack surfaces small, keep up to date with any security issues and even deploy countermeasures before any fix is released.
The market is just big enough for those services to exist. Now consider the same for a custom built Symfony or Laravel CMS.
Besides that, the number of companies that are able to harden, maintain and host is much, much smaller, because their workflows can only scale so much.
So your gains are not really on the security side of things, rather on the implementation flexibility. Which CAN mean a much more Resource Intensive Project.
Drupal and WordPress both have their birthdefects which have ingrained so far into the community that you can't expect them to be ever worked out fully. This leads one to your conclusion that because they aren't doing some parts of their job particularly good, they shouldn't be considered.
Having worked on large WordPress, Drupal(just when Drupageddon happened) and Symfony Projects I can say that from the viewpoint of a customer, the CMS Win out simply because they make the chain of people working on the project more accountable, comparable and replacable. The risks of being technologiclly dependent on the few people that wrote your custom CMS just arent worth it for the customer. The Risk of Running the same Wordpress Code as millions of others sites is manageable in comparison. With Drupal you can go as far as just calling Acquia if all else fails, their customers were safe on Drupageddon since they could just Filter the malicious requests. You can't expect your Symfony Hoster to do something similar when their day comes.
If you are in the business of content and your mission objective is entirely driven around delivering content to your users, you will have a dedicated development and operations team. Your users are the customers and they demand content delivered to them in any number of ways and means. WP's shortcomings increase exponentially when you operate at scale.
> This leads one to your conclusion that because they aren't doing some parts of their job particularly good, they shouldn't be considered.
When it comes to content, your data layer is not just "some part". It is a fundamental component and critical aspect to get correct for sound, scalable content management. WP's database schema and abstraction layers fail miserably at anything beyond the context of a basic blog. I understand WP bills itself as a CMS, but its data handling and architecture says otherwise.
> The risks of being technologiclly dependent on the few people that wrote your custom CMS just arent worth it for the customer.
If your CMS is written in Django, RoR, Spring, etc, you aren't anymore dependent than when you are leveraging Wordpress. No WP installation is without heavy customizations to finagle it to become a poor man's CMS and some group will still have to manage/maintain the mountain of technical debt you've left behind by deploying WP in the first place. Furthermore, the landscape of quality software developers in WP land is bleak to say the least.
>If you are in the business of content and your mission objective is entirely driven around delivering content to your users, you will have a dedicated development and operations team. Your users are the customers and they demand content delivered to them in any number of ways and means. WP's shortcomings increase exponentially when you operate at scale.
Have you looked at the Mossfon pages? They are barely more than sales pages, nothing outside of the scope of WP or Drupal. You can't expect everyone who wants a Website with Basic functionality to have dedicated ops Teams, that would make it unfeasible for the majority of companies to run their own websites.
For most businesses the page is not the business, even more so for a company like Mossack Fonseca.
> You can't expect everyone who wants a Website with Basic functionality to have dedicated ops Teams, that would make it unfeasible for the majority of companies to run their own websites.
I don't and the very first thing I mentioned is that content management is a very domain specific problem. In some cases, WP may fit the bill, in many cases it does not.
At the best one it only took 3 separate SQL Injections which got their database dumped and two defacements to make them decide to go back to one of the big CMSes. If you go complete custom, you do it at the cost of repeating other people's mistakes.
The CEO of that company took it upon himself and put the custom dev budget, and then some, into an actual site security company.
They did nothing much but keep the cms and it's plugins updated and have the traffic filters coordinated with current best practices.
Of course they printed nice reports of all the updates that were installed and through that the threats prevented, in case the customer thinks that because the carpet is clean they can fire the cleaning lady.