Maintaining a CMS is a lot of work. We all stayed up late last night patching all our supported sites. I think it's worth it for companies to completely outsource maintenance to specialized companies. These recent patches seem back up that claim. I'd guess that the vast majority of unpatched sites are self-maintained.
Yes some small companies and personal web pages could be replaced by static HTML with minimal inconvenience.
But most companies benefit greatly from a CMS.
How about instead of telling users not to use a CMS, the CMS developers start listening to the security concerns that have been brought up to them again and again for the last 20 years.
This isn't any kind of panacea either. This works up until the contractor/contracting company goes out of business, decides they no longer want to work on "unsexy" products or get dropped because management hasn't a clue as to why they keep receiving invoices from a random company. I've seen variations of scenarios like these play out time and again. I think more companies need to realize that they are in fact now software companies in some shape or form, take ownership of their code and make the necessary personnel hires. The days of outsourcing everything IT are over.
These original web publishing systems used to have a complete separation of back office and front end. For large publishers back in the day, one of Drupal's major innovations was the concept of a single type of user who could publish using the web front end - that enabled content to be filed and updated from out of the office, covering court cases and music festivals for example. Before they adopted Drupal, I saw a case at a major US publisher where minor changes to a site layout had to have externally conducted pen tests booked in at great cost and then go to a signoff committee which met every 2 weeks - that's what applying strict backend and frontend separation entails.
Publishing to HTML isn't a new idea - it's how CMS's used to work and wasn't up to the task. Using HTML files as a caching layer as you propose is already available in Drupal but has terrible performance due to the number of variants that a modern site can generate (think about permutations of Drupal Views here) and how that hits filesystem limits and OS architecture. You also have the fun of cache invalidation and recompiling every HTML file which uses some upstream fragment you decide to edit - it's ultimately using the filesystem like a very inefficient version of what a relational database is designed for. Quite apart from the latency, that's why people use CDN's instead for caching static content.
Every piece of software we use has periodic bugs which are potentially catastrophic and need patching - yet nobody is saying we should switch to a pen and paper instead of OSX and Windows. I shudder to think what is going on in router firmware and yet somehow we are getting advice that a business shouldn't use a CMS - it's complete nonsense!
If maintenance is too much hassle, the model isn't to switch to static publishing, it's to switch to SaaS - which is exactly what we see. If your needs are too specific for SaaS, then by definition you are going to be creating a tailored solution and managing that in-house or outsourcing.
Is there any products that support CMS as backend and automatically generate HTML as frontend OOTB?
Here is the location of the Drupal plugin:
And the headless Drupal GatbyJS demo:
Have you used it with a Drupal or WordPress on a larger site? To do a decoupled site, every time someone publishes a new article or a change, you are going to have to do a ton of HTTP requests during build time for Gatsby since incremental builds are not a thing yet. If you use the Drupal Paragraphs module, that can really complicate things as well. The only way around this with Gatsby that I can think of is to have Drupal create a repository of static files that get incrementally updated. Then Gatsby could grab a compressed version of this during build & create a new version of the site.
I would love to hear thoughts from anyone else though as I'm sure better ideas must exist.
I noticed that the Gatsby WordPress plugin hits every endpoint on your site to build the graphql data store, you could probably modify it to just hit the ones you need. Additionally I feel like there should be a way to do persistent incremental builds. At least there should be a way to cache the graphql stuff. Maybe a incremental webpack build plugin exists.
It supports multilingual content, custom content types, media... Most of what you'd do with any other CMS.
For reference, it runs the new Starbucks website .
An honorable mention goes to Netlify CMS. I just wish they had documentation on how to host the service yourself.
Kudos to the Drupal security team for their work. I bet it's not the easiest codebase to work with, but at least the security team are doing their job well.
Now if they aren't willing to even pay for that minimal level of service I have little sympathy.
You get what you pay for. Unfortunately, many of those unpatched websites end up causing trouble for others...
Who markets it as this? That's utter madness!
Drupal loves it because their tools get used on large-scale websites, and it differentiates them from the likes of WordPress. Agencies love it because the enterprise market usually means a larger budget than what you would get for a standard site. Clients love it because they feel they are paying for quality.
Of course, there's nothing stopping a development team from using a standard CMS or framework to build this site. In fact, I've had far more success with the likes of Umbraco than with enterprise-level systems like Sitecore, and we've delivered the same marketing features the enterprise systems use as a selling point. The problem is that a lot of clients explicitly say they want a site built in Drupal, Sitecore, Episerver, etc, and in an agency or in-house environment it's often not the developers making the tech decisions...
I've done my fair share of work on the things over the years and the outcome has never been the best one for the organisation.
No. Its not cheaper to hire someone to hand-code the site and then hand-code every change.
I don't know if this is solvable. A CMS is complex enough that each of its functionalities deserves the care of good product and technical designers. These pieces ought to then be integrated into a cohesive whole, a la carte. For desktop software, we were able to pull this off pretty well, with 2000s OS X as the most cohesive, successful attempt, dictated by strong design guidelines and solid enough tech... And note that they invisibly transitioned CPU architecture along the way! But when online collaboration and multi device access became a requirement, everyone flailed and forgot the lessons of the past.
I don't think the current software market is capable of something like that. Almost everyone is trying to make captive SaaS where compatibility only exists on a service-to-service basis, in a subordinate manner. Branding is more important than cohesion, and flexibility and interoperability has taken a back seat to dumbing down.
The price one pays for being somewhat lazy (and bad at designing websites).
The seriously scary part about the previous vulnerabilities like Drupalgeddon was that anyone could exploit them without having an account on the site.
This is true for Drupal 7, but not for Drupal 8. Nothing in wild has surfaced regarding SA-CORE-2018-004 for D8 yet.
"Plugins are dependencies that if not maintained actively, may cause you to fall behind on updating the core CMS. Not keeping your CMS up to date will crush your website if an emergency security patch comes out & you can't update to it."
I get that this could be said with any framework or code base, but as someone whose job is to update a couple Drupal sites, I've almost been burned on this way to many times. Content editors rely on a plugin. That plugin isn't getting updated as fast as it should & Drupal introduced breaking changes so the plugin won't work with the new Drupal version. We have to hold back an update until the plugin gets patched. Fortunately I had just finished updating our sites before this security announcement.
The best advice I can give to anyone managing multiple Drupal sites would be pick your plugins carefully, make sure you have a testing server, make sure you can set aside some time each month to run updates & fix the many issues created by those updates, and create integration tests.
It's a pity Drupal infrastructure was not up to the task of distributing updates to everyone at the moment of announcement.
drush updates its information about the latest available versions only every few hours. Which... in times of urgent severe vulns that need to be patched immediately is probably something they should reconsider.
The most reliable method is to use Git, Drush, or the patch plugin with Composer to apply the patch immediately, and push it out to your servers. Then update to the latest core version and push that out to your servers once it’s ready.
The security team usually links to the raw patch file for each new version in the CVE.
That been said, Drupal 8 might be a good fit for large sites that needs flexibility and customization, for most (smaller) projects though, wordpress seems a better choice these days, its popularity proves that.
Just move to Jekyll or similar. Combined with a CMS like Jekyll+  you can create very large sites and apps without having to bend a bloated stack to do what you it do in the front-end. You'll spend less time configuring things in an admin panel, and more time actually investing in the UX.
For reference, we used it to build the new Starbucks website .
Ghost looks like more for the hosting service similar to wordpress.com. I want to self-host, so it is not the best option.
a quick check did not reveal how Netlify does its CMS, e.g. post can be public/private/user-access-by-permissions, note CMS means I can classify various levels of access rights, i.e. content-management(instead of just publishing). Most CMS are geared towards public viewing, which is what blog does, but CMS should do more,
Drupal with its access module got CMS right(still not built-in though), Wordpress is similar, default for public viewing, but you have plugin to control each posts' access rights. I have yet to see an OSS CMS without the need of modules/plugins to make it a true CMS.
Netlify offers something but I haven't used it - https://www.netlify.com/docs/identity/
We applied the D6 patch immediately, 911b/admin/reports/status says 6.35. The avg active acct age is >10y. Anon users can do nothing. Is there anything else to fix? Moved to Drupal 04/2005.
What is the longest running D* site?
Formal verification can do nothing to help people who run software that's been outdated and unsupported for several years.
You can spend a bunch of time going from 6 to 7, or you can spend almost the same amount of time going from 6 to 8. It's not like there are major features the users need, most of the work goes into not breaking existing customization they expect.
how to report it to github
hell, look right at the message when the target is vulnerable.
Good News Everyone! Target seems to be exploitable (Code execution)! w00hooOO!
(This is not to say that you couldn't end up in a situation where you'll spend a few years and a truckload of money in a legal fight because you've released something like this.)
The feature is activated by default, you get informed when one of your instances automatically gets patched. It works very well.
Apparently they bought this patching solution from an outside vendor, wasn't able to find the name of the product though.
It's been quite the load of my mind...
* = Details in german, no affiliation: https://www.cyon.ch/support/a/wie-funktioniert-das-automatis...
Which is exactly what Drupal should do and Wordpress did many years ago. It works.
In such a world, RCE isn’t quite so scary. Not quite. (Yeah, PHP code in the database and all that.)
In practice, shared hosting doesn’t tend to take kindly to genuine read-only-ness, and so the grand ideal of not being able to inject persistent code doesn’t work quite so well.
I really don’t like the way Wordpress does it, but the way Drupal does it also isn’t great. I don’t like the security models of any of these PHP things.
Such is the sad state of humans.