Installing Initial Sub-Theme with Drupal Bootstrap

The next step is to implement a custom sub-theme. I have a lot of experience with Bootstrap, and there is a great Drupal project that is feature rich and well maintained.

Getting the main theme installed was pretty straight forward, with most of the work updating the Drupal Runner CI script to make it all work.

Create the Drupal Sub-Theme

Enabling the ‘Bootstrap’ theme was as simple as drush pm-enable bootstrap -y and drush vset theme_default bootstrap.

From there it got a bit trickier.

The official documentation has a nice list of instructions, and for me they went something like this:

1. Duplicate the bootstrap/starterkits/sass directory as its own folder in the sites/all/themes directory.
2. Rename the sub-theme directory to ark
   1. Is this too short? It might conflict with this ‘Ark’ project.
3. Rename sass.starterkit to ark.info
4. Edit the information inside ark.info
5. Clone the current Bootstrap repo from GitHub into the sub-theme as bootstrap
   1. Be sure to remove the embedded .git directory in bootstrap. It’s not needed and also huge.
6. Install and enable the jQuery Update module.
7. Compile the sass to css/style.css
   1. Use the command sass sass/style.scss:css/style.css
   2. This actually is a small typo in the official docs. (it currently says ‘styles.css’)
   3. It just has to match the line in ark.info: stylesheets[all][] = css/style.css
8. Add sites/all/themes/ark/.sass-cache to the repo .gitignore file.

Ideally the compiled css won’t be stored in the repo, but build and moved by the CI deployment script. This is enough to get off the ground though.

Updating the CI script

Previously the Drupal Runner script was removing the entire sites directory and linking it to the shared directory. However, I forgot the themes live in there, so I refactored it to symlink the settings.php file instead.

Additionally, the drush command was not found by the gitlab-runner user, which meant the bash PATH was not being exported correctly during first login. Since the login is non-interactive, some of the profile files weren’t loading. I couldn’t get it to load consistently (at all), so I opted to export the ~/.composer directory to the PATH right in the .gitlab-ci.yml file during before_script.

Remote Configuration with Drush commands

Most importantly, I needed a way to configure the remote staging database during the push. This way drush commands are run automatically on git push deployments, and I don’t have to go the remote server to configure everything in the admin by clicking.

Updating WordPress and Drupal remote configurations is awful because of all the damn clicking.
~ Me

There seems to be a few ways to perform this task (which might call for more research later, especially for the Features module), but ultimately I decided to create a /scripts/releases.sh file in the root of the Drupal project. This file is then run during the deploy script

Resources

• Drupal Project Bootstrap
• Official Drupal Bootstrap Docs
• jQuery Update Module
• Deployment Module
• Deploy Drupal with Drush Commands