24 Mar 2021
I’ve created a short tutorial on upgrading a website from Drupal 7 to Backdrop CMS as part of my work with Freeform Solutions. I encourage you to reach out if you have any questions.
Perhaps you got here because your Drupal 7 website is getting crusty and you are searching for alternatives. I’m going to show how to upgrade a website from Drupal 7 to Backdrop CMS.
Why should you trust us? I’m Herb van den Dool, a senior developer and project manager at Freeform Solutions. I’ve already got a few Drupal 7 (and Drupal 6) upgrades to Backdrop CMS knotched up. Some of those have been complicated websites integrated with [CiviCRM}(https://civicrm.org/) and custom modules. At Freeform Solutions we many years of collective experience keeping valuable non-profit websites secure and well-maintained. We take you and your website needs seriously. Feel free to get a hold of us if you want our help.
You may have heard about Backdrop CMS which is a fork of Drupal 7. Perhaps “fork” is too simplistic a term. Upgrading from Drupal 7 to Backdrop is actually often easier than upgrading to Drupal 8. Backdrop is a good choice for non-profits and small businesses who have essential websites but don’t always need to be on the cutting edge that is Drupal 8. Backdrop CMS has made a number of improvements to make the hard things that most people use easier. Backdrop also includes the most popular and useful modules in core, which almost everyone uses, such as Views, Pathauto and Token. Backdrop CMS is guided by the philosophy of making it easy for the 80% of users rather than cater to the advanced developer (a conscious change from Drupal 7). If you’re unfamiliar with Backdrop you can take it for spin with this demo. For this upgrade I reviewed the upgrade documentation again. I recommend you do so to make sure you’ve got everything ready for your upgrade. I also suggest making backups of your database, code and files so you can retry things if you get stuck.
22 Jun 2020
What’s right for you? Drupal 8 or Backdrop CMS? This is a question I’ve been trying to answer for a lot of clients. And it’s a hard to answer since it really depends on the website, the organization, budget, and what stakeholders want to accomplish. And then there are the clients who are more comfortable with WordPress and want that, even without knowing whether it would even be a good fit for their website.
I hope to dive into my experiences and thinking a bit in the hope that it helps people navigate their own decisions. And provide some Drupal 7 to Backdrop CMS upgrades demos. There are already many Drupal 8 demos so I’ll leave that to others.
I’m fairly agnostic about the platforms. Each of them have strengths and weaknesses; there are things I love about both. I’ve been happy to work on Drupal 8 projects for some of our larger clients. But I’ve been contributing to Backdrop CMS quite a bit so that’ll be a good part of my focus.
More to come!
04 Nov 2014
I’ve been working on a number of Drupal 6 to Drupal 7 upgrades. When it comes down to it, many of them take just as much work as an entirely new site. But I’ve been putting a lot of work into getting the firm I’m working for to adopt more efficient and resiliant deployment processes.
Migrating content
Using the migrate and migrate_d2d modules to script the mapping of fields from a Drupal 6 site to a fresh Drupal 7 site. This has been invaluable in the upgrade process even though there still ends up being lots of work with menus, dealing with translated content, blocks and views.
I’ve had the chance to start using Pantheon for one of our clients and it’s pretty awesome. It makes deployment and development much easier. You get three environments in the basic package: dev, testing and live. And Pantheon provides an easy UI for managing the deployment process between each stage. For example, when pulling in code changes to testing Pantheon easily allows you to pull in the live database to see how the new code would work on the live site without exposing any issues to the public.
We’ve also started using Beanstalk to help with deployment on projects where we can’t put them on something like Pantheon. This is the only way we’ve been able to use version control across all projects. There has been some resistance to this at work.
Using Features and Configuration Management
A key part of improving deployment is putting all configuration changes into code instead of storing it all in the database, which is a big failing of Drupal. For this we’ve been using features and have started using configuration management. Features is widely used so I don’t feel the need to talk about it. The latter is a Drupal 7 module that borrows heavily from the new Drupal 8 Configuration Management Initiative, which is much better at helping with the deployment process than Features. The Drupal 7 module works fairly well but it suffers from a resource-intensive UI and from being a contributed module which can result in poor support from more obscure modules. Still it has drush commands which help quite a bit.
All of these together have really helped improve my development.
05 May 2014
Yes, that’s a rainbow shooting out of my head
There’s a good reason this site is barebones. I’m busy and I can’t always conjure up rainbows and unicorns. But I like it that way too. I aim to keep this very basic since other projects always take up most of my time.
Lately, I’ve been interested in simplifying the process of meeting the needs of our clients. Instead of offering a full-package solution that includes Drupal and CiviCRM, we should be thinking of providing the minimum amount of functionality that meets their needs. I’ve been quite interested in reading how Development Seed, which was a firm heavily involved in Drupal until a couple years ago, ditched Drupal altogether and dived into Github pages and Jekyll. They even started their own user-friendly markdown editor prose.io that connects with your github account (I’m using it right now). This was a major missing piece in moving to a “CMS-free” setup.
For my own work I don’t need anything complex. Flat HTML is fine. I can edit my own images locally. That is partly why I’m now trying out Github pages for my own personal information. I’ve been using markdown for awhile on my other blog, which is run on Drupal.
My previous personal site was little more than a brochure site with a portfolio. The code was getting horribly out of date; security updates piled up. I just don’t need that all. I could have moved it to Drupal Gardens or Wordpress.com but the chance to play with Github pages is too inviting.
Drupal can be quite powerful and we still end up using it for most projects, but clients seldom need everything that it has to offer and it is hard to resist the urge to turn on many features just because it’s possible. When completing user stories we should be open to exploring new ways of completing the functionality with something that doesn’t require a complete technology stack.