3

We have a working Drupal 9 installation (running within Docksal), which has pretty much the whole install living in docroot/ except for the config/ directory, which is a sibling of docroot/. This application is fairly plain-vanilla--no custom modules, just some well-known contrib modules and normal config. I will refer to it herein as the "working app."

In order to get this application onto Acquia Cloud and set up our CI/CD we hope to use their BLT utility.

We have tried several approaches to get BLT working with this application:

  1. Create a Docksal Drupal 9 BLT boilerplate application and attempt to use composer install to get the same set of modules as the working app, and then import the working app's configuration with fin drush cim.
  2. Create a Drupal 9 BLT boilerplate application and hand-edit composer.lock with selections from the working app's composer.lock file, run composer install, and then import the working app's configuration using fin drush cim.
  3. Install BLT within the working app as described here: https://docs.acquia.com/blt/install/adding-to-project/.

Approaches 1 & 2 did not work because of incompatibilities between the BLT boilerplate app's composer configuration requirements (minimum-stability dev and prefer-stable true) and those configurations in the composer.json file of the working app. There were also version incompatibilities between the contrib modules in the working app and those which the BLT boilerplate app wanted to install. Hand editing the composer.json file also proved equally fruitless.

Using approach 3 we got as far as installing BLT in that the blt/ directory and associated files are now present, but blt doctor complains of a missing docroot/docroot directory. Looking at the differences in the filesystem layout between the BLT boilerplate app and the working app made it seem like it might be worth trying to move vendor/, sites/, composer.json and composer.lock up one level from within docroot/ such that those two directories and two files are now siblings of docroot/ and seeing if that satisfies blt doctor. Doing this of course breaks the application and makes composer unhappy. I have tried the following:

  1. Deleting everything in vendor/ and running composer install
  2. Running composer dump-autoload
  3. Hand-editing docroot/autoload.php looking for and attempting to edit incorrect filesystem locations within the relocated vendor/ directory

As you can imagine, none of the above have worked and we are just about at the end of our patience with this endeavor.

I have a few general questions:

  1. Are any of the three approaches above likely to result in a successful BLT install?
  2. With regard to approach 3, is there a generally accepted method of moving either vendor/, composer.* and/or the sites/ directory as described above?

Thank you in advance for any general or specific help you can offer.

1
  • Maybe start with setting up a fresh site with BLT and simply require any additional contrib module with Composer to it, and then try to import the existing config.
    – leymannx
    Feb 21, 2021 at 21:18

2 Answers 2

0

You have two distinct problems here:

  1. "Composerizing" your codebase
  2. Installing BLT

The latter should be pretty painless once you've got the former (theoretically more painful) out of the way.

Fortunately, the Composerize Drupal plugin should get you most if not all of the way there. From the description of your project, you'll want to run this in the root folder (the one containing config/ and docroot/). You don't need to move anything out of the docroot/ folder yourself, anything that needs to be updated will be.

Once that process is complete, run database updates (contrib modules may have been updated to more recent versions), clear cache, verify the site is working, and commit the changes.

At this point you have the structure BLT is expecting, so following the installation instructions again (link in your third approach) should work out a bit better.

0

Composerize Drupal looked like it would be the ideal solution for our problem--it would nuke our composer.* files, put directories where best practices dictated, and re-composerize the application. Sadly, it's just too far out of date (it hasn't been updated in 2 years) and I ran into several problems installing it either globally on my machine or within docksal.

The solution that worked was Approach #1 in my question above (also what leymannx had suggested). That said, it certainly was not as simple as cp -R working-app/config/* blt/config/ followed by fin drush -y cim.

We had to do the following, in this order:

  1. Within the blt drupal run fin drush cex to generate baseline config export files.
  2. Within the working app run fin drush cget system.site uuid and then set that as the site uuid in the blt app fin drush set system.site uuid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
  3. Within the blt app, run composer require for all the contrib modules in the working app.
  4. Hand copy the custom theme from the working app to blt's docroot/themes/custom Hand-merge both apps' config/default/core.extensions.yml files, with specific importance on making sure to override blt's minimal install profile with the working app's standard install profile and to make sure the custom theme from the working app was present in the blt core.extensions.yml.
  5. Once that was done, fin drush -y cim worked (as did fin drush uli just to make sure), and fin blt doctor reported no issues.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.