"Why we don’t (continuously) update our Drupal websites"
Two weeks ago we decided to run a little survey asking Drupal folks one simple, but provocative question “Why I don’t update my website continuously”. I decided to present you the results - and I can tell that some serious voices got out!
First, I want to speak highly of least 38 of 78 participants, who actually update their website continuously and seem to know exactly what happens if they wouldn’t do it.
So let’s get down to brass tacks - the great majority of the participants decide to set their own update (time) frame. And that’s where it’s getting interesting. Well, I have to say that it relieved me to see that only 3,8% don’t care about updates at all as long everything works as is. Good luck to you!
One out of four thinks that the time spent on monitoring, waiting for and finally applying an update could be used for more productive work. We saw a lot of comments like these:
“It takes too much time to do it properly”
“Security updates always get updates but you must read the release notes as often a security vulnerability has prerequisites that don't affect 99% of websites.“
So it shows that it is truly cumbersome and time-consuming to keep at least one eye per day on (security) update news. And in the end, it’d be frustrating to overlook the most - or even only single one - important update, just because other work cries for you. This issue is an old acquaintance, but I think that this is still pretty alarming after disasters like “Drupalgeddon” back in 2014 or “Panama Papers” this (!) year.
But let’s carry on to the most popular reason why people skip continuous update processes: “New updates can break my website and be incompatible with other modules”.
38,5% of the participants probably had some negative experience with this, and it’s not a surprise. Unfortunately, this is a known dark side of all open source projects maintained by the community, and we all have to rely on the Drupal core and contributed modules maintainers in our workflow.
There is a high chance that you never face this problem in the case of using only popular and well-maintained projects. For the rest - it’s better to triple check the update on dev/stage environment, run integration tests and thus be unconditionally sure the update won’t do any harm. Pro tip: always check the issue queue for the feedback on a new module release - it should give you an idea how stable it is.
Lack of concern
Two comments respond to another important, but not initially provided in a survey option:
“I think updating is a must and it's a pity that clients often don't understand
the importance to have their website updated”
“Client refuse to pay for this because they don't care about security
or new features if it works as is”
I think it is a very underestimated problem for many agencies and freelancers and at the same time one of the biggest dangers to the whole Drupal ecosystem. Clients simply don't get why should they spend money on something which is not visible and without a real value for their business. In most cases, clients become concerned about security and being always up-to-date when the website was hacked, or broken, and the costs of recovering are incredibly high.
That's why we, at Drop Guard, see our mission in promoting the value of taking care of the website on a continuous basis, no matter how - by using our product, doing it manually or via 3rd-party solutions. Other libraries and frameworks are following this path, and we should do so too (stay tuned for our guide dedicated to this topic alone, will be available soon!).
Finally, nearly 21% of participants wait for the community to test the updates first or have other reasons why they wait with updating their websites.
One “continuous updater” delighted me with this rounding off remark:
“but it's a real bugger:) there should be more automated update possibilities with drupal. don't get me wrong, I love drupal since 15 years, but this is definitely one of the annoying subjects.”
- dear participant, Drop Guard contributes with all its capability :-)