Backdrop Intro: Setting It Up

Blank Backdrop Site

In my last post in this series, I went over my motivations for exploring Backdrop and a few of the differences between it and Drupal 7 (D7). In this post, I'll actually go over setting up Backdrop and pushing code up to a server. 

Pantheon and localhost

Since Pantheon gives you a free developer account and has a quick "Get Started with Backdrop" link, I started by spinning up a Backdrop site on Pantheon. The initial install went very smoothly and was very fast. If you're familiar with D7 installs, then you should recognize a lot of the same screens and prompts. 

Hooray, no issues so far! Pantheon's UI provides a simple Git link you can use to clone the files locally, which I used. Locally, I did nothing special to install Backdrop and went through the same install process as on Pantheon.

I will mention that I initially tried to export the database from Pantheon and into my local setup. This step got me an error about the configurations files, and that's why I decided just to install Backdrop locally as well as in Pantheon. Since it's a brand new site, both routes should get you to the same place, and I'm sure if I cleared a cache or two I could of just imported the database without any trouble. 

Admin Menu

Holy shit, the Admin Menu module is the default menu for Backdrop! Now I can finally clear the cache in one step (and many other useful things) without having to install a darn module for it. I really love this addition to the Backdrop core. It even responds nicely to screen size, well done!

Local Configuration

One great addition to my development practices on D7 sites was to start using a "settings.local.php" file to keep my local configuration out of the Git repo but still not have to change values when I pulled code down.

In Drupal 8, such a file is included in the core and "settings.php" calls it like this...

 * Load local development override configuration, if available.
 * Use settings.local.php to override variables on secondary (staging,
 * development, etc) installations of this site. Typically used to disable
 * caching, JavaScript/CSS compression, re-routing of outgoing emails, and
 * other things that should not happen on development and testing sites.
 * Keep this code block at the end of this file to take full effect.
 if (file_exists(__DIR__ . '/settings.local.php')) {
   include __DIR__ . '/settings.local.php';

I wish this file was included in Backdrop core, but I don't see a sanctioned way to store local configurations at this point. Maybe I will create a pull request for such in the future. 

For now, I just added the change in "settings.php" which looks more like what you had to do in D6...

 * Simple database settings:
 * Most sites can configure their database by entering the connection string
 * below. If using master/slave or multiple connections, see the advanced
 * database settings.
$database = 'mysql://user:pass@localhost/database_name';

Configuration Management Test

Okay, so now that everything is up and running, I wanted to try the new Configuration Management (CM) component of Backdrop. I decided to just make a small change, like cache settings and see what happened. 

As you would do on a live site, I decided to take configuration settings from the server and import them locally to make sure everything lined up configuration wise before doing any working or trying to fix a bug. 

It was as simple as going to "admin/config/development/configuration/full/export", clicking export, going to "admin/config/development/configuration/full/import" on my local setup, choosing the zipped file, clicking import/upload, and then clicking "Stage Import".

At this point, you'll get a message telling you that the file has been uploaded to the staging folder and that you can view the differences before you import the configuration. 

Importing Configuration

As you can see with the "+" and  "-", I am only changing three configuration settings related to caching. That looks good to me so I will click on "Import All". 

Sweet, it says it went successfully, and when I check my local performance settings...they are changed! I know this is a simple example, but the CM UI has worked for me without any problems yet, which is pretty cool. 


Now that everything is setup and configuration is synced between my local and development server, I can begin to create my site. I always like to start with theming and creating a sub-theme so that will be the topic of my next post.