5 ms·

I work at a company specializing in Drupal services. In fact, it was one of my coworkers who discovered the Drupalgeddon2 exploit. My opinion is that people and

I work at a company specializing in Drupal services. In fact, it was one of my coworkers who discovered the Drupalgeddon2 exploit. My opinion is that people and companies should be careful with using any CMS. All of our customers have a genuine need for using Drupal, but the truth is that for most companies, there is no need for an outward facing CMS. If there is no user interactivity, I strongly recommend to anyone to build their site to static HTML and serve that if at all possible. 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.

ar-jan 8y ago
A middle road is also possible. I use a self-hosted opensource hosting system (https://github.com/omega8cc/boa https://github.com/omega8cc/boa) which automatically patched all my sites upon release of the advisory. This may not work for all vulnerabilities, but it was very convenient for the last two Drupal vulnerabilities.
a012 8y ago
> I strongly recommend to anyone to build their site to static HTML and serve that if at all possible. Is there any products that support CMS as backend and automatically generate HTML as frontend OOTB?
- cromulen 8y ago
  forestry.io works with Jekyll/Hugo.
  - prophesi 8y ago
    +1 to Forestry. Lets me build lightning fast static sites for people that they can easily edit. I recently deployed a site that uses https://lunrjs.com/ https://lunrjs.com/ to also allow for quick browser-side site searching. An honorable mention goes to Netlify CMS. I just wish they had documentation on how to host the service yourself.
    - hunvreus 8y ago
      You can get started pretty quickly with Jekyll+ [1] and self host it at no cost [2] using now [3]. 1: https://github.com/Wiredcraft/jekyllplus#quick-start https://github.com/Wiredcraft/jekyllplus#quick-start 2: https://github.com/Wiredcraft/jekyllplus#installation--development https://github.com/Wiredcraft/jekyllplus#installation--devel... 3: https://zeit.co/now https://zeit.co/now
- dberhane 8y ago
  I recommend gatsbyjs (react.js based static generator) and it has plugin for Drupal and Wordpress. Here is the location of the Drupal plugin: https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-source-drupal https://github.com/gatsbyjs/gatsby/tree/master/packages/gats... And the headless Drupal GatbyJS demo: https://using-drupal.gatsbyjs.org/ https://using-drupal.gatsbyjs.org/
  - giancarlostoro 8y ago
    So what tool would be used to extract the static information from the site conveniently? Or does it still need a running instance of Drupal to function? Cause that would still leave you vulnerable to Drupal exploits basically.
    - dberhane 8y ago
      There are various things you could do with the headless Drupal: you could put it behind a Firewall or enable access control where only your front-end Gatsby.js app can have access to.
  - mattferderer 8y ago
    I really like Gatsby & static site generators, especially when hosted on something like Netlify. 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.
    - octalmage 8y ago
      I noticed this too. I wrote a WordPress plugin to trigger a TravisCI build when I publish a post and this works great, but it takes 5 minutes or so to publish a new version of the site. For me this isn’t a huge deal, although waiting 5 minutes to fix a grammar issue sucks, but for some this is going to be a bigger deal when they’re used to being able to make changes instantly. 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.
- dec0dedab0de 8y ago
  depending on how complex your url structure is you could have wget download everything from your local cms, then rsync it to your webserver. I have been considering doing this with a side project I am working on.
- numbsafari 8y ago
  Movable Type?
- rufugee 8y ago
  For our corporate site, we use Drupal internally, and then use httrack and bash to package it up statically and deploy to our public web server. This works very well, and allows our marketing department to easily maintain it while keeping our server reasonably safe.
- hunvreus 8y ago
  I use Jekyll along with Jekyll+ [1] for the CMS. Put it behind CloudFlare and you have a very professional solution. 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 [2]. 1: https://github.com/Wiredcraft/jekyllplus https://github.com/Wiredcraft/jekyllplus 2: https://wiredcraft.com/blog/the-new-starbucks-cn-website-bold-mobile-first-and-hyper-personalized/ https://wiredcraft.com/blog/the-new-starbucks-cn-website-bol...
ebbv 8y ago
The main reasons to use a CMS have nothing to do with user interactivity. It’s about content sharing and reuse between pages. Interlinking of Pages. Site wide configurability. 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.
- Xylakant 8y ago
  Many of those things can be done without an (internet-facing) CMS. You could for example use an internal CMS that generates static HTML which is then pushed to a simple webserver with no option to execute code. This is certainly not a panacea, but it will prevent 0-day automated attacks from random botnets.
- darklegend 8y ago
  You can have the benefits of a CMS with static sites too. Just have a internal CMS and export it as static pages whenever you have changes. This is fast and secure but breaks interactivity with the CMS
mtberatwork 8y ago
> I think it's worth it for companies to completely outsource maintenance to specialized companies. 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.
dreamfactored 8y ago
This is terrible advice and frankly it's a bit shocking to see so little insight into contemporary CMS architecture and why it exists on a tech site. Yes UGC is a very important driver, but many organisations have an internal community of non-technical publishers and marketers whose needs are served by a CMS. 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.

ar-jan 8y ago

A middle road is also possible. I use a self-hosted opensource hosting system (https://github.com/omega8cc/boa https://github.com/omega8cc/boa) which automatically patched all my sites upon release of the advisory. This may not work for all vulnerabilities, but it was very convenient for the last two Drupal vulnerabilities.

a012 8y ago

> I strongly recommend to anyone to build their site to static HTML and serve that if at all possible. Is there any products that support CMS as backend and automatically generate HTML as frontend OOTB?

cromulen 8y ago
forestry.io works with Jekyll/Hugo.
- prophesi 8y ago
  +1 to Forestry. Lets me build lightning fast static sites for people that they can easily edit. I recently deployed a site that uses https://lunrjs.com/ https://lunrjs.com/ to also allow for quick browser-side site searching. An honorable mention goes to Netlify CMS. I just wish they had documentation on how to host the service yourself.
  - hunvreus 8y ago
    You can get started pretty quickly with Jekyll+ [1] and self host it at no cost [2] using now [3]. 1: https://github.com/Wiredcraft/jekyllplus#quick-start https://github.com/Wiredcraft/jekyllplus#quick-start 2: https://github.com/Wiredcraft/jekyllplus#installation--development https://github.com/Wiredcraft/jekyllplus#installation--devel... 3: https://zeit.co/now https://zeit.co/now
dberhane 8y ago
I recommend gatsbyjs (react.js based static generator) and it has plugin for Drupal and Wordpress. Here is the location of the Drupal plugin: https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-source-drupal https://github.com/gatsbyjs/gatsby/tree/master/packages/gats... And the headless Drupal GatbyJS demo: https://using-drupal.gatsbyjs.org/ https://using-drupal.gatsbyjs.org/
- giancarlostoro 8y ago
  So what tool would be used to extract the static information from the site conveniently? Or does it still need a running instance of Drupal to function? Cause that would still leave you vulnerable to Drupal exploits basically.
  - dberhane 8y ago
    There are various things you could do with the headless Drupal: you could put it behind a Firewall or enable access control where only your front-end Gatsby.js app can have access to.
- mattferderer 8y ago
  I really like Gatsby & static site generators, especially when hosted on something like Netlify. 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.
  - octalmage 8y ago
    I noticed this too. I wrote a WordPress plugin to trigger a TravisCI build when I publish a post and this works great, but it takes 5 minutes or so to publish a new version of the site. For me this isn’t a huge deal, although waiting 5 minutes to fix a grammar issue sucks, but for some this is going to be a bigger deal when they’re used to being able to make changes instantly. 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.
dec0dedab0de 8y ago
depending on how complex your url structure is you could have wget download everything from your local cms, then rsync it to your webserver. I have been considering doing this with a side project I am working on.
numbsafari 8y ago
Movable Type?
rufugee 8y ago
For our corporate site, we use Drupal internally, and then use httrack and bash to package it up statically and deploy to our public web server. This works very well, and allows our marketing department to easily maintain it while keeping our server reasonably safe.
hunvreus 8y ago
I use Jekyll along with Jekyll+ [1] for the CMS. Put it behind CloudFlare and you have a very professional solution. 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 [2]. 1: https://github.com/Wiredcraft/jekyllplus https://github.com/Wiredcraft/jekyllplus 2: https://wiredcraft.com/blog/the-new-starbucks-cn-website-bold-mobile-first-and-hyper-personalized/ https://wiredcraft.com/blog/the-new-starbucks-cn-website-bol...

ebbv 8y ago

The main reasons to use a CMS have nothing to do with user interactivity. It’s about content sharing and reuse between pages. Interlinking of Pages. Site wide configurability. 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.

Xylakant 8y ago
Many of those things can be done without an (internet-facing) CMS. You could for example use an internal CMS that generates static HTML which is then pushed to a simple webserver with no option to execute code. This is certainly not a panacea, but it will prevent 0-day automated attacks from random botnets.
darklegend 8y ago
You can have the benefits of a CMS with static sites too. Just have a internal CMS and export it as static pages whenever you have changes. This is fast and secure but breaks interactivity with the CMS

mtberatwork 8y ago

> I think it's worth it for companies to completely outsource maintenance to specialized companies. 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.

dreamfactored 8y ago

This is terrible advice and frankly it's a bit shocking to see so little insight into contemporary CMS architecture and why it exists on a tech site. Yes UGC is a very important driver, but many organisations have an internal community of non-technical publishers and marketers whose needs are served by a CMS. 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.