The recent #drupalgeddon incident and comments from a customer made us rethink how we apply Drupal updates for customers (2020Media is a leading UK Drupal hosting provider. We offer a tuned hosting environment for Drupal that is fast and responsive).
For those who missed it on the BBC news and elsewhere, 'drupalgeddon' was a security weakness in the Drupal content management system which allowed attackers to take over websites.
Mark Stockley, an analyst at security firm Sophos, said the warning was "shocking". "Many site owners will never have received the announcement and many that did will have been asleep," he said. "What Drupal badly needs but doesn't have is an automatic updater that rolls out security updates by default." There is strong feeling on both sides with many arguing against "dumbing down" Drupal.
We do not apply updates automatically to any and all Drupal sites we host for a very good reason. The risk of breaking a customer's site is too great. It's worth noting the Drupalgeddon security problem was the first such in 9 years. So it's arguable the risk of such a security problem happening again on such a scale is manageably small. Drupal updates typically replace the entire Drupal codebase, leaving just the /sites/ folder untouched. If a customer or their developer has made any changes to a core file, these changes will be wiped out.
Sometimes a bug will be fixed or a feature changed as a result of an update. The site may well have a work around in place already for the bug and the update will then cause the site to break. These are just a few of the reasons.
The problem for us is, we did not build the site in the first place, nor are we familiar with it's inner workings. So for us to be sure the site is in a working state after an update is very hard to do. A working homepage does not signify the site is 100% working. If the customer is going to be involved, which in our view they have to be, to check the site after the update, they should be involved all the way through - from the point of getting a Drupal notification email of an update, or getting a notification from the Drupal security list through to the timing of the update, to checking the site afterwards in case a roll back is required.
What changes have we made? Actually very little. We have simply streamlined our internal processes to make the technical side of doing the update a lot quicker. A lot of our customers have several sites with us. So we are now using some simply scripting so we can update all a customers sites, once they give us the go ahead.
Inspiration for the scripting came from Dane Powell 's blog: http://danepowell.com/node/69
Our version of the script is:
Update Multiple Drupal Sites Script
for index in 1 2 3
printf "Updating %s\n" "$filepath"
drush archive-dump --overwrite --destination=/pathforbackups/backup.tar
yes | cp .htaccess ../
drush vset --always-set maintenance_mode 1
drush cache-clear all
drush up drupal --yes
drush vset --always-set maintenance_mode 0
drush cache-clear all
yes | cp ../.htaccess ./
chown -R apache:apache ./
Notes on the script.
This script is for discrete Drupal sites, not Drupal multisite.
We copy .htaccess out of the way and put it back afterwards and we noticed Drupal updates sometimes overwrote the original.
The final steps resets the file ownership permissions on the site to whatever your webserver runs as. If using suphp this would need to be changed.
Output is written to the command line so you can see what is going on.
Use at your own risk. Comments and improvements are welcome.
Billed as "Something for Everyone to Love", Drupal 8 is now in Beta testing and we are expecting the release of a final version soon.
The new release clearly owes a lot to WordPress, and this is no bad thing. WordPress is rightly praised for its ease of use, and conversely the opposite always been the first thing people say when they start to use Drupal. So from a user perspective, the new design and associated features such as the mobile admin interface can only benefit the Drupal community.
What has caused some controversy is the move to a completely different coding methodology (Drupal 7’s procedural code versus object-oriented programming (OOP) in Drupal 8). What's the problem? It means developers have some work to do to migrate modules and themes to work in Drupal 8. Drupal is often used for enterprise and/or complex bespoke sites that have undergone a lot of customisation work (always one of the strengths of Drupal) and the coding change will result in a lot of work before an upgrade to the new version is possible.
However it is worth remembering that the previous major version change (from 6 to 7) was also a big jump (and has even resulted in many, many Drupal sites remaining on version 6). A similar effect can be found in Joomla, with Joomla 1.0, 1.5 and 2/3 being majorly different from each other, with no simple upgrade available. Only WordPress seems to have escaped this painful process so far. Perhaps WordPress benefiting from coming to the party later and learning from these other established CMS's growing pains.
Key New Features in Drupal 8
Mobile in its DNA
Deploy content once and watch it display the way you want on any device.
Translate anything in the system with built-in user interfaces.
New Configuration Management
Transport configuration changes and manage versions with ease.
Built-in Web Services
Build mobile apps with Drupal as the data source, or even post back to Drupal from the client.
Use the WYSIWYG editor and in-place editing to quickly create formatted content and make changes on the fly.
Fun and Fast Theming
Build sites quickly with the fast, secure and flexible TWIG template engine.
Views, Out of the Box
Easily customize the front page, listing blocks, and more. Simply create custom admin pages, customize filters, actions, and more.
Drupal 8 includes more field types in core, and lets you attach fields to more types of content like entity reference, link, date, e-mail, telephone, etc.
Better Markup with HTML 5
The page markup in Drupal 8 is now HTML 5-based. Each output template has simplified elements and classes with native input tools for mobile fields like date, email and phone.
Industry Standard Approach
Non-Drupal developers can embrace object oriented programming and proven technologies from the larger PHP community.
CMS Market Share - March 2014
Let's take a look at the latest distribution of market share amongst the most popular website content management systems (all supported by 2020Media, natch!)
- WordPress 60.2%
- Joomla 8.7%
- Drupal 5.4%
A year on year comparison shows why Drupal just might be making radical changes (click to enlarge slide):
Whilst WordPress continues to grow, Joomla more or less holds it position but Drupal is clearly losing share. Is the drop due to the uncertainty over what Drupal 8 would hold, or is it the end-users are switching to easier to use CMS systems and this downswing is temporary and the new look D8 will win them back?
2020Media will be watching developments and will keep you updated.
CiviCRM 4.0.0 has been released for the latest Drupal version - 7 and the new Joomla version - 1.6. Up until now it was necessary to install CiviCRM on the older Drupal 6 and Joomla 1.5.
- CiviCampaign has been integrated with other components such as CiviContribute, CiviMember, CiviEvent, CiviMail and CiviEngage
- Joomla v1.6 introduced an ACL based permissioning system. This gets CiviJoomla to much closer parity with CiviDrupal.
- CiviMember now allows membership upsell. This allows membership type to be changed on renewal
- CiviCRM Extensions. You can now browse and download CiviCRM extensions from within your CiviCRM install.
- A new API - version 3, introduces standardisation of functions, inputs and outputs.
For users of existing Drupal 6 and Joomla 1.5 CiviCRM installs, the simultaneous release of 3.4 for these versions includes the same features.
Comparison of the upgrade methods used in Joomla, WordPress and Drupal
Popular content management systems require updating from time to time. Sometimes this is for new features, often because a security loophole needs patching. In this article we're not going to look at which CMS most often requires updates, but at the upgrade procedure itself. How easy is it, are the instructions clear and easy to follow, what the potential problems, and what can you do if something goes wrong? At the time of writing new major versions of Drupal (7.0) and Joomla (1.6) have been released and no updates have yet been produced for these releases. We therefore concentrate on the older versions, which run the vast majority of existing sites.
Drupal is used on many thousands of websites, but a recent convert to Drupal is The Economist. The Economist is now using Drupal 6 to serve the vast majority of content pages to its primary web site, economist.com. Drupal powers the homepage, along with all articles, channels, comments, and more.
The site is incredibly busy - over 100,000 stories and a Posting rate exceeding a comment per minute. It also boasts 20-30 million page views per month with 3-4 millon unique visitors over the same period.
The Economist has a large varied dataset and moving from the previous system (based on ColdFusion and Oracle) was no easy task. They hired a specialist company called Cyrve who've written and open-sourced a Drupal module to enable migrations of existing complex databases to Drupal. Read more about the migration, or check out Drupal Hosting from 2020Media.