teranex weblog - drupal7https://budts.be/2012-05-24T11:32:00+02:00Drupal Development: some tools and utilities2012-05-14T23:03:00+02:002012-05-24T11:32:00+02:00Jeroen Budtstag:budts.be,2012-05-14:/weblog/2012/05/drupal-development-some-tools-and-utilities<p>I finally took the time to make my <a href="https://github.com/teranex/drupaldev">'drupaldev'-repository</a> available.</p>
<p>First a short introduction: It is my strong opinion that Drupal modules which are only used during development, such as <code>devel</code>, <code>diff</code>, etc, should never be deployed to production. They shouldn't even be in the repository. Instead, I keep a personal collection of development-modules in a separate repo. Thanks to the fact that Drupal recursively searches for modules inside the <code>modules</code> folder, I can simply create a symlink to my collection of development modules. This allows me to use my preferred modules, even though they are not in the repository for the project.</p>
<p>For Drupal7, I usually just create a symlink, named <code>devmodules7</code>, in sites/all/modules. Like this:</p>
<div class="highlight"><pre><span></span><span class="c1"># from the drupal root of the project</span>
ln -s ~/drupaldev/devmodules7 sites/all/modules/
</pre></div>
<p>The repository itself contains a collection of modules, for both Drupal 6 and Drupal 7, and some utility-scripts. After experimenting with copies of the modules and git submodules, I finally settled on <code>drush make</code> to manage the …</p><p>I finally took the time to make my <a href="https://github.com/teranex/drupaldev">'drupaldev'-repository</a> available.</p>
<p>First a short introduction: It is my strong opinion that Drupal modules which are only used during development, such as <code>devel</code>, <code>diff</code>, etc, should never be deployed to production. They shouldn't even be in the repository. Instead, I keep a personal collection of development-modules in a separate repo. Thanks to the fact that Drupal recursively searches for modules inside the <code>modules</code> folder, I can simply create a symlink to my collection of development modules. This allows me to use my preferred modules, even though they are not in the repository for the project.</p>
<p>For Drupal7, I usually just create a symlink, named <code>devmodules7</code>, in sites/all/modules. Like this:</p>
<div class="highlight"><pre><span></span><span class="c1"># from the drupal root of the project</span>
ln -s ~/drupaldev/devmodules7 sites/all/modules/
</pre></div>
<p>The repository itself contains a collection of modules, for both Drupal 6 and Drupal 7, and some utility-scripts. After experimenting with copies of the modules and git submodules, I finally settled on <code>drush make</code> to manage the modules. Instead of copying all the modules in my repo, I only keep a make-file for each Drupal version (currently 6 & 7). This makes it really easy to update all the modules, as I can simply run the makefile again. To make this even easier I have added a <code>build</code> script which will run all the drush make-files with the correct arguments:</p>
<div class="highlight"><pre><span></span>./build
</pre></div>
<p>The utility-scripts currently only exist for Drupal7. First there is the <code>install_dev</code> script. This script can install a Drupal from scratch using a provided installation profile and then completely sets up my preferred Drupal development environment. This means that it enables all my preferred development modules, disables some and configures some settings. The script can also be instructed to skip the fresh installation, so it can be run when you are forced to use a database-dump. To make it a little easier to start the script I use an alias in my <code>.bashrc</code> file, which let's me start the script from somewhere in the drupal-tree:</p>
<div class="highlight"><pre><span></span><span class="c1"># in my .bashrc</span>
<span class="nb">alias</span> drupal-install<span class="o">=</span><span class="s2">"\`drush dd\`/sites/all/modules/devmodules7/install_dev"</span>
</pre></div>
<p>Now I can simply run the script inside my Drupal installation:</p>
<div class="highlight"><pre><span></span><span class="c1"># install the default site from scratch with the 'foobar' installation profile</span>
<span class="nb">cd</span> /path/to/drupal
drupal-install foobar
<span class="c1"># setup in the budts.be configuration without installation</span>
<span class="nb">cd</span> sites/budts.be
drupal-install --skip-siteinstall
</pre></div>
<p>Another included script is <code>phpsh-bootstrap.inc</code>. This script can be used to bootstrap your Drupal inside phpsh. <a href="http://www.phpsh.org/">phpsh</a> is an interactive php shell, created by Facebook. That's already really cool, as it is a lot better than the default interactive PHP. But what makes this completely awesome, is that it allows you to provide a bootstrap script to start your preferred framework. With the included script you can start phpsh, bootstrap your Drupal and *boom*, you have an interactive shell which is running <i>inside</i> your live Drupal. You have access to your full Drupal environment and it allows you to do everything a regular page request can do. Similar as to the <code>install_dev</code> script, I also have an alias for this in my <code>.bashrc</code>:</p>
<div class="highlight"><pre><span></span><span class="nb">alias</span> drupal-phpsh<span class="o">=</span><span class="s2">"REMOTE_ADDR='localhost' \</span>
<span class="s2"> phpsh sites/all/modules/devmodules7/phpsh-bootstrap.inc"</span>
</pre></div>
<p>With that alias I can start phpsh by running `<code>drupal-phpsh</code>` from the root of my Drupal project.</p>