Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Install Drupal with an installation profile #27
Why "everything in code"?
If everything we do is either part of the original installation profile or is added as a feature, then we are complying with "everything in code".
The "Drupal development, staging and production problem" and the solution as "everything in code" was pointed out years ago by visionary prophets:
This is why we favor Zen over the Adaptive and especially over Omega base themes (see #20 Choose base theme), which store the results of their GUI based configuration in the database together with content.
This is why Backdrop CMS with serializable JSON file based configuration will definitely be a wonderful upgrade path for Drupal 7 site builders seeking to avoid Drupal 8 complexity and the associated learning curve.
Installation profiles in Drupal 7
First cut solution
The standard Drupal install uses database writes to set configuration values.
Drupal Lean Process uses the Install Profile API for Drupal 6. For Drupal 7 we could take advantage of the module dependency to start the install off with the third party modules we want to include, doing the rest with features. So, clone the standard Drupal install, add third party modules and specify them in .info, then add more stuff with features, which should be added to the .info file as dependencies (they will have their own dependencies too).
I'm not keen on the idea of using drush make alone since I actually want the modules and any required patches under version control.
Profiler only downloaded a handful of times. Profiler Builder looks very promising. It's very active and growing in usage. What it does is take a functioning Drupal site and spit out an install profile for that site, which you can download as a tarball.
Let's first try the method outlined here
to create an installation profile
From then on, it's add features, wash, rinse, commit and push
Created dev branch
lit@awebfactory:~/lit-dev$ git status # On branch master nothing to commit (working directory clean) lit@awebfactory:~/lit-dev$ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/gh-pages remotes/origin/master lit@awebfactory:~/lit-dev$ git checkout -b dev-profile-builder Switched to a new branch 'dev-profile-builder'
modules to install:
Library example (views_slideshow)
Enabled all modules
The Date API requires that you set up the site timezone and first day of week settings and the date format settings to function correctly.
Coder Review PHP_CodeSniffer not installed.
added a commit
Dec 19, 2013
For initial install profile generation and testing, first installed module profiler builder:
lit@awebfactory:~/lit-dev/docroot$ drush dl profiler_builder Project profiler_builder (7.x-1.0) downloaded to [success] sites/all/modules/contrib/profiler_builder. lit@awebfactory:~/lit-dev/docroot$ drush en profiler_builder The following extensions will be enabled: profiler_builder Do you really want to continue? (y/n): y profiler_builder was enabled successfully. [ok] profiler_builder defines the following permissions: administer profiler builder
Then to Administration » Configuration » Development » Profiler Builder
lit@awebfactory:~/lit-dev$ cd docroot/ lit@awebfactory:~/lit-dev/docroot$ cd profiles/ lit@awebfactory:~/lit-dev/docroot/profiles$ tar xvf ~/download/lit_dev_opentimebook_com.tar lit_dev_opentimebook_com/lit_dev_opentimebook_com.info lit_dev_opentimebook_com/lit_dev_opentimebook_com.install lit_dev_opentimebook_com/lit_dev_opentimebook_com.profile lit_dev_opentimebook_com/drupal-org.make lit_dev_opentimebook_com/local.make.example lit@awebfactory:~/lit-dev/docroot/profiles$ ls lit_dev_opentimebook_com minimal standard testing
The profile is chosen by default (because the Exclusive option was checked on the profile generation page) at the Url http://lit-dev.opentimebook.com/install.php?profile=lit_dev_opentimebook_com
Drush make is not getting executed evidently. The install profile is generated for http://drupal.org, where the packaging system includes the necessary modules to be downloaded.
Going back to How to Create a Drupal Installation Profile with Profiler and Profiler Builder, the Screencast: Turning your current site into a distribution with Profiler Builder (1/29/2013) explains how to run the drush make file to get the new site, and how to add in the profile to the profiles folders, to obtain the fresh new Drupal instance for your install profile.
Listed on the same resource page: Screencast: Using Drush with this package and what it does (10/25/2012)
On any existing Drupal site:
$ drush dl profiler_builder $ drush en profiler_builder $ drush distro catchy_distro_name Wrote .tar file catchy_distro_name.tar to current directory
This just creates the tar file as before, except in the current directory instead of having to download and upload it to server. However, if we do:
$ drush distro catchy_distro_name --untar Profile catchy_distro_name created successfully!
It didn't create a tar file, it actually added the profile to the profiles directory, and included best practices folders. Full action:
lit@awebfactory:~/lit-dev/docroot$ ls profiles/ minimal standard testing lit@awebfactory:~/lit-dev/docroot$ drush distro lit-drupal-lean --untar Profile lit-drupal-lean created successfully! [ok] lit@awebfactory:~/lit-dev/docroot$ tree profiles/lit-drupal-lean/ profiles/lit-drupal-lean/ ├── drupal-org.make ├── libraries ├── lit-drupal-lean.info ├── lit-drupal-lean.install ├── lit-drupal-lean.profile ├── local.make.example ├── modules │ ├── contrib │ ├── custom │ └── lit-drupal-lean_features └── themes ├── contrib └── custom 8 directories, 5 files lit@awebfactory:~/lit-dev/docroot$
But wait, why not just leave the modules and libraries where they are? This would be a much better fit for development, in order to package a delivery, you can simply generate the install profile and commit (
Would the install work? To find out I would simply:
Let's do it!
So, we get automatic selection at http://lit-dev.opentimebook.com/install.php?profile=lit-drupal-lean but when we hit
According to https://drupal.org/node/1075012 it is because the profile name does not match the directory. I guess it's a bad idea to use dashes :)
Doing it again, we now get a WSOD, from /var/log/apache2/error.log we get:
This is actually covered in issue https://drupal.org/node/2015431 So maybe will work in next stable version.
The offending lines are the first two in
!function_exists('profiler_v2') ? require_once('libraries/profiler/profiler.inc') : FALSE; profiler_v2('myprofile');
Erased those and the installer worked like a charm.
New site up.
Now, Profiler Rebuilder is present, of course, but not enabled.
I re-created the install profile directly with drush, then erased the two lines.
Will merge into master and test
A little script to zap a site so you can go ahead and run an install profile:
$ cat scripts/zapsite.sh # # Prepare Drupal instance for interactive installation # Execute from document root (may need sudo) # Zap the database # http://drush.ws/ shows sql-drop! drush sql-drop # Zap settings.php by copying over a fresh one from default.settings.php cp sites/default/default.settings.php sites/default/settings.php # Zap the contents of the files directory rm -rf sites/default/files/* rm -f sites/default/files/.htaccess chown www-data sites/default/files sites/default/settings.php # Ready to Install Drupal! echo "Go ahead and install Drupal!\n"lit@awebfactory:~/lit-dev$ cd docroot
Go to docroot and run it
$ cd docroot $ ../scripts/zapsite.sh Do you really want to drop all tables in the database lit_dev01? (y/n): y Go ahead and install Drupal!
Procedure to re-create install profile
Comment out offending code in
added a commit
Dec 23, 2013
added a commit
Dec 23, 2013
added a commit
Dec 29, 2013
When the number of features is large, install profile cannot handle dependencies very well, and some stuff doesn't get reverted by the install process no matter what you do.
So it's best to have the install profile install all the basic architecture and perform the initial configuration, including the enabling of a few base features; and then manually enable the desired app level feature set manually after installation is complete, either from the gui or from the drush command line (revert), choosing from among all the options made available via version control.
This makes for two separate phases for the development workflow. The first perfects the install profile and the base features. Once these are thoroughly tested, there is no need to continue re-installing the site from scratch every time you test something new. A simple revert for the features being tested should suffice for user story level testing (not for regression or integration testing).
A special mention should be made of node export default content. Content is imported upon enabling the feature, and then again and again every time you revert it. So it's best to not have any other components than node export features in the default content features, and just have them reverted once by the install process.
Some of the paths to be taken in Drupal Lean Process LTS include using panels with adaptive and zen themes, and perhaps other kinds of page managers were they to become available (i.e. with Backdrop CMS). So this particular instance, Lit Drupal Lean, will be using a zen sub-theme with Context module driven layout management (via block management only, not via context layout module which requires special outmoded themes).