Skip to content
Snippets Groups Projects
Select Git revision
  • master default
  • git-to-https
  • 7.x-1.50
  • 1.47
  • 7.x-1.47
  • 7.x-1.15-rc1
  • 7.x-1.15-rc2
  • 7.x-1.15-rc3
  • 7.x-1.13
  • 7.x-1.14-rc1
  • 7.x-1.14-rc2
  • 7.x-1.14
  • 7.x-1.14-rc3
  • 7.x-1.13-rc3
  • 7.x-1.13-rc2
  • 7.x-1.12-rc3
  • 7.x-1.12
  • 7.x-1.13-rc1
  • 7.x-1.12-rc1
  • 7.x-1.12-rc2
  • 7.x-1.11
  • 7.x-1.11-rc3
22 results
Compare
Name Last commit Last update
..
libraries
modules
themes
CHANGELOG.txt
README.md
build-wcm_base-dev.make
build-wcm_base.make
drupal-org-core.make
wcm_base.info
wcm_base.install
wcm_base.make
wcm_base.profile
README.md

Cloning the WCM Base profile

To get started, clone the WCM Base profile in your local web root:

git clone git@code.osu.edu:ocio_odee_web/wcm_base.git

Building the codebase

After you've downloaded the most recent version of the profile, build the development site from your web root using the dev makefile:

drush make --no-gitinfofile wcm_base/build-wcm_base-dev.make DRUPAL_ROOT

If you are building for proudction, simply use the standard makefile:

drush make --no-gitinfofile wcm_base/build-wcm_base.make DRUPAL_ROOT

Replace DRUPAL_ROOT with the name you would like to give to the directory in which your local drupal site will reside. This will not appear in any repositories, so you may use any name you would like. If you do not specify a location, the distribution will be built in the current directory, which you do not want.

The --no-gitinfofile flag prevents drush from making changes or adding metadata to your .info files

The build might take couple of minutes, as all of Drupal core must be downloaded, as well as contrib and custom modules and themes.

Updating the codebase

In order to retrieve updates made to the WCM Base profile, including modules, themes and Drupal core, you will need to update the profile via git.

Since the WMC Base profile was downloaded again within the Drupal site after first running drush make, you can simply update it there instead of going back to the one in your web root. This must be done from the profiles/wcm_base directory:

git pull --rebase

After the profile has been updated, run the following from your Drupal root:

drush make --no-gitinfofile profiles/wcm_base/build-wcm_base-dev.make .

This will rebuild the site using the parameters defined in the make file. Note that this command must be executed from the Drupal root. While you can generally build from any location and then add a parameter specifying the location where you'd like the files to go, drush will only let you rebuild an existing site from the site root. In this case, we are using the . character to target the current directory. This command can be executed without setting a target, but drush will then force you to confirm that you would like to build in the current directory. This confirmation can be skipped by appending the -y flag, but unless you want to be asked to confirm the build every time, simply targeting the current directory will circumvent this.

If you are updating a production codebase, you can use the drush remake plugin, which will rebuild the codebase from any location within your Drupal site with a simplified command:

drush remake

To install this plugin, simple run the following command:

drush dl drush_remake

This plugin is not recommended for the development environment, as it appears to download everything into profiles instead of sites/all.

IMPORTANT: Changes to any files within the Drupal root will be overwritten, so make sure you've committed and pushed changes to custom modules and themes to their corresponding UCR repositories before rebuilding. Existing modules and other files in your local environment will not be deleted however, so if you are testing modules that you have not added to the make file, they will still be there after you rebuild. If you have any local branches, they will be lost, so either push your branch to UCR, merge your changes into an existing branch and push, or simply make a copy of your repository and then move it back into the site after you rebuild. If you're not confident overwriting everything, you can always start a new build in a completely different directory than the one where your existing site lives, but this will require lots of copying and pasting and is very tedious.

The rebuild would normally take a while, as once again, everything needs to be re-downloaded. Fortunately, this is not necessary if you just want to refresh modules and themes. If Drupal core has not been updated in the make file, this is just a waste of time, so in most cases, you can just add the --no-core flag:

drush make --no-core --no-gitinfofile profiles/wcm_base/build-wcm_base-dev.make .

This is significantly faster and usually all that is necessary to get your whole site up to date.

Installing the profile

If you are installing the WCM Distribution for the first time, then you need to create a new database, configure settings.php, and run the Drupal installer. This can be accomplished by passing your database credentials, the name of the new database you'd like to create, and the name of the site to drush site-install, or more simply, drush si.

drush si wcm_base --db-url='mysql://[db_user]:[db_pass]@localhost/[db_name]' --site-name=Example -y

If you don't like the idea of your credentials being visible and appearing in your shell history, this can also be done by creating a new database manually and running the command without any extra parameters. This will require you to create and configure a settings.php file, either manually or through the installation web interface.

drush si wcm_base -y

Once the settings file has been created and configured for the first time, the shorter command above can also be used at any time to reinstall WCM Base, which will wipe out the site's database and recreate it from scratch.

Building the distribution

When updating the distribution repository, rebuild the codebase (but not with working copies):

drush make wcm_base/build-wcm_base.make DRUPAL_ROOT

Loose ends and bonus tips

This might seem complicated, but it's really not so bad. It's unlikely that you will need to rebuild on a daily basis, as most changes that matter to you as a developer can be retrieved from the git repos. A full rebuild is only necessary when Drupal core is updated, which is not very often. If you're worried about whether changes to your repos will be easily communicated to other team members, remember that any time someone else wants to push to a repo you're working on, they will probably have to pull first, meaning your changes will get to them soon enough. As long as all your changes have been committed, rebuilding should never cause any problems, and will be necessary when contrib modules are updated or when modules and themes are added to the distribution.

Here are some additional tips to help you along:

  • Typing out all these commands can be tedious, so it's highly recommended to use shell aliases to minimize the inconvenience. This is a common and straightforward practice and is not difficult to do. There are plenty of resources on the subject, but DigitalOcean has a pretty good one.

  • You may also have noticed that the recommended method for updating the WCM is to use the --rebase flag when executing a git pull. This is generally a good practice whenever you pull because it prevents unnecessary merge commits from being added to the git log. You can also configure your local git configuration to always rebase on pull with git config --bool pull.rebase true

  • You may also may not know the the shell you use from the command line can help you out with keeping track of what's going on with git. Oh My Zsh is an excellent replacement for the default Bash shell, and includes lots of options and customizations, such as showing you what branch you're on without having to type anything at all, as well as customizing the look and feel of your prompt, and additional enhancements for command line usage and navigation.

Why a make file instead of a mega git repository?

Development of this distribution could be done by this method above, whereby building a make file downloads core and contrib and pulls down entire working git repos for modules and themes, or by using a repo of the pre-built site, with the smaller repos nested inside of it. There are pros and cons to each approach.

Build speed

Rebuilding from the make file is slower than a git pull because every file is downloaded whole instead of just a diff of each changed file. However, the benefit is minimal since Drupal does not need to be updated frequently, and most of the work will be done on custom themes and modules, which will have their own repos, regardless of the method used to build the site. It's true that it is easier to do a quick pull to see if any changes have been made, as opposed to having to rebuild,

Ease of common development

With nested repos, changes to modules and themes, which are frequent during early development need to be committed to individual repos and to the larger distribution repo. The introduces the potential human error involving adding and committing the right files to the right repo and adds frequent, unnecessary repetition. With the make file approach, developers need only focus on their version-controlled projects, which are updated automatically upon rebuilding, but can also be pulled manually. New modules and themes can simply be created or downloaded locally and then added to the make file for later distribution. Once they have been added to the make file, committing them to a parent repository becomes unnecessary, as contrib and core modules are never modified.

Hands-off updates

Contrib modules, and even Drupal core itself must be updated manually, and then committed to a parent repo. With a make file, the newest version is pulled by default when rebuilding making regular maintenance easier. Specific versions can optionally be added, as well. As a bonus, this will prevent developers from hacking core and contrib due to the fact that any changes they make will be overwritten on the next rebuild.