Backdrop CMS

Building a Backdrop site on pantheon can be done many ways. Below is my preferred method. It includes the following Pantheon options:

I was able to get this working today. It only took two changes.

Git clones of the contributed projects I have ever worked on live on my computer (MacOS) at ~/_backdrop/_contributions. When I am working on one of these modules from an active development site, I remove the module from that site's codebase, and replace it with a symlink to the git clone of contrib:

rm -r metatag
ln -s ~/_backdrop/_contributions/metatag

Then I do all the work for metatag on the site where I had the problem or want the feature, until I'm done. At this point I have a patch/PR (or new release) for the module. So I restore the previous module to the site, apply the patch (or update to the lates version), and commit the change.

There are several ways to handle ALT text for images in Backdrop.

Alternative text in image fields on Nodes

In Drupal 7 core the text was stored in the same field as the reference to the image. This is how Backdrop CMS handles ALT text on images out of the box.

Alternative text in text fields on Files

If you would prefer to handle ALT text the way it is handled by Drupal 7's file_entity module, where the text was stored in a field on the File entity, that is also relatively simple to achieve.

All that is needed is a preprocess implementation in your theme.

The following will make this change only for a field named field_image

In Backdrop CMS most contributed projects that depend on libraries include those libraries as part of the project. We call this "Bundling libraries".

People who use Backdrop can be confident that any module they enable or update using the Installer module (also known as Project browser) will work. Each module includes what it needs, or depends on another module that includes what it needs, and Backdrop manages all the dependencies.

Bundling libraries avoids these classic Drupal User eXperience problems:

There are lots of different approaches to managing Backdrop CMS configuration files in Git, but this one is my favorite. It works great for projects with multiple developers, and it can also be easily adapted for multiple deployment environments, as on Pantheon.

This versioned staging directory strategy has been adapted from a recommendation from @populist and @davidstrauss based on how the config directory is being managed for Drupal 8/9/10 on Pantheon.

One of the benefits of hosting a website on Pantheon, is that the dashboard can notify you when there are available updates for the core code of your CMS (Backdrop CMS, Drupal, or WordPress).

Pantheon does this by comparing the code you are running on your own website, to the latest available code in the matching Pantheon "upstream". For Backdrop CMS websites, the Pantheon "upstream" is the backdrop-pantheon repository on GitHub.

When your Pantheon dashboard shows that there are updates available for your site, it has noticed that your code is no longer identical to the code located there.

If you've been working with Backdrop for a while, you'll notice that sometimes, a particular module, theme, layout template (or sometimes even Backdrop core) doesn't quite work right - or - perhaps it just doesn't quite work the way you'd like it to for your particular project.

Fortunately, this is the world of open-source, and you are most likely not the first person to have this concern. Your first line of attack should always be to search the issue queue for the project and see if someone else has already fixed this problem for you (or added the new feature). Quite often, you'll find that they have, and there will be a Pull Request (PR) linked from the issue containing the necessary changes to the code.

Once an issue has a PR on GitHub, it's easy to create a patch for your own site by adding .patch to the end of the URL.

Today I need to make some updates to one of my Backdrop CMS websites that hasn't been worked on for in a while. This site is hosted on Pantheon. Since I haven't written about how I update my local site before, I thought I'd take the time to document it today. I hope someone finds this helpful :)

Note, the instructions here assume the site is using my configuration management workflow for Pantheon hosted websites.

Get recent copies of everything

I always start by grabbing a fresh copy of the 1) code, 2) database, 3) files and 4) configuration files.

To pull down any recent changes to the code (1), I use the Terminal to navigate to where I keep the code for this site on my local computer, and type 'git pull'.

I use MAMP for my local Backdrop development on MacOS.

If you would like to do the same, first download the most recent version of MAMP and install it locally. When you are done, you should have directories for both MAMP and MAMP PRO in your /Applications directory.

To run the application, double click MAMP.app inside the MAMP directory. Once it's up and running, you should see a MAMP widget with a cute elephant icon.

Let's start by adjusting the preferences. I like to run MAMP on the standard ports for Apache and MySQL. MAMP provides it's own ports, and by default uses these instead.

When moving from traditional web hosting to managed platform-specific hosting providers like Pantheon, there are often a few tricks you'll need to work around. In this post I'll be documenting the steps necessary to move an existing website onto Pantheon.

Step 1: Create a new website on Pantheon

As someone who manages dozens of websites, I love Pantheon's upstreams. Whenever there is a security update for Drupal core or for Backdrop core, the provided one-click core update saves me a lot of time. Whenever I start a new Pantheon project or moving an existing site onto Pantheon, I want to start from an upstream.

I'll start by creating my site from Backdrop's Pantheon upstream.

I also like to run the installer to get a working Backdrop site (you'll see why later). I will replace various parts in the steps that follow.