Skip to content

Instantly share code, notes, and snippets.

@markf3lton
Last active May 3, 2024 20:09
Show Gist options
  • Save markf3lton/7271452b3737097bf2babb6674be60e6 to your computer and use it in GitHub Desktop.
Save markf3lton/7271452b3737097bf2babb6674be60e6 to your computer and use it in GitHub Desktop.
Create a "vanilla" codebase for Site Factory

Create a "vanilla" Drupal codebase for Site Factory

These steps may be followed to create a "vanilla" code branch for your project. This is useful when starting a new Site Factory project — or perhaps you just want to test some platform functionality on a clean Drupal branch running the latest version of Drupal.

Initialize the codebase

Navigate to your Projects directory. Use Acquia CLI to fetch Drupal and create a new project. (You can can then add this to an existing code repository, as a separate branch, to keep things tidy.)

cd ~/Projects
acli new

When prompted, you will select option [0] for the acquia/drupal-recommended-project.

As a quick aside: The acquia/drupal-recommended-project is simply Drupal core installed via composer. This is an Acquia-maintained fork of drupal/drupal-recommended-project that relocates the docroot per Acquia standards, adds drush to your project, and includes a handful of Acquia-recommended settings. If you want to see what differences may exist between this fork, and an "unmodified" Drupal install, read through this guide. In short, this gets you Drupal with most of Acquia's requirements and recommendations preconfigured out-of-the-box.

Rename the codebase, set up DDEV

We will call this project "vanilla."

mv acquia_drupal_recommended vanilla
cd vanilla

Then add DDEV.

ddev config
ddev start

Cloud IDE would be preferred and recommended for most customers. I am using DDEV in this tutorial instead of Cloud IDE because it is lightweight and sufficient for the task at hand. Specifically, I am using OrbStack as described in the DDEV install docs.) Feel free to use whatever tools you prefer! If you are using DDEV, just make sure it is loading (e.g. https://vanilla.ddev.site:80/core/install.php) before you continue.

Set up Git, push the "vanilla" branch

git remote add acquia vanilla-example@svn-2398.enterprise-g1.hosting.acquia.com:vanilla-example.git
git add .
git commit -m "Initial commit of acquia/drupal-recommended-project."
git checkout -b vanilla 
git push --set-upstream acquia vanilla

Add the required Site Factory module

ddev ssh
composer require drupal/acsf
drush pm:enable acsf
git add .
git commit -m "Add Site Factory Connector module."
git push

Link the project to your target Cloud application

acli auth:login
acli app:link

(Follow prompts as necessary.)

git add .
git add .acquia-cli.yml
git commit -m "Adds .acquia-cli.yml to include the uuid of the target application."
git push

Run acsf-init

Run acsf-init. You can do this using DDEV or the development environment of your choice.

drush acsf-init-verify --root=/var/www/html/docroot/modules/contrib/acsf/acsf_init --include=/var/www/html/docroot/modules/contrib/acsf/acsf_init

If you do not know, acsf-init will make a handful of (necessary) changes to your codebase. Taken together, these small modifications enable Site Factory to deliver your Drupal applicatioin as a dynamic multisite (i.e. no code changes needed to launch additional sites).

You must execute acsf-init whenever you update Drupal core.

drush acsf-init --root=/var/www/html/docroot/modules/contrib/acsf/acsf_init --include=/var/www/html/docroot/modules/contrib/acsf/acsf_init

Commit the latest changes to the repo.

git add .
git commit -m "Add acsf module and run acsf-init"
git push

Deploy a build artifact to Site Factory

The composer install command installs (or updates) the vendor directory within your project's root. The best practice is to .gitignore the vendor directory in source code, but we need to include it in the production tag.

There is an easy way to create a production-ready tag using Acquia CLI. While most customers will utilize a dedicated CI tool such as Code Studio (preferred) or Pipelines to automate these build steps, Acquia CLI does have a command that will take care of it in a pinch.

acli push:artifact

The output of this command should appear as follows:


 ! [NOTE] Acquia CLI will:                                                                                              
 !                                                                                                                      
 !        - git clone vanilla from example-vanilla@svn-2398.enterprise-g1.hosting.acquia.com:example-vanilla.git  
 !                                                                                                                      
 !        - Compile the contents of /Projects/vanilla into an artifact in a temporary directory
 !                                                                                                                      
 !        - Copy the artifact files into the checked out copy of vanilla                                         
 !                                                                                                                      
 !        - Commit changes and push the drupal-9-clone branch to the following git remote(s):                           
 !                                                                                                                      
 !          example-vanilla@svn-2398.enterprise-g1.hosting.acquia.com:example-vanilla.git                                                     

    ✔ Preparing artifact directory
    ✔ Generating build artifact
    ✔ Sanitizing build artifact
    ✔ Committing changes (commit hash: 368ce5bb4e9a119f33af54da9be38a8e97e02a34)
    ✔ Pushing changes to vanilla branch.

Note, this command will overwrite the deployed development branch by default, so be sure this is what you want to do! In this illustrative example, "vanilla" is just a branch for testing, so no big deal! Read more about it here.

Summary

With a plain vanilla version of Drupal deployed to your 01dev or 01live environment, you can test a variety of Site Factory functions.

I prefer to use the "Standard" Drupal profile when creating new Site Factory-hosted websites because the "Standard" profile is ubiquitous, and because it will always work. Then, use configuration management strategies to manage application- or site-specific requirements and modules as necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment