Contents
Lets get this party started .......................................................................................................... 5
Why write an Ebook and What to Expect? .............................................................................. 5
Who is this for?....................................................................................................................... 5
What is a Drupal Ninja? .......................................................................................................... 6
Secret 1: Code Editing What you see is not what you get ....................................................... 7
Komodo Edit Features I could not live without ........................................................................ 7
Syntax Highlighting for any language I would ever need ..................................................... 7
Nice indenting that match the Drupal development best practices ...................................... 9
Code Completion for Drupal ...............................................................................................10
Code Snippets ...................................................................................................................12
Remote File Editing ............................................................................................................13
Other nice features ............................................................................................................16
What are some other Code Editors to look into?....................................................................16
Minimalist ...........................................................................................................................16
Code Editors ......................................................................................................................17
IDEs ..................................................................................................................................17
Any others?........................................................................................................................18
Why You Shouldnt Dismiss this Secret .................................................................................18
Secret 2: Drush Command line Kung Fu ...............................................................................19
Getting Started By Installing Drush ........................................................................................19
Downloading Drupal with Drush.............................................................................................19
Downloading and installing New Drupal Modules ..................................................................23
Disabling a Drupal Module/Theme.........................................................................................33
Listing Drupal Modules and Themes using Drush ..................................................................34
Uninstalling a Drupal Module .................................................................................................37
Running Cron on your Drupal website ...................................................................................39
Clearing your Drupal cache ...................................................................................................41
Backing up your Drupal website ............................................................................................42
Restoring your Drupal website from a backup .......................................................................42
Updating Drupal Core and Contributed Modules/Themes ......................................................44
Countless Other Awesome Features .....................................................................................46
I upgrade all my Drupal modules one by one. I update Drupal core manually as well.
I dont use a development site or a staging/testing site for my Drupal websites.
I do use some type of development site, but if I make a change to a content type, view,
or anything like that, I then manually go to the live site and make that same change. I am
just careful to make sure that I make exactly the same changes on both sites so they
stay consistent.
Dont worry if some of these statements ring true. I am here to help. The only reason I knew to
write those statements above is because at one point or another, they were all true for me. I will
tell you this, since I learned these 5 secrets I have:
Less errors on my Drupal website that ever make it to the live production site.
A better knowledge of what has changed on my Drupal websites over time.
A more streamlined process to developing new functionality and features.
A much simpler process for rolling back changes that did not go as planned.
Much more peace of mind knowing that everything follows a set process on all my
Drupal websites.
Secret 1: Code Editing What you see is not what you get
The first secret is not specific to Drupal and is probably the simplest of all of the secrets. Step 1
to becoming a better Drupal website developer is to find a code editor or IDE (integrated
development environment) that you are comfortable with. If you are already using a code editor
you like and are thinking of just jumping to the next secret dont touch that mouse wheel or
scroll bar! Also, I mention a lot about code development in this section. If you are not a module
developer and are instead more of a site builder or theme designer, dont worry about the
development specific vocabulary used. There is still a lot you can gain from finding the right
code editor.
There is almost always more to any code editor than what meets the eye. These tools are built
with features to try to make your life easier. Are you using these features? I am not saying you
need to use all of the features under the sun, but you should at least be aware of them to know
if they can help you build your Drupal websites faster. I know some of you purposely try to stay
away from code editors and do as much as you can inside the Drupal administration section. As
you progress with your Drupal websites, you will begin to realize that it is often much faster and
more efficient to jump into some code. Whether you are building a new module, making some
small tweaks to your website through a custom module, building a new theme, or just modifying
the style of an existing theme, you will need a good code editor.
My code editor of choice for the last 5 years has been Komodo Edit. It is a great tool that is
simple, but has just enough features to keep a developer satisfied. In the following sections I will
go through some of the key features that help make my life as a Drupal developer much easier.
Depending on your personal development style, you may decide you want something much
simpler, or perhaps even more feature rich like a full blown IDE. The important point here is that
you are deliberate enough to make a decision based on what you want in an editor, not just
because someone recommended it at one point. At the end of this section, I will list out a
handful of other editors so you can have a baseline of what you are looking for. The only way to
really make this decision though is to try a few of them out and decide for yourself.
10
11
Code Snippets
If you are developing Drupal modules or themes, you will likely need to rewrite the same code
many times. I especially have to rewrite the same code when building out module hooks. A
Drupal module hook is a piece of code you can write that will tie into your Drupal website during
a specific time or event that happens. For instance, you can use a module hook to change a
form on your website using hook_form_alter(). Discussing module hooks is beyond the scope
of this Ebook, but they are powerful functions that allow you to easily change how your Drupal
website looks or functions. The important point here is that Komodo Edit has Code Snippets
that easily allows me to save an example module hook snippet of code, so I can quickly add it
into my module when I am developing it. In the example below you can see a list of all my code
snippets on the right, to add it into my code I simply double click on the code snippet. I can also
set hot keys to specific snippets of code that I use all of the time which allows me to save even
more time during development.
12
13
the example below you can see the process of connecting to a remote server. It is simple and
easy to set up and can be useful in a number of situations.
14
15
Minimalist
Vim - This one is for those of you that do not like to use your mouse! It is a command line text
editor that is chalked full of features. This tool is not for everyone though. I use it anytime I am
doing any type of server work, but I wouldnt think of using it for my day to day code editing. If
16
you do give this one a try, dont give up at the first sign of struggle. Without learning the shortcut
keys and the extra features, you might dismiss it before you realize its true power. I do know a
lot of developers that like using Vim for everything, but as I mentioned before, it is not for
everyone.
Code Editors
Komodo Edit - As I mentioned before this is my code editor of choice. I would highly
recommend it to anyone.
NotePad++ - I have used this in the past and I actually kind of liked it. It was extremely simple
to use but did not have all of the features I needed.
TextMate - I have never used this but have heard a lot about it from Mac users. If you are
running on a Mac it might be worth checking out.
IDEs
Komodo IDE - If I ever decide to jump to a full featured IDE, this is probably the one I would
choose. It is similar to Komodo Edit, but has even more features like Git Integration, MySQL
explorer, and much more. This one is not a free solution though.
Eclipse - This one is completely free and is incredibly flexible. The only problem is you will need
to do some research to see what add ons you would like to have and will need. I have used this
in the past with some success but ultimately decided to move away from it. Note: The last time I
17
used Eclipse for any type of PHP, CSS, or HTML, was probably 2008 a lot has probably
changed since then.
Netbeans - I have used this for Java programming in the past, but I cant speak to how it would
work for Drupal.
Any others?
There are a ton of other code editing tools that might be worth looking into if you havent found
the one yet. Here is a good link to a Drupal.org page that goes over a number of tools I havent
covered here - https://drupal.org/node/147789
18
19
Drush Command
drush dl drupal
The next steps are to set up the MySQL Database. As I mentioned before I will not go over
those steps, here. Assuming you have your database ready, you have a couple options for
installing Drupal.
The first is to do it the standard way of going to your Drupal website in the browser. This will
bring you to the Drupal installation page that will look something like this:
20
You could go through all the steps and get your Drupal website set up easily enough, but you
can also use Drush to automate this step.
Note: Before you run the following command, make sure you are in the new drupal folder that
was created when you ran your last drush command.
Drush Command
Note: You can also use the Drush command drush si instead of drush site-install and get the
same results.
ninja less
21
As you can see, the Drupal website has been installed. I can now log in as the admin account
using the password that was displayed after I ran the drush site-install command. After logging
in, my Drupal website looks like this:
22
drush dl [project-name]
drush en [module-name]
The first step is to download the module_filter module using the drush dl command:
23
This command will tell you where the module was downloaded (in this case
sites/all/modules/module_filter) and if there are multiple modules that can be enabled/installed.
Now we install/enable the module using the drush en command.
In case you are curious what the Module filter module does, here is the Drupal modules page
before installing the module:
24
We will now download and install a bunch of extra modules. The following examples show that
you can download and install multiple modules at a time. The examples also show you that
some projects may contain multiple modules that need to be enabled.
We run the drush dl command to download the views, pathauto, and features modules. Notice
how it is able to download multiple projects at once. Also notice that the views project contains 2
modules; views and views_ui.
We can install multiple modules at once as well using the drush en command. Notice how the
views and pathauto modules require additional modules to be downloaded in order to be
installed. Drush is smart enough to automatically download those modules for you.
25
If you look at the modules page now, you will notice that the new modules are there and have
been installed.
26
base theme that can be used when building your own Drupal 7 theme design. Notice that when
we run the drush dl zen command, Drush correctly downloads and places the theme in the
sites/all/themes directory.
Installing a theme is very similar to installing a module, just use the drush en zen command to
install the Zen theme.
You might expect this to change the design of your site immediately, however that isnt the
case. A Drupal theme can be enabled, but not set as the default theme. Here is the Drupal
Appearance page showing that the Zen theme is in fact enabled, but Bartik is still the default
theme.
27
You can also use the drush status command to view status about your Drupal website.
Specifically you can use drush status theme to view theme information about your Drupal
website.
Drush Command
drush status
First we run the drush status command. You will notice there is information about the theme
listed in the command output.
If you want to only see information about the theme, you can run drush status theme
command.
28
We already know that bartik is the default theme from looking at the Drupal Appearance page
on our site. However, we can use drush to change the default theme. Drupal stores a lot of your
websites configuration in a database table called variables. This variables table contains
information such as your Site name, Site slogan, Site email address, default theme, and much
more. Drush allows us to view and change these variables.
Drush Command
drush vget
Here is the output of the drush vget command. You will notice there is quite a bit of variables
already in our Drupal site. This list will continue to grow as we add more modules to our
website. Here is the top of the output, notice there is an admin_theme variable.
29
Here is the bottom output of the drush vget command. You will see a variable named
theme_default, this is the one we need to change in order to change our default theme.
30
If we run the drush vget theme_default command, you will notice we only see the output for
the specified variable, in this case theme_default.
We can now run the drush vset command to set the theme_default variable and switch our
theme to show the Zen theme. Notice that we can run the drush vget theme_default command
again and confirm that the zen theme is now the default.
31
If you go back to the Appearance page on your Drupal website, you will of course see the Zen
theme listed as the default theme.
If you go back to the homepage of your Drupal website, you will notice the design of the website
has changed and is now displaying the zen theme design.
32
If you were launching your website and you no longer needed the views_ui module, you can
disable the module using drush dis views_ui.
A Drupal module can be disabled, but that does not necessarily mean it is uninstalled. A Drupal
module may create additional database tables in your Drupal database or add additional
variables to your Drupal variables database table. If you disable the module, those database
tables and variables will not be deleted. This means you are able to enable the module later
without losing any of your module settings.
33
Here you can see the Modules Uninstall page. You can get to this page on your Drupal website
by clicking on Modules in your admin toolbar, then finding the sub menu tab Uninstall.
The Views UI module has been disabled on our site, but has not been completely uninstalled.
Drush Command
drush pm-list
34
Here is the output of the drush pm-list command. The top of the command
looks like this:
While the bottom of the command output looks like the screenshot below.
Notice the views_ui module is listed with the status of disabled.
35
In the commands list above you can see that there are two options being
shown. The type option and the status option. These can be used to filter the
list. Many drush commands have options, you can view a list of options
available to the drush pm-list command by using running drush pm-list --help.
36
Also keep in mind you can use multiple options together, making it possible to
view only the list of disabled modules using the drush pm-list --type=module -status=disabled command.
37
Drush Command
Here we run the drush pm-uninstall views_ui command to uninstall the Views UI module that
we previously disabled.
We can view the list of uninstalled modules using the drush pm-list --type=module -status=not installed command.
38
We can also confirm that the Views UI module is no longer listed in the Uninstall Modules page
on our Drupal website.
39
Here you can configure cron to run periodically, but there is a catch. The only way cron will run
is if there is someone on your website. If for instance you have cron set to run every three
hours, but there is a 5 hour gap between visitors on your site, your Drupal cron will not run until
that next visitor shows up. This also can make the page load much more slowly for that visitor
as they have to wait for the Drupal cron process to finish. Because of this, it is beneficial to
configure your Drupal website (or more specifically the server the site is on) to run cron using
Drush.
Ninja Lesson: Configure your server to run cron instead of using Drupals built
in Cron.
Drush Command
drush cron
You can manually run the Drupal cron process using Drush by running the drush cron
command.
40
Note: Configuring Drupal cron to run on your server is beyond the scope of this Ebook and the
setup process will vary based on the type of server and hosting you have for your Drupal
website.
drush cc
drush cc all
You can clear the Drupal cache using the drush cc command. After running this command,
Drush will provide you an option to select which cache you want to clear. In this example we
select 1 to clear all of the available Drupal caches.
You can also specify which Drupal cache to clear directly in the drush cc command. In this
example we run drush cc all to clear all of the Drupal caches without the extra prompt to
choose the Drupal cache to clear.
41
drush archive-backup
You can simply run the drush archive-backup command to quickly and easily backup your
entire Drupal website.
42
Now we can use Drush to restore our website to our previous backup (before the article was
created).
Drush Command
drush archive-restore
[backup-path]
The drush archive-restore command provides the easy solution for restoring our Drupal
website to a previous point in time.
Now if we refresh the homepage of our Drupal 7 website, the article we just created no longer
exists.
43
Ninja Lesson: Determine a backup and restore plan for your Drupal website.
Updating Drupal Core and Contributed Modules/Themes
As with any other software, Drupal and the Drupal modules you install on your site will have
updates. Drush provides an easy way for you to update the modules and themes on your Drupal
website. Drush can also update the core Drupal code to a new version.
Drush Command
drush up
The drush up command is a useful command to make sure your Drupal website stays up to
date. If the output of the command contains No code updates available, then you have no
available updates.
44
If you have an update to a contributed module, the output of the drush up command will contain
information about the updates that are available.
After running drush up, if there are updates to Drupal core, the command will warn you about
not running this on production sites prior to testing, and that all changes to Drupal core files will
overwritten by the changes.
45
Ninja Lesson: Because Drupal updates using drush up will overwrite changes to
Drupal core files, it brings us to one of the most important lessons. DO NOT
hack the core Drupal code. Instead build modules to extend Drupals
functionality.
Countless Other Awesome Features
Drush has many more features than could possibly be covered in a short Ebook. You can list all
of the Drush commands by just typing drush in the command line and hitting enter. You will see
a list of commands:
46
This can help you if you forget a command or looking to see if a specific command exists.
Drupal modules can define their own Drush commands meaning that as you install more Drupal
modules, the number of Drush commands available to you may increase.
47
48
There are typically many more features, but that is a basic list that almost all Git hosting
services offer. It is best to do your own research here as opinions tend to vary on which is the
best. The most popular one is probably Github. It provides a great interface and great
collaboration tools. Github is especially popular in the open source software market. Github is
free to use as long as you make your Git repository public. Github charges for you to have a
private repository. Github bases its fees on the number of private repositories you require.
49
Bitbucket is another popular choice. Bitbucket has free Git project hosting for teams of 5 or less.
Bitbucket allow for an unlimited number of public or private Git repositories. All of the fees for
Bitbucket are based on the number of people on the team (not the number of repositories). This
distinct difference between Bitbucket and Github often helps you decide based on the type of
project you are building and the team size (assuming you are basing your decision only on
price). There are many other options out there, but these are the most widely used that I am
aware of.
So which Git project hosting service do I use? Well both actually. I prefer using Github for any
type of open source project. Githubs interface and collaboration tools are slightly better than
Bitbuckets in my opinion. I do however use Bitbucket much more than I use Github. Because I
often tend to work on projects in small teams, and I need private repositories for much of my
work, Bitbucket is the logical choice. I also dont want to discount the tools in Bitbucket as they
too are really good (Github is just slightly more user friendly).
Ninja Lesson: All Git Hosting services will following the same constructs. Learn
Git and you can easily adapt to the hosting service of your choosing.
Git Configuration
The first step is to open up your command line. You may want to create an empty test folder
somewhere on your computer so you can test a few basic Git commands. I will start with a
folder on my desktop called git_test. You will want to make sure your are inside that folder on
your command line.
50
If this is your first time using Git, you will likely need to configure your basic Git settings.
Git Command
You should now have your basic Git configuration set up. You are now ready to create your first
Git repository.
git init
Creating your first Git repository is incredibly simple. Just run the git init command on the
command line from within your project folder.
51
If you have not created the git_test folder yet, you can create the empty directory and the Git
repository in one step.
Either of the above commands will create a new empty Git repository for you to start working
with. It does not get much simpler than that. One simple command to Git you started.
git status
The git status command is a command you will run early and often. It tells you the basics of
what has changed with your Git repository. If you run the command now, you will see that there
is nothing to commit yet. The command does tell you the branch that you are on (which we will
cover later), as well as text telling you this is the Initial commit.
Note: Notice how the last line of the git status command tells you to create/copy files and use
git add to track. Git is full of these helpful hints that tell you what you need to do. This can
especially be helpful when you dont know what to do or it has been awhile. I have spent way
too much time searching the internet for answers, when the answer was often in the command
output of the the Git command I previously ran.
Ninja Lesson: Read the output of Git commands. It will save you time and
headaches.
52
Open up a text or code editor and create a test file. Name your test file test.txt and keep the
text really simple for now.
You will see what my current git_test directory looks like with the new test.txt file created.
53
Now re-run the git status command to see what has changed.
Notice how the test.txt shows up under the Untracked files section. Also notice the line above
the test.txt line that tells you how to add this file to include it in what will be committed.
Note: You may have noticed the .git hidden folder inside the git_test folder. This hidden folder
is created when we created the Git repository with the git init command. It is used to track
everything about our Git repository. If you delete this folder, you are deleting your local Git
repository.
54
Ninja Lesson: Do not delete the .git folder or you will delete your entire local
Git repository.
Adding Files to your Repository
The next step in the process is to add the files to the Git staging area. The Git staging area is a
middle ground between what has changed, and what has been committed to your Git repository.
You can add files to this area and when you are ready, commit these files into one Git commit.
Git Command
git add .
Add all new/modified files inside the current directory to the staging
area of your repository.
We are going to run the git add test.txt command to add the test.txt file to our Git staging area.
We will then run the git status command to see that our file is now ready to be committed.
If we had multiple files to commit, or we did not want to type in the file name, we can use the git
add . command. The . (period) indicates to Git to add all new/modified files in the current
directory or any subdirectories in the current directory (it does this recursively so even files in
multiple levels of subdirectories would get added). We will use this command in future sections
to provide a better idea of how it works.
55
Git Command
git commit
Commits all changes from the Git staging area with the
corresponding commit message.
You can use the git commit command to commit all of your staged changes. You will then need
to fill out a commit message after the text editor is opened. After you save and close the file, the
commit will be finalized.
You can also use the git commit -m command along with an inline commit message to simplify
the process into one command. I prefer using this method as it is simpler than having to use a
separate text editor tool. I also show the git status command after the commit which lets us
know that we have nothing new to commit (our working directory is clean).
Note: The commit message is much more important than it originally seems. The commit
message provides a way for you to describe what has changed in the project. This makes it
easy for you or others to quickly look at a history of commits to see how the project has
changed over time.
git log
56
Use the git log command to see the revision log of your Git repository. This will tell you the
author of the change, the date, and what has changed (using the Git commit message).
57
We will also create a new subfolder inside our git_test folder. Lets call this directory
test_folder.
58
Inside this new test_folder directory, we will create a new file called test2.txt.
59
We can now view the status of our git repository with the git status command.
60
Notice the command output of the git status command lets us know that the test.txt file has
been modified. It also lets us know about an untracked directory called test_folder.
Git Command
git diff
Shows the changes between the last commit and the current
working tree. This will only show changes in files that have been
added to the repository.
Use the git diff command to see the specific changes of any files that have been modified.
Ninja Lesson: The git diff command only shows changes to files that are
already being tracked by your Git repository.
We can use the previously mentioned git add test.txt command and a git add
test_folder/test2.txt command to add the two files to the staging area, or we can use the git
add . command to add both files for us automatically.
61
Ninja Lesson: The git add . command can be a real time saver, just be careful
not to commit files you were not intending to commit.
Undoing Changes
There will inevitably be a time where you will need to undo a change. Git makes this process
relatively easy. The first undo situation we will cover is when you add a file to the Git staging
area that you did not want to add. Luckily for us, Git tells us exactly how to remove this file when
we run a git status command.
Git Command
Removes a single file from the Git staging area but keeps any
changes to that file.
git reset
Removes all files from the Git staging area but keeps all changes
to the files.
Note: The git status command says to use the git reset HEAD command. However, in this
case HEAD is assumed so it is not needed to accomplish the same result.
If we want to remove the test.txt file from the staging area, we simply run the git reset test.txt
command.
62
As you see in the screenshot above, the output of the git status command now shows the new
test2.txt file is still in the Git staging area, however the test.txt file is not. Notice that our changes
to the test.txt file were not lost, we simply removed this file from the Git staging area. You can
confirm your changes are still there by running the git diff command.
If we decide we want to remove all files from the staging area, we can run the git reset
command.
63
Now you will notice that we no longer have any changes staged for a commit. The git status
command still shows us we modified our test.txt file and it now shows us that we have files in
our test_folder directory that are not being tracked by Git.
Ninja Lesson: The git reset command will cause you to lose any uncommitted
changes. Use with caution or you may lose all your work.
What happens if we made a change to the test.txt file by mistake? What if we wanted to get rid
of any of the changes we made to the test.txt file and instead go back to our last commit. This is
also easy to do with Git.
Git Command
Gets rid of your local changes to a file and instead checks out
(or uses) the contents of the file from the last commit.
The git checkout command serves many purposes. It can be used to checkout a specific Git
branch (discussed in the next section), checkout a specific Git commit, or in the case above,
checkout a file (which reverts it back to the last commit).
You can run the git checkout test.txt file to get rid of your local changes to the test.txt file. It
helps me to think of it this way I want to checkout the last committed copy of the test.txt file
and replace (or drop) my local changes to the test.txt file in the process.
In the above command output, you can see that the test.txt file is no longer showing up as
modified. You will also see that the git diff command does not have any output (meaning
nothing has changed).
The last undo situation we are going to cover is how to undo a Git commit. First we need to start
by making a commit that we are going to later undo. We will commit up our new test2.txt file.
64
Now lets look at the git log command to get an idea of what our commit history has been. You
will see both of our commits are listed.
Now we are going to look at what steps we need to follow to safely remove that last commit.
Notice the commit id highlighted with a red box around it. We will need this commit id in order to
safely revert the commit.
Git Command
65
We grab the Git commit id from the log message of our last commit and run the git revert
f54a3f4e00e0ffcbe72c5f3f8be90047a145cb65 command. After running the command a text
editor will open allowing you to add a commit message. You can add additional information or
accept the default commit message. When you are ready save and close the commit message
in the text editor. Below you can see my Nano editor that Git has opened for me.
After saving and closing, the commit has been successfully reverted by Git and the entire
history is now tracked (as seen in the following git log command).
66
67
The first and simplest way is to have a development and a master branch. All your new features
are developed on the development branch, and when you have everything working and ready
on the development branch, you merge the development branch into the master branch. This
way you keep your master branch as the true production level code, while keeping a
development branch to build new features and fix bugs on. This is a useful way to get started,
however it starts to break down when you have a number of developers working on the same
branch at the same time.
In the diagram above, a copy of the master branch is made by creating a development branch.
Development is then completed (each circle representing a Git commit). When the development
is finished, the development branch is merged in with the master branch. In this model, the
Development branch is always kept open.
The second way (and my preferred method) is to use Git branches to develop new features, or
fix bugs. This is actually really simple if you take a second to think about it. Any change that you
want going into the master branch (production/live code) must first originate as its own unique
Git branch. If you need to fix a bug, you create a new branch to fix that bug, and when its ready,
merge it into the master branch. If there is a new feature to be built, you create a new Git
68
branch, develop the new feature, and when its ready merge it into the master branch. If you are
working on just one thing at a time, this may seem like a little overkill. However, imaging you are
working on two or three features at one time. Keeping separate Git branches for each feature
means you can release one of the features without having to have all of the features completed.
In the diagram above, you can see that there are examples of both a Bug fix branch and a New
Feature branch. Development is performed on each branch and as soon as the individual
branch is ready, it is merged into the Master branch. The final circle in the Master branch
contains both the Bug Fix and the New Feature. Using the Git feature branch process, the
branch is closed after it has been merged in with the Master branch. It is important to keep in
mind that in this example you may have a good number of branches open at one time
(depending on team size and what you are developing).
69
to build a new feature. We will just use simple text files, but you should be able to easily see
how it can be used with your code.
Git Command
git branch
To create your first branch called my_new_feature, we just run the git branch
my_new_feature command.
In order to see all of the available Git branches in your repository, you can run the git branch
command.
Notice in the example we have two branches, one called master and one called
my_new_branch. The * character indicates the branch we currently have checked out. Any new
commits we make will be on the currently checked out branch.
70
To checkout your my_new_feature branch run the git checkout my_new_feature command.
If you run the git branch command afterwards, you can see that you now have your new
branch selected.
There is also a shortcut command to create a branch and check it out at the same time. You
can run the git checkout -b another_new_feature command to create a branch called
another_new_feature and immediately check it out.
Switching back to the my_new_feature branch is as simple as re-running the git checkout
my_new_feature command.
71
Git Command
The first step is to checkout your master branch using git checkout master, after that you can
merge in your my_new_feature branch into your master branch by running git merge
my_new_feature.
72
Fixing a Conflict
It is inevitable, eventually something will happen that will cause some type of conflict in your
commit. Dont worry though, it is not as scary as it sounds. A conflict happens when two
different commits change the same file, or more specifically the same section or even line of a
file. Git will attempt to automatically merge the changes and generally does a pretty good job,
however if it cant auto merge the changes, it will ask you to resolve the differences manually.
The first step is to create the scenario of a conflict so we can see how to handle it.
The first step is going to be to make a change on our master branch (this could be from your or
someone else working on another feature branch and merging their changes in with master). In
our example however, we will just make a change directly to master.
73
Next, we will check out our old my_new_feature branch and make a change to that same file
(the same line of the file to be exact).
We will now follow the same process as before to try to merge the changes. This time however,
you will notice that Git tells us there is a problem.
74
There are two ways this conflict can be resolved, the first is manually using a text or code editor.
If we open up the test.txt file in our editor, you will notice a few strange things.
To merge the changes, all you need to do is select the line you want to keep, and remove all of
the other lines. In this case if we wanted to keep the line of text Making another change for
my_new_feature branch., we would remove the <<<<<<< HEAD line, the Making a new
change on master now. line, the ======= line, and the >>>>>>> my_new_feature line. It
would look like this when we were finished.
We would then need to add and commit this change like normal using the git add and git
commit commands.
75
There is a second option for merging a conflict in Git. This option is to use some type of Diff
Viewer tool to help resolve the differences. There are many various tools to choose from,
however in this example I will use Meld.
Note: To follow along with this example you will need some type of diff viewer.
Git Command
git mergetool
The first step in this approach is to run the git mergetool command. This command then asked
me if to hit the return key to open up my Meld Diff Viewer application. Once I hit return, the
application opened showing me the differences in the file.
Inside the Meld Diff Viewer, it shows me three copies of the file. The first column is the Master
branch or what I am trying to merge my change into. The Last column is the change I am trying
to merge in. The middle column (and this could differ based on the settings you use, or the diff
viewer you are using) is the last common ancestor. This is essentially the last time the two
76
branches were the same. In our case this is before each of our last commits to the master
branch and the my_new_feature branch.
To select the change you want, simple click the arrows to move the code over to the center. The
only code that really matters is what ends up in the center. So by click the left pointing arrow in
the right column, you can move the code from the right column to the center column.
Once the code is in the center column, click the Save button and close out of the tool. Here is
what the command looked like from the command line.
77
You will notice that the original git status command showed the test.txt file in the Unmerged
paths section. You will also notice that after running the git mergetool command there is a
new test.txt.orig file sitting around. This file contains the original test.txt before the mergetool
command was run. There are a few ways to deal with this file. The first is to simply delete it,
another is to configure your Git to not create these backup files in the future by running the git
config --global mergetool.keepBackup false command, or you can just ignore this file by
adding it to something called a .gitignore file (which we will discuss briefly later).
In this case, we simply delete the file and are ready to run our git add and git commit
commands as normal.
78
This should give you some results. If you are using a Linux based operating system or a Mac,
you can probably just run the ssh-keygen command (however you should probably do a little
research so you can understand the various options).
After you have an SSH key setup on your local system, you will have a .pub file available to you
in your ~/.ssh/ directory (this might be slightly different on a Windows computer). Open up the
.pub file (in my case it is id_rsa.pub) and copy the contents of the file.
In your Github account, click on the Account Settings link, and go to the SSH Keys section.
Click the Add SSH Key button, give your key a title (probably something related to your current
computer), and paste in the contents from your .pub file into the Key section. Click the Add Key
button to save your key. You computer should now be hooked into your Github account allowing
you to push and pull your Git repositories.
Now that you are setup and ready to go, on your account homepage you should see a section
listing your repositories and a button to create a new one.
You will want to fill in information about your new Git repository and click the Create Repository
button.
79
After creating your repository, Github will take you to a page with information on what to do next.
First click on the SSH button so we can see commands that will use the SSH key we just linked
up. In our case, we already have a repository created, so we will focus on the last section called
Push an existing repository from the command line.
80
We will grab that first line of code and paste it on our command line (inside our Git repository).
Git Command
Paste the git remote add command from Github into your command line and run it. Then do the
same with the git push -u origin master command. Your output should look something like
this.
81
If you refresh your page on Github, you should now see your repository listed.
You can now look through and begin using the Github tools on your Git repository. Anytime you
make a Git commit to your master branch you can simple run the git push origin master to get
the changes to be pushed up to Github. If someone else pushes changes to your Github
repository, you can run a git pull origin master to pull in the changes to your local Git master
branch.
You may have noticed that only the master branch is listed on Github, you can push your other
branches up as well. Simply run the git push origin [branch-name] command to push up a
branch to your Github repository.
82
git remote
git remote -v
83
The git remote and git remote -v commands are useful for listing information about your
current Git remotes.
We could remote the origin remote by running the git remote rm origin command. Keep in
mind, deleting the remote, does not delete the remote Github repository. It simply deletes the
link between our repository and the Github repository. In this case, we will remove the remote
called origin and recreate the same remote but call it github. We also make one small change
to the test.txt file, add it to the staging area, commit the change, and push our change up to
github using our new remote we just created.
Ninja Lesson: Although it is a good practice to use origin as the remote name
if you only have one remote, the name of the remote can be anything that
84
helps you remember where you are pushing your changes to or pulling your
changes from.
Pushing your Repository to Bitbucket
Now that you have seen how Github works, we will also push our repository to Bitbucket. We
could push to either Github or Bitbucket, but Git allows us to seamlessly push to both through
the use of Git remotes.
Make sure you have a Bitbucket account created if you want to follow along. You will need to
link your SSH key in the same way you did with Github. You DO NOT need a separate SSH key
for each service. The process for adding an SSH Key is almost identical to that of Github.
Simply go to the Manage Account section, click the SSH Keys tab, and add a new SSH Key.
Paste in the contents of your public key (the .pub file).
Now that you are setup, you are ready to create your repository on Bitbucket. Back on the
Dashboard page there are two places to easily create a new repository. The first is the Create
link at the top of the page.
Fill in your Git repository information and click the Create Repository button.
85
Once you create the repository, you will see a page that displays information on how to add
your code.
If you click the Im starting from scratch link, you will see information on how to create a new
Git repository and add Bitbucket as a Git remote.
86
In this case, we already have a Git repository created, so you can click the I have an existing
project to push up.
The only difference from the code listed on Bitbucket is that we dont want to create a remote
called origin. We will want to add a new remote and call it bitbucket.
87
Now we need to push up the repository to bitbucket using the git push command. We dont
need to use the -u parameter. The u parameter allows you to push and pull without having to
specify the remote. Since we have two remotes, we will always want to specify this anyway.
If we refresh the page on Bitbucket, you will see your repository and all of its history has been
pushed up.
Now when you commit changes you can choose to push to any of your Git remotes by using the
git push github or the git push bitbucket command. The git pull command works the same
way allowing you to pull changes from either remote.
Git Command
88
Using the git clone command we can easily pull down a remote Git repository. First we need to
find the Git url from Bitbucket (we could also have chosen to clone from Github instead). The Git
url can be copied from the Bitbucket repository page.
Next will change the current directory to the Desktop to make sure we are not in our original Git
repository. Then we clone down the repository from Bitbucket using the Git url we copied from
Bitbucket. We can name the folder anything we want.
89
90
Drupal 7 comes with a .gitignore file for us to use. If you are using Git for a non Drupal project,
you could create this with any text editor. The contents of the .gitignore file exclude the
settings.php file, the Drupal files directory, and the Drupal private files directory. Here are the
contents of the .gitignore file.
These patterns are set up to match files such as sites/default/settings.php as well as files such
as sites/test.com/settings.php. This allows the Drupal multisite functionality to work correctly
without allowing you to accidentally add in user generated files or a settings.php from one of
your Drupal websites.
You are now ready to add all the files to your Git repository and make your first commit.
You are now able to use the Github, Bitbucket, or any other Git hosting service to push your
repository up using the instructions above.
91
of your computer. Git is like a supercharged collaborative backup and recovery system for your
entire project.
92
93
You may choose to take a step further and set up a third staging or test site.
The staging or test site may not be necessary for smaller sites, however it provides a nice
balance if you are working with clients. In this setup, you perform your development on the
development site and push the changes up to your staging site when you are ready for the client
to review. When the client tests and approves the changes, you move the changes from the
staging site to the production site at a predetermined date and time. This way your client will
know when you will be making production changes (and can be prepared for any expected or
unexpected downtime). This clean separation makes the entire development process much
more predictable and easier for the client.
The only negative to the approach of having a development and possibly a staging site is that it
sometimes takes longer for a change to make it to the live site. This small issue can actually be
94
a blessing in disguise. By not hastily pushing out changes, you are more likely to be confident in
the changes you are pushing. This small change in thinking, is probably one of the biggest steps
to becoming a Drupal 7 Ninja and becoming a better Drupal professional.
Ninja Lesson: It is best not to use the drush up command on the live site. This
has the potential to download module, theme, or core Drupal updates that
have not been tested. You can use the drush up command to download these
95
updates to your development environment, test the changes, then push those
changes up to your live site using the Git process outlined above.
Now that we have looked at how a very simple development process works to deploy changes
to a live site, we will look at some other examples. One important aspect of your development
process that cant be overlooked is your hosting provider.
Pantheon
Pantheon is a development platform that allows you to instantly launch, develop, and manage
Drupal websites. I early 2014 I transitioned the Code Karate website to Pantheon and have not
looked back.
What is Pantheon
Pantheon provides a UI for you to easily create a Drupal website and provides a structured
workflow for you to manage that website. You can manage multiple websites from within their
developer dashboard. Each Drupal website gets a development, staging, and a live
environment. Git and Drush are built directly into the platform meaning that from the beginning
all of your sites will will follow the processes I mention in the sections above.
Since Pantheon was originally built just for Drupal websites, it follows Drupal development best
practices and does so on a platform that is easy to scale. Using Pantheon, you do not need to
worry about any of the server details, you simply focus on building your Drupal website.
You can get started with Pantheon for free, however as soon as you want to launch the website
live, you will need to pay for the service. Pantheon offers simple pricing plans which currently
start at $25 per month and go up from there.
Getting started with Pantheon
Lets look through an example to see how this might work. You will need to start by creating a
FREE Pantheon account. Once you have an account and are on your Sites & Account page,
you will be able to manage your sites, your credit cards, and your SSH keys. In the screenshot
below, you will notice that I have the Code Karate site and a development site I use for Daily
Dose of Drupal videos listed on the page.
96
The first step is to add your SSH key. This can be done from the Your Keys section and is
similar to the steps that you had to take with Github and Bitbucket. Click the Add key button.
97
You are now ready to add a new site. Back on the Your Sites & Account page, click the Add a
site link, you will need to give your site a name. This will also create your development URL for
your site.
Clicking the Create Site button will bring you to the Create or Import a Site page. Here you can
select whether or not you are creating a new Drupal site, or importing an old Drupal site.
98
In this case I will select Start from scratch although if you have an existing Drupal website you
can select Import a site and follow along with the step by step instructions. The next step is to
click the Install Drupal 7 button.
99
This will begin the process of creating your new Drupal 7 website.
Once your new site is created, you can click the Visit your Pantheon dashboard button to get
to your dashboard.
100
Your Pantheon Dashboard may feel intimidating at first, however its pretty easy to understand
once you spend a little time learning what all the button do.
The first section we will look at is the available environments. Each of these is a link that will
allow you to manage that version of your Drupal site. You can see that currently we are on the
Dev environment, but can easily manage the Test or Live environment by clicking the
corresponding link. It is important to remember that each environment is a completely separate
Drupal 7 website accessible by a different URL.
101
The left sidebar contains links to allow you to manage your website. These links are specific to
the environment you are currently in.
The top right section of your dashboard has links that allows you to set your environment public
or private, provide you Connection details, and allows you clear the Drupal caches of the site
you are currently on.
Next we will look at the Connection Mode. Currently the Connection Mode is set to SFTP, but
this can easily be changed to Git by clicking the corresponding link. The connection mode is an
important choice you will have to make regarding your personal development process. If you
want to edit the development site directly and do not want to set up a local development site on
your own computer, SFTP is the choice for you. This will allow you to use SFTP clients like
FileZilla (or countless others) to edit the Drupal files directly on the Pantheon development
server for your site. If you prefer to instead do all of your development locally on your computer,
and then want to push those changes up to Pantheon, then Git mode is the choice for you. This
will allow you to commit your changes to Git, push them up, and have them show up in your
Pantheon development environment. In this example we will stick with using SFTP to keep
things simple. Click on the SFTP connection Information will provide you with all of the
connection details you will need for your SFTP client.
102
If the Connection Mode is set to SFTP, you will see a textarea to add commit details. This will
allow you to add a commit message to any changes you make using your SFTP Client. This will
then commit these changes up to your Git repository which can then be migrated to your testing
and live site.
Below this section you will see the Commit Log. This contains information on any commits to
your Git repository.
Now we will take a look at what your development site currently looks like. Click the Visit
Development Site in the top left to open up your Drupal 7 site. You can see that you will need
to finish the installation process. Click the Pantheon installation profile and click Save and
continue.
103
Now complete all the necessary steps and add in the site information at the end of the
installation process.
104
You will now be able to visit your newly installed Drupal 7 site. It looks just like you would expect
a Drupal 7 website to look like.
105
The Test environment must be set up before some additional functionality is opened inside
Pantheon. You can set up this Test environment by clicking the Test link and clicking the Clone
the Development Environment now to create the Testing environment button.
This will begin a process that pulls in all the information from your development site to create a
new testing site.
When the process is complete, your Test environment will look almost identical to your Dev
environment (but remember these are two completely separate Drupal websites).
106
Now that you have your Test environment ready, you could choose to set up your Live
environment, or you can start developing and choose to set up the Live environment later. In
this example, we will make a change to our Dev environment and show how that change can be
pushed up to the Test site.
We will start by adding a few modules to our website. To do this we will want to use Drush. You
will need Drush installed on your local system in order to follow along, so install that now if you
are following along with the process.
Pantheon makes use of Drush aliases that allow you to run remote Drush commands on your
Pantheon websites. This means you can open up the command line or terminal window on your
local computer, and execute a Drush command on your development website. You will need to
download your Drush aliases from Pantheon. You can do this by going back to the Your Sites &
Account page (click the Pantheon Logo in the top left to get there). Click the Download all
Drush aliases link.
107
If you open up the pantheon.aliases.drushrc.php file, it will contain information to access your
Dev and Live environment with Drush.
108
The recommended location for this Drush alias file is the .drush folder inside your home folder.
By moving this file in the .drush folder, you will be able to access the Drush aliases for your Dev
and Live environments.
Now that you have Drush aliases set up, you can run Drush commands on your Dev
environment using the command drush @[alias] [drush-command] where [alias] is the alias
name from your Drush alias file and [drush-command] is the drush command you want to run. In
this case we will use the command drush @5-secrets-drupal-ninja.dev dl module_filter to
download the module_filter module on our Dev environment.
A few quick notes:
You will get a message the first time asking to verify the authenticity of the host.
At the time of this writing, if you are using Drush 6, the drush command may contain an
error with the message Unknown option: --db-url. You can suppress this error by
adding --strict=0 to the command. This means the drush command would be drush
@5-secrets-drupal-ninja.dev dl module_filter --strict=0. View this link for more
information on this warning.
Now if we go back to our Pantheon Dashboard, you will see that it mentions there have been
changes to the Dev site. This module is now available on your development site to enable and
use. If we start typing a commit message, you can see all of the files that have changed.
109
When you click the Commit button, Pantheon automatically makes the Git commit for you. You
can now pull this change up to your Test environment. Click the Test link to get to your Test
environment. Click the Pull Code from Development button to pull in the module_filter module
to your test website.
Once the process is complete, the module_filter module will be available on your Test
environment. Your Commit Log should now show all the commits from your Dev environment.
110
Pulling code to the Live environment is almost identical to pulling code to the Dev environment.
You can also use the Workflow tab in the future to pull your Live or Test databases back to Dev
for better testing (to make sure you are testing with the most up to date data). This was a
notably simple example, however once you get the basics of how Pantheon works, the rest can
be figured out with a little experimenting.
Ninja Lesson: It is a good idea to copy the default.settings.php file and rename
it settings.php inside Pantheon (located in the sites/default folder).
Technically Pantheon can run without a settings.php file, but Drupal and Drush
will complain about the settings.php file not being there. You could also
simply create a blank settings.php file at sites/default/settings.php.
What I love about Pantheon
Pantheon is probably the fastest way to get up and running with a Drupal website. It provides all
the development tools you would ever need to develop and manage a Drupal website. On top of
that, Pantheon structures a Drupal development workflow that follows all of the processes I
have mentioned above (use Drush, use Git, follow a specified development process).
One of the coolest features about Pantheon is the ability to create a site for a client, and have
that client login and enter their payment details. I have never tried it to see how it works,
however it is a great idea that really facilitates running client websites on Pantheon.
The best thing about Pantheon is the peace of mind it provides not having to worry about any of
the server details or having to worry about how to scale out the servers when the time comes.
What I dont like about Pantheon
It is hard not to like pretty much everything about Pantheon, however there are a few things that
are a little limiting. The first is the specific development process. Because it tries to provide a
111
single streamlined process, this can feel a bit limiting at times. With the lower level payment
plans of Pantheon, it is difficult for multiple developers to work on a single project. While there is
a Multidev feature, without paying for one of the more expensive plans you are unable to try it
out. Without this feature you cant make use if Git branches within your Pantheon environment
(although if you used the local development environment you could make it work). These things
are very minor in comparison to all of the features you get with Pantheon.
When to use Pantheon
If you are building a Drupal website, dont want to ever have to think about servers, and want to
follow a best practices development workflow, Pantheon is for you. It is easy to build your
website on once you get the hang of things, and it allows you to scale your website as the traffic
of the site grows. I would highly recommend Pantheon to anyone looking to build a Drupal
website.
Acquia Cloud
The next service we will go over is Acquia Cloud. This is another service that I have a lot of
experience with and one that I think highly of. The service is typically more expensive than the
Pantheon route, but also provides more flexibility and configuration options.
What is Acquia Cloud
Acquia Cloud is similar to Pantheon in that it provides a streamlined development environment
specifically tuned for Drupal development. You will never need to worry about setting up servers
but have some flexibility in setting a few server configuration options.
Each site gets a development, staging, and live environment. You are able to add multiple
databases which allows you to set up multiple Drupal websites in a multisite environment or
interact with an external database from another application. Each environment can be set to use
a specific Git branch, which means you can easily develop features using multiple Git branches
and test them on your development or staging environment.
Pricing with Acquia Cloud can be determined by looking at the Cloud pricing and selecting your
server ram, hard drive space, and Acquia support options. Every Acquia Cloud subscription
comes with access to the Acquia network. This comes with Acquias Insight tool and Acquia
Search. You can sign up for Acquia Cloud Free to give it a test run before actually purchasing.
This allows you to set up your development environment and see how the tools work.
Getting started with Acquia Cloud
You will need to purchase an Acquia Cloud subscription or sign up for Acquia Cloud Free to
follow along. If you are using Acquia Cloud Free, there may be a few differences in the following
screenshots, but they should for the most part be the same.
The first page in Acquia Cloud that is important is your Sites page. Here you will be able to view
all the sites for your account, as well as see the Performance, Security, Code Quality, and SEO
Grader scores.
112
You can add a new site by clicking the the Add site button and giving your site a name. You will
also need to make sure to select the correct Acquia Cloud subscription when adding a site.
When you create a new site you will be brought to the Workflow page and all your environments
will begin to spin up.
113
When it is finished you will be on your Cloud Workflow page and your environments will have
additional information available. This is the page that you will be able to use to migrate changes
between environments and get an overview of what is going on with your website.
114
If you click Getting started you will see a list of getting started tasks. If you click on the task,
you will be guided through the setup process.
115
For instance, if you click the SFTP link, it will launch a tour and you will be guided through the
process. You can end the tour by clicking the End Tour link (which is where the getting started
link previously was located).
Click the drop down by the Git URL link provides additional quick links to Manage your SSH
Keys, Switch to SVN (instead of Git), and get your Drush information.
If you click the Git URL link directly, you will see information for setting up Git.
116
The environments section is where all the magic happens. Here you can drag your code
between environments, drag your database between environments, and even drag your files
between environments.
Click the drop down next to the environment provides you with more quick links and
configuration options.
117
Each environment has slightly different options, however an important option to remember is the
Enable live development link. This will enable you to develop directly on the server using SFTP
instead of having to set up your own local development server.
Below the environments is a task history table that displays all of the tasks that have been
recently run on your Drupal site. When you perform actions inside Acquia cloud or commit
changes to Git, additional tasks will display. You can use this table to monitor their progress.
Clicking the Details link on a task provides additional information about the task.
118
The menu in the left sidebar allows you to easily navigate around your site in Acquia Cloud.
Click the Domains link allows you to configure URLS to access your website. Note: This may
not be available if you are using Acquia Cloud Free.
119
To add a domain, click the Add domain button for the environment you want to add the domain
for, enter your domain name, and click the Add domain button. This will add the domain to the
specified environment. You will need to make sure to set this up with your DNS provider to point
the domain to the correct IP address.
Click the Servers link in the left menu allows you to see information about your currently
running server. You can view CPU, memory, storage, and slow query history of your server.
120
You can filter this report or even perform operations on your server by clicking the drop down
next to reboot in the top right.
Clicking on the Configure link will allow you configure global server settings for all your
environments.
121
Click the Users and keys link in the left menu. This will allow you to manage your SSH keys for
accessing your Drupal site.
Clicking the Add SSH Key button will allow you to add your SSH keys to your Acquia Cloud
site. Although you can add your SSH key here, I think there is a newer and more preferable way
122
to do this that ties the SSH key to your specific user account. We will go through this option in a
future section.
If you click the SSL link in the left menu, you will see a message saying that your site is not
currently setup for SSL.
Enabling SSL is a fairly simple process, simply submit a support ticket and your site will have
SSL turned on in just a short amount of time. If you do have SSL turned on and an SSL
certificate created it will look something like this.
123
You can click the dropdown next to the Upload new certificate link to view more SSL options.
Clicking the Databases link in the left menu will allow you to manage the databases on your
site. This will allow you to set up multiple databases and even configure your website to run in a
Drupal multisite environment.
124
Clicking the Add database link provides you with a simple form to add a new database.
If you add a new database, you will see a message confirming the database has been added.
You can then go to the Workflow page to view the progress. When its complete, you will see
that your new database has been added to all environments.
125
You will now have both databases listed on your Databases page.
126
If you click the Configure settings.php link for any of the databases, you will be provided
information that can be added to your settings.php file of your Drupal websites to connect to
your database. This is an important thing to note as in Acquia Cloud you actually commit your
settings.php file into your Git repository (since it will not actually include any sensitive database
information).
You can also run various operations on your database such as backup, view past backups, or
even view your database credentials.
127
You can download various log files from your server by click the Logs link in the left menu.
Clicking the Statistics link right now will not show you much, however after your site is
launched, you can come to this page to view statistics such as number of requests, number of
uncached requests, and total number of bytes sent for set periods of time. For now you will just
see a message mentioning that there are no usage statistics.
128
Clicking the Backups link provides details on the available database backups. If you just
created your site, you might not see any backups yet. When they do appear you can use this
page to download, restore, or delete the database backups.
Clicking the Drush and API link in the left menu actually brings you to the credentials section of
your user account. Here you can change your Acquia password, add SSH keys specific to your
account, download your Drush alias file, get your private key to use the Acquia Cloud API, or set
up two-step verification.
129
The Cron link in the left menu allows you to configure cron tasks for your site or sites (if using a
Drupal multisite). You can configure cron to runs on each of your three environments.
You can click the Add cron task button to open up a dialog window allowing you to add a new
cron task.
130
The easiest way to add a cron command for a specific Drupal site is to use the Acquia cloud
wrapper script. This runs cron using the drush cron command. Simply enter /usr/local/bin/cronwrapper.sh [site].[env] http://[site_URL] into the Cron command text field. To simplify things,
assuming my site url is http://codekarate.com, and my site name is test142, here is what I would
enter for a few different cron settings.
To run cron on the development environment once every day at 7:00 am create a new cron
entry on the development site with the following values:
Name: Dev Cron
Cron command: /usr/local/bin/cron-wrapper.sh test142.dev http://codekarate.com
Command frequency: Every day at 7:00
To run cron on the staging environment once every hour at 15 minutes past the hour, create a
new cron entry on the stage site with the following values:
Name: Staging Cron
Cron command: /usr/local/bin/cron-wrapper.sh test142.test http://codekarate.com
Command frequency: Every hour at 5 minutes past the hour
To run cron on the live environment every 5 minutes create a new cron entry on the Prod site
with the following values:
Name: Dev Cron
Cron command: /usr/local/bin/cron-wrapper.sh test142.dev http://codekarate.com
Command frequency: click Enter frequency as a string and enter */5 * * * *
131
Note: to determine the [site] value, go to your Users and Keys page and find the value in the
ssh command before the @ sign. This is the name of your site. To determin the [env] value use
dev for the development environment, test for the staging environment, and prod for the live
environment.
Ninja Lesson: When you dont know what to do inside Acquia cloud, look for
the blue help links in the descriptions. These will bring you to help documents
that will often solve the issues you are having trouble with.
To actually get a Drupal site set up and running, go back to the Workflow page, click the
dropdown link next to the Dev environment and click Install Drupal.
This will bring you to the Install Drupal page for you to select which Drupal distribution you want
to install. You can pick one of the included Drupal distributions, or you can paste a URL to a
Drupal distribution in the text field at the bottom of the page.
132
Then make sure you read the warning and check the box at the bottom of the page. Then click
the Finish button.
This will take you to an installation page that will keep you updated on the status of the Drupal
install.
133
When the installation is finished you can select to Set up my set or Manage my code. The first
link brings you to the Drupal installation page where the website will finish the installation
process. The second link brings you to your Workflow page on Acquia Cloud.
Click the Set up my site link and then select your installation profile to start the Drupal
installation process for your development site.
134
Go through the rest of the steps of the standard Drupal installation process until you get your
development website up and running.
Now back in Acquia Cloud (you can click the Manage my Code link to get back there), click the
Domains link. You could now add your custom domains, but in our case, just copy the domain
from the Stage environment. If you go to that website you will notice a default Acquia page.
135
This is because the code and database for Drupa was only installed in the Development
environment. To fix this, go back to the Workflow page and drag the code and database from
Dev to Stage.
When you drag the code from Dev to Stage Acquia will ask you for a commit message. You can
then click the Deploy button. Acquia is creating a Git tag for your master branch and will then
move this tag to the Stage environment. Although we did not cover tags in the Git section, you
can think of a Git tag as just a specific version of a branch (in this case the master branch) at a
specific point in time. By tagging your release automatically, Acquia allows you to easily roll
back to any release that you ever create. This is especially helpful if things do not go as
planned.
136
After deploying the code, drag the database from Dev to Stage and click the Copy button.
Once these changes finished getting pushed to your Stage environment (you can monitor this
using the Task information below where the environment are listed), you are ready to check
your staging site. Go back to your stage site URL and you should now see your Drupal website
on your stage environment.
137
You can follow the same process to copy code and your database to your Prod environment to
create your production site. Once you launch your live site, you will want to make sure to click
the drop down arrow on your Prod environment and switch your environment to Production
Mode. This will ensure that you can not copy Files or Databases from your Dev or Stage
environment over to your Prod environment. This helps prevent the accidental loss of data
We will now walk through a simple example of adding a new module to your site hosted on
Acquia cloud. As mentioned before, you can set up a local development environment or operate
Acquia in live mode, we will go ahead and switch to live mode to make this demonstration
easier. Click the drop down next to the Dev environment on the Workflow page and click the link
to Enable live development.
138
Now click the Enable button to turn on live development mode for your Dev environment.
Once live development has been enabled, you can access the code by either SSHing into the
server, using an SFTP tool, or using a code editor (like Komodo Edit) that allows remote file
opening. In this case we will simply SSH into the server and use Drush to download a module.
We will then commit these changes up using Git, and migrate them to our Stage environment.
The first step is to SSH into the server, so click the Users and Keys link. Grab the ssh
command and paste it into your command line window.
In this command we SSH into the server, change to the ~/dev/livedev directory, and view the
contents of that directory.
139
We will now go into the docroot directory which gets us to the actual Drupal code, and run
drush dl module_filter to download the module_filter module.
We can now view the differences using Git, add the changes and commit them.
The first time you run a Git commit, you will be asked additional information about who you are.
This is to track who made the commit within Git. Run the git config --global user.email
"you@example.com" command followed by git config --global user.name "Your Name"
command to identify yourself to Git and re-run the commit.
140
Now you can push your changes up using git push origin master.
Back on the Workflow page inside Acquia Cloud, you will notice that your commit has now been
pulled in the Task history.
141
Moving this up to Stage is a two step process. The first step is to turn off live development mode
by click the drop down on the Dev environment and selecting Disable Live development.
When you are in live development mode, you are unable to drag code changes directly to the
Stage environment. Also, when you disable live development mode you will lose any changes
that have not been committed and pushed. This is one of many places where having multiple
Git branches (one for each feature request or bug fix) makes this process much easier and
helps from getting in a situation where you have to wait to push your code changes up to Stage.
When you are ready to disable your live development check the box and click the Disable
button.
142
Now you simply drag your code from Dev to Stage, add a commit message, let the process run,
and your module has been pushed up. You can do the same from Stage to Prod as well.
Acquia Cloud Additional Notes and Features
One other feature that I will not go over in a lot of detail but want to mention is the ability to
easily switch between branches in each environment. While you are on your Workflow page,
click the </> icon to the right of the code Git branch. This will bring up a dialog window where
you can check out another Git branch. This really opens up the ability to craft your own
development process around Acquias tools. It might not be necessary for small projects, but if
you have a bigger project with multiple developers, this flexibility really helps.
You will also want to make sure to download, install and configure the Acquia Network
Connector module to ensure your site correctly reports data back to Acquia. This will provide
data for your Acquia Insight score, allow you to connect to Acquia search, and monitor your site
for updates and status information. Going over all of the tools that Acquia provides could be an
entire book on its own, so feel free to really spend some time using Acquias documentation if
you want to learn more about Acquias other services.
What I love about Acquia Cloud
There are so many awesome things about Acquia Cloud I dont know where to start. It is great
to have SSH access to the server without actually having to do any type of server updates or
maintenance. I really like the ability to use multiple databases or run things in a Drupal multisite
environment if needed. The additional tools and support that Acquia provides is very beneficial,
and two-step verification adds an extra layer of security on your Acquia account.
If I had to pick the thing I love the most though, it would have to be the flexibility Acquia Cloud
provides for a developer or development team to craft their own unique development process
based around the needs of the team. Acquia Cloud is tuned specifically for Drupal and provides
a structured and well thought out development process to use, however it provides the flexibility
to change this process as needed. No development team or project is the same, why should
your hosting provider force you to treat each one the same?
143
144
If you were able to follow the last three paragraphs, then you are probably already familiar with
setting up servers and a VPS or cloud hosting service might be perfect for you and your team. If
your head is spinning a little bit or you feel a little lost, then you probably will not want to dive
into building your own VPS (unless of course you are doing it to learn).
VPS providers
There are many VPS providers to choose from, I will list a few here that I have either worked
with in the past or heard good things about.
Amazon EC2 - Easily scale out servers to meet demands. I used this for many years
with a lot of success. Works nicely with all the other Amazon Web Services.
Linode - I used Linode a few years ago and never had any problems.
Rackspace Public Cloud - Although I have never used Rackspace, I know a number of
other Drupal companys that do. It would definitely be worth looking into.
What I love about using a VPS
The biggest benefit of a VPS is the control and flexibility it provides. I was able to define my own
process and set things up as I needed them. If I ever needed an additional PHP extension or
something installed on the server, it was as simple as logging in and installing it. A VPS was
also much cheaper than other Drupal specific platforms.\
What I dont like about using a VPS
If you do not like server administration or are not very skilled in server maintenance, managing a
VPS server can take up a lot more time than you probably initially would realize. A VPS can
easily to from a time waster to downright frustrating if you are not a skilled system administrator.
If you think that you will be able to figure it out as you go and keep it updated, you are in for an
interesting adventure its never as easy as it seems.
I used a VPS for years with quite a bit of success. However at the end of it all I realized that my
skillset was not in managing servers and my time was better spent developing. You will need to
evaluate your priorities, skills, and time commitments and decide for yourself if you want to run a
VPS to host your Drupal websites.
When to use a VPS
You should use a VPS when you want full control over what is happening on your server at all
times. If you want to get the most power for your dollar, a VPS solution will be your best bet.
Just keep in mind the cost savings is a tradeoff for additional time required to maintain the
server and keep it running smoothing. If you have a very detailed or specific development
process or want to run additional tools (like a continuous integration server), a VPS might also
be the best option for you and your team. If you dont want to get tied to a specific service, then
that might be one more reason to use a VPS. Since most VPS providers allow you to start with
a base server operating system, this makes it a little more difficult to get tied down to a specific
service.
145
Aegir
Oh Aegir, you will always hold a special place in my heart. I used Aegir when building my first
Drupal development process on my own. I used Aegir exclusively for over 3 years but now have
completely abandoned using it. The reason for no longer using Aegir is not in any reason the
quality of Aegir, it is simply that my situation and Drupal development needs have changed.
Ninja Lesson: Do not forget to reevaluate your hosting needs from time to
time, and if necessary make a change.
What is Aegir
If you are not sure what Aegir is, it is a hosting platform that allows you to deploy and manage
large networks of Drupal websites. The reason I no longer needed Aegir is because I no longer
am managing large numbers of Drupal websites. If you need to build and host a large number of
Drupal websites, then this hosting platform may fit your needs perfectly. We will now look at
what Aegir is, what it does and does not do, and how this hosting platform can fit into your
Drupal development process.
Aegir is built to take advantage of Drupals multisite capabilities. Each Drupal multisite in Aegir
is called a platform. This platform can have multiple Drupal websites installed on it. This logically
works well if you think of a platform as a collection of Drupal modules, themes, installation
profiles, and even the version of Drupal. Sites can be migrated between platforms. A simplified
process might look like this. You create a new platform for Drupal release 7.28 and create 5
different client websites on the platform. When Drupal 7.29 is released, you create a new
platform for this new version. You then migrate the 5 client websites to this new platform. This
runs all the necessary updates for each client website.
This process gets even more helpful if you use large collections of the same modules on every
site (for instance, views, ctools, panels, etc). You can add these modules to your platform
(either through the sites/all/modules folder, or through a specific installation profile). Now when
you want to make updates to these shared contributed modules you simply build a new platform
with the updated modules included, and migrate the sites over. All of the contributed modules
will be updated automatically during the migration.
What can Aegir do for me?
Aegir can be a great solution if you build and host Drupal websites. This is especially true if you
are building out simpler Drupal websites. The process Aegir provides can certainly work with
larger scale Drupal deployments, however large websites often have complex requirements that
require a little additional work to fit into Aegirs model.
Aegir provides an administrative interface to manage your Drupal websites. This administrative
interface is actually just a Drupal 6 website with a collection of modules and a theme.
Essentially you are using a Drupal website to create and manage other Drupal websites pretty
cool if you think about it.
146
It can be used to create new Drupal platforms, create Drupal websites, migrate sites between
platforms, backup and restore your websites, run cron on all your websites, and overall provide
a high level overview to help track and monitor all of your Drupal websites.
What are my options for setting up Aegir
There are a lot of options for setting up Aegir, but three that I will go over. The first is to
download and install Aegir on a server. There are installation instructions but this is still a very
manual process. You will be required to manage the server on your own.
There is also the BOA option. BOA stands for Barracuda, Octopus, Aegir. This option still
requires that you install it on your own server, however there are easy to run scripts that keeps
the entire system updated for you. There are a lot of additional options included, but also some
additional things for you to learn. Essentially it is a tool that allows you to install and run multiple
Aegir instances and in the meantime keep your server updated. Pretty easy to set up and much
easier to maintain than running your own Aegir server. However, because it is much more
prepackaged, you can also run into some limitations that you wouldnt by running Aegir on your
own.
The final option is to pay for an Aegir hosting service. The best route for this would be to use
Omega8.cc. While I have never used the service myself (I have always used one of the above
two options), I have heard some good things about it. You can get your own running Aegir setup
without having to worry about support or server maintenance. Peace of mind so you can deploy
and run your entire network of Drupal sites without worrying about the server infrastructure.
Getting started with Aegir
Assuming you have Aegir up and running, here are some of the things you can do with it. You
login screen will look something like this.
147
Once you log in, you can view a list of all of your Drupal websites by clicking on the Sites link
located in the top right menu.
148
The main navigation is handled by the menu links located in the top right menu.
The Queues section lists tasks that have run recently and allows you to view more details of a
task.
149
The Administration menu below the Queues section, allows you to perform Aegir administration
tasks such as Manage Clients, Add Client, Add Site and Client, and Add a Platform.
If you just want to add a site though, you can click the Add Site menu tab while on the Sites
page. First you will need to enter a Domain name. In this example we will use
aegir.codekarate.com. You can then select a Client. We will leave this value at the default
client.
150
Next we select the Drupal Profile to use. In this case we want a basic Drupal 7 website so we
select Vanilla Standard (which is for the most part just the standard Drupal 7 installation
profile). Depending on the profile you select, you will have different options for the Platform. A
platform is an Aegir multisite Drupal installation that allows multiple Drupal websites to be run on
it. In this case we select the first option.
151
The last options allow you to select the Language, the Database server to run the site on, how
often you want cron to run on the site, any additional domain aliases for the site, and if you want
the domain aliases to redirect to the main domain. When we have the options we want selected,
click the Save button.
As soon as the Save button is clicked, a new item is added to the task queue. The task is to
install the aegir.codekarate.com Drupal 7 website.
152
To view a more complete list of the tasks, you can click the More tasks link.
153
While we are waiting for the site to install (it will take a minute or two), we can look around the
rest of Aegir. If you click on the Platforms link in the top right menu, you will be able to view all
of the platforms created on your Aegir system. Each of these platforms can have specific types
of Drupal websites installed (depending on the types of Drupal profiles available).
154
In the Administration menu, click the Manage Clients link. This brings you to a page that looks
like the standard Drupal 7 administer users page. A client in Aegir is simply a Drupal 7 user that
has a specific aegir client role.
155
If you click the Add Client link in the Administration menu, you will see the create a client page.
You can use this form to add new clients inside Aegir. When you create a client it adds a Drupal
user for this client. This user can log into the Aegir interface and perform some basic
administration tasks on any Drupal websites assigned to them. If you are using BOA, FTPS and
a limited shell account will be created for this client. This allows the client to add new modules
or themes to their Drupal website, and even SSH into the server to run things like Drush
commands.
156
The Add Site and Client link in the Administration menu, is simply the add site and add client
form all in one, so we will skip that link. You can click on the Add Platform link in the
administration menu to add a new platform to Aegir. Adding a platform is a little trickier as you
have to map the platform path to a location on the server where a Drupal installation is located.
Instead of downloading the Drupal source code and placing it on the server manually, you can
also create and reference a Drush make file that can do this for you. A Drush make file can be
used to build a specific type of Drupal platform. For instance, a Drush make file could be used to
download the newest Drupal 7 release, some contributed modules and themes, installation
profiles and more.
157
By now our new Drupal 7 site aegir.codekarate.com has finished being created. You can
confirm this by looking at the task in the task queue and seeing that it is now green. If the task
turns yellow or red, then something went wrong during the running of the task.
158
You can go back to the sites page and click on the site from there, or you can click on the name
of the site from the task queue. This will bring you to the site page for aegir.codekarate.com.
159
The page contains information about the Drupal site in the left column. The center column
contains tasks that can be run on this Drupal website. You will notice there are a wide variety of
tasks that can be performed on the aegir.codekarate.com site. You will also notice the install
tasks is highlighted in green since it completed successfully.
160
If you click the Log in to aegir.codekarate.com link, this will bring you to your newly created
Drupal 7 website. The first time this will automatically log you in and request that you change
your password.
161
If you go to the homepage of the new Drupal 7 site, you will notice it looks just as you would
expect a freshly installed Drupal 7 website to look.
Back in the Aegir control panel, on the aegir.codekarate.com site page in the left column, you
can click on the platform name Drupal 7.28.1 D.006 to get to the platform page. This looks very
similar to the site page, but has different information and different tasks available. These tasks
allow you to perform the tasks on the entire platform which may contain multiple sites. You will
162
notices that the platform lists aegir.codekarate.com as the only site currently installed on the
platform.
You can create multiple sites on this platform. See below where I created a site called
test2.codekarate.com on this platform as well.
163
If you hop back over to the aegir.codekarate.com page, we can peform a few more site
administration and management tasks. First click the Backups link to view the available
backups for this site. You can use this link to restore the backup, delete the backup, or export
the backup.
Back on the main site page for aegir.codekarate.com, you can click the client name (in this case
Octopus115913, which is simply the default client created for the Aegir platform). This page
contains details about this specific client including the sites installed for this client.
164
Back on the site page for aegir.codekarate.com, we will test the migration functionality. This is
usefuly if you are using a development, staging, and production platform and are ready to
migrate your site to the correct platform. This is also useful if you created a new updated
platform (perhaps with a Drupal core update or module updates). To migrate your site you click
the Run button in the task section for your site. Here you will be able to change the domain
name and select any available platforms to migrate to. Clicking the Migrate button will trigger
the process.
165
The process will create a task to migrate the site to the new platform.
166
When the task finishes, the site will now be located on the new platform. If you updated Drupal
version or modules you have nothing to worry about. Aegir took care of the entire update
process during the migration. You will notice that once the proccess is finished, you now have
another backup created for your site. This is a failsafe so Aegir can restore your site if anything
goes wrong during the migration.
167
You can also click the Run button on the Restore task for the site. This will open a dialog asking
you which backup to restore to. If you select a backup and click Restore, Aegir will queue up
the restore process task.
There are a lot of things you can do with Aegir. It is incredibly powerful, but also requires that
you spend some time learning the way that Aegir works. Because it manages Drupal sites a
little differently it can take some time to understand and can take even more time to develop a
smooth development process around the Aegir system.
What I love about Aegir
Aegir can be a great tool for any Drupal development shop. I really like that it is open source so
you can install it and run it on your own server. I also like how it simplifies the creation of Drupal
websites so you do not need to manually create each site or rely on custom written shell scripts
to build a Drupal site for you. Aegir is quite simply the easiest way I know of to manage large
amounts of Drupal websites on your own server. It also provides a lot of the Drupal specific
tools and features you need to manage large networks of Drupal sites.
What I dont like about Aegir
Aegir introduces additional terminology you probably wont be familiar with when you just get
started. If you really want to use Aegir the right way or at least the recommended way, you
will want to spend time learning Drush make and installation profiles. This makes it easier to
build platforms with specific configurations of modules/themes and facilitates running larger
networks of Drupal sites.
Aegir also makes it tricky to run a development/staging/live process without quite a bit of work.
Because there are so many moving parts version control with an Aegir site is also more
complicated (to do it right you need to learn Drush make and installation profiles as mentioned
above).
168
Migrating sites into and out of Aegir is also a little more complicated. Because it needs the site
to be in a multisite format, it takes a few extra steps to get the site in or out of Aegir. This is
inconvenient if you ever have clients who decide they want to use a different host or want to
host their own Drupal site.
In the end, if you use self hosted Aegir you have to manage the server and updates yourself.
This can be a good and bad thing. Keep in mind you can always use Omega.cc for support or
hosting if you decide to use Aegir, which facilitates or takes care of the server maintenance for
you.
When to use Aegir
If you have a single Drupal site to manage, Aegir is not the best tool for you. If you have a huge
collection of client sites and your clients want to have some level of access to install new
modules or themes, then Aegir (or most likely BOA) might be the perfect solution. If you fall
somewhere in the middle, you will need to weight the cost of learning a new technology and way
of thinking of Drupal development before you jump in. It really is a great piece of software and it
helped me run my Drupal website development company for over three years. Although I have
said farewell to Aegir for the time being because my circumstances have changed, it can still
work wonders for you.
Shared hosting
The last type of hosting provider we will look at is a shared hosting provider. This is the least
desirable of all the hosting providers on the list, but I know there are circumstances where this
option is chosen by many developers. Typically this option is chosen specifically because it is
the cheapest of all the hosting solutions mentioned.
The one thing you should look for in a shared hosting provider is either SSH access or some
type of Git deploy method to allow you to easily manage your code using Git. This way you will
at least be able to build a development process around your hosting provider. If these options
are not available, it will be much more difficult to build a repeatable and streamlined
development workflow.
What is Shared hosting
Shared hosting is a specific type of hosting where your website is shared on the same server as
many other websites, and the resources of that server are shared among the websites on that
server. Shared hosting providers typically offer some type of administrative control panel to
manage your website code and databases.
Shared Hosting Providers
I do not have as much experience with Shared Hosting Providers, but here are some shared
hosting providers to look into:
GreenGeeks
Bluehost
169
Godaddy
Arvixe
InMotion
A2 Motion
Web Hosting Hub
170
make a lot of changes to your site, then maybe, just maybe, this is the option you are looking
for.
171
172
173
staging website for the client to look at and approve. Hmmm You decide to just go to the
staging website and make those quick changes again. The client looks at it and approves the
changes, you now have to go to the live production website and make those changes. It seems
like a hassle, but its not difficult so whats the harm.
What if you had 20 changes to make? What if you missed a change on the live site? What if the
client had additional requests after you made the changes on the staging site and you had to go
back to the development site, and try to keep track of all of the separate changes and separate
requests. What if you have multiple developers making changes, are you going to make each
developer keep track of all their changes and push them up through the three environments?
You can see how much of a mess this causes and how much frustration it can lead to. So much
so that you may start rethinking the entire process of having a development, staging, and
production website.
Dont worry though the Features module, with the help of the Strongarm module makes this
entire process manageable. The Strongarm module can be used along with Features to export
additional configuration information into your created Features module. Drupal 7 contains a
database table called variables in which many different site configuration settings are stored.
The Strongarm module will allow you to store these settings in your created Features module.
This will allow you to push those settings up to your different environments. An example of
some of these settings includes your sitewide email address, your default front page, your site
slogan, your site title, whether comments are enabled on your content type, and much more.
Lets look at the mess of a process we walked through above, and see how it would have
changed using the Features module. You need to add a new field to the Blog content type and
174
make a change to the view. This is not a problem, you simply make the changes as normal.
Since you already have a Blog Features module created, you simple rebuild this Features
module to include your new field on the content type and view. This process is as easy as
clicking a few buttons or running a Drush command. You now have these changes in your Blog
Features module. You commit these changes up to your Git repository, and pull them down on
your staging website. You run a quick process to tell the staging website to use the new code,
and its ready for your client to review. When approved, you simply pull down the code on your
live environment, run a quick process to tell the production site to use the new code, and its
ready for prime time. Imagine you had to make 20 changes on your development site. No
problem, the process is the same and doesnt take any more time to push up to the different
environments.
Now this diagram is a little bit simplified. When you have your entire development process set
up as was discussed in earlier secrets (using Git and a defined development process), the
actual process looks more like this.
175
176
Ninja Lesson: You will notice that the Views module contains a views and a
views_ui module. The views_ui module just enables the interface that allows
you to build and manage a view. A simple performance saving trick is to never
turn this module on for your live site. Its a good test to make sure you are
properly using the Features module as you should never need to manage a
view on the live site directly.
Creating Your First Drupal Features Module
The first step to creating your first Drupal Features module is building out the functionality that
you want to export into a module. This is typically a configuration of Content Types, Fields,
Views, Panels, StrongArm variables, and a number of other possibilities. In this example we will
just build a simple content type and view to demonstrate how it all works. We will start by
logging into our development site and created a content type.
177
Call the new content type Blog. In this case we add a simple description and leave all of the
other fields at their defaults. We then click the Save and Add Fields button.
You will now be able to add or edit the fields of the Blog content type. To keep the example
simple, we will leave the fields at their defaults.
In order to add a new view, go to the views page located at Structure > Views. Click the Add
new view button to get started adding your new view.
178
We create a view with the name of Blog Posts and make sure it shows Content of type Blog.
Everything else can stay at the default values. Click the Continue and Edit button.
You can now look at your View and make any changes if you wish. In our example, we simply
look things over and click the Save button.
179
Now go ahead and add a few example blog posts and go to your /blog-posts page to take a
look.
180
Nothing fancy, but it should be working. You are now ready to dive into the world of Features. In
the admin toolbar click Structure > Features. Here you will see the manage features page.
Since you currently do not have any available Features modules, the page will be mostly blank.
You can view additional Features module settings by clicking the Settings link. Here you can
change Feature module settings. You can disable certain components from being available
when building your Features module. For the most part all of these options can remain at their
default.
181
To get started building your first Features module, click the Create Feature link when on one of
the Features administrative pages. Here you will see the Create a Feature page with all of the
available options you can use when creating your module.
We will start by filling out the General Information section. The Name is the name of your
Features module, when you type the name, a machine name will be automatically created. This
machine name can be changed if necessary by clicking the edit link. The Description field
allows you to add a brief description to your module. The Package field controls where your
module is displayed on the Drupal Modules page. The Version field is an optional field in which
182
you can specify a module version number. This can be used for your own purposes so you can
keep track of changes to your Features module over time.
The Advanced Options section allows you to configure additional settings for your Features
module. The URL of update XML field can be used to tell your module where to check for
updates. In order to get this to work you will need to set up and run your own Drupal Feature
server. This is not a necessary step and is only useful for some very specific uses.
There are two ways to create your Feature module, you can either have the Features module
auto generate the module for you and place it in your modules folder, or you can download the
module as a .tar file and place it on your Drupal site yourself. If you want to auto generate the
module, you can use the Path to generate feature module field to specify the directory to create
the Feature module in. The Preview .info file button is also handy once you get a handle on how
a Feature module is created (we will leave everything at its default in this section).
183
The right side of the Create Feature page allows you to select the components you want
included in your Feature module. Notice all of the available components and feel free to do
some clicking to see what is available in each of the sections.
184
We start by selecting Content Types and click the checkbox next to Blog. This will add the
Blog content type we created and will trigger some additional dependencies to be added to the
Feature module.
185
The next step is to click on the Views section and click the Blog Posts view to add that to your
Feature module.
You can now click the Download Feature button to download your new Feature module. This
module is downloaded as a .tar file and will need to be extracted before being adding to a
Drupal website.
If you look inside the downloaded module, you will see a file structure that is not that much
different than a typical Drupal module.
186
If you unpack this .tar file, you can now drop this Drupal module in your sites/all/modules folder
(sites/[example.com]/modules folder if using a multisite environment). This module can be
enabled just like any other module. However, before we manually drop in this folder, we can
simply click the Generate Feature button within the Create Feature page. This process will
create the simple_blog module and place it in the sites/all/modules folder of the Drupal website
for us.
Now if you go to the Drupal Modules page, you will see the Simple Blog module listed in the
Features section. You could enable this module using this page, just like any other module.
You can also view the Feature module from the Features page.
Here you will notice the module is in a Disabled state. You can click the checkbox here and
click the Save settings button to enable the module. This is the same as enabling the module
from the Drupal Modules page.
187
When the Simple Blog module is enabled, you will notice the state changes to Default. If you
click on the Default link you will see additional information about the Simple Blog Feature
module.
188
On this page you can change settings on the field_tags field you added to your content type. In
this case we will just accept the defaults and click Save settings.
If you go back to your Features administration page, you will notice that the Simple Blog Feature
module still says Default. This is because adding a new field is like adding something
completely new. You need to tell your module about the new field before it can keep track of any
changes to that field.
You can add the new field to the Feature module by clicking the Recreate link on the Features
administration page for the Simple Blog module.
189
This will bring you back to the same page you used to create the Feature module originally. You
will notice that it automatically added the field_tags field inside the Field Bases and Field
Instances sections. We could click the Download Feature button, unpack the .tar file, and
replace the simple_blog module in your sites/all/modules folder. Instead, we will open up the
Advanced section and click the Generate Feature button. This will overwrite your existing
simple_blog module in the sites/all/modules folder with the new version that contains the
field_tags field.
If you go back to the Features administration page and click the Default link for the Simple Blog
module, you will notice that the information page now lists the field_tags field. This means your
changes were correctly written to the module.
Now we will look at how the Features module can identify changes to items that are already
being tracked by changing one of the fields on the content type. On the Content Type
Administration page (go to Structure -> Content Types from the admin menu), click Manage
fields on the Blog content type. Click the edit link on the newly added Tags field.
190
Add some help text on the tags field. In this example I added Enter tags to help categorize
your content. Now click the Save Settings button.
Go back to the Features administration page. You will now see that your Simple Blog feature is
in an Overridden state. This is a good thing. It lets you know that you have made changes to
something that is tracked in your features module.
If you click on the Overridden link, you will be taken to the Simple Blog Features module page.
Here it will show you what has been overridden. In this case its the field instances section.
191
This is great information, however what if you had 20 fields on your content type and did not
remember what you changed. Luckily there is a Drupal module for that. The Diff module can be
used to view the differences between what is in your Drupal Feature module, and the changes
you made on your website. Here we will download and install the Diff module on our Drupal 7
website using Drush.
Now if we refresh our page, you will notice you can click on the Overridden link in the field
instances section.
192
Clicking this link will use the Diff module to show you the differences. The Default column is
what currently exists in the actual code of your simple_blog feature module (the code sitting in
the sites/all/modules/simple_blog folder). The Overrides section is what your current settings on
your Drupal site look like (these are changes that are sitting inside your Drupal database). You
will notice on the left there is no description, but on the right the description we entered is listed.
To get this change added to our simple_blog module, we can go through the Recreate link and
click the Generate feature link. You can also use Drush to make this process even simpler. You
can run the drush features-update [module-name] command or the drush fu [module-name]
command for short.
Drush Command
drush fu [module-name]
In this case we run drush fu simple_blog and enter y when asked if we want to continue (this
will overwrite the existing simple_blog module so make sure you really want to make the
change).
193
Ninja Lesson: The Features module offers a bunch of Drush commands that
make managing your Features modules even easier. You can learn about these
commands at https://drupal.org/node/960926
If you go back to your Features administration page, you will notice that your Simple Blog
module is now back to Default. This process works exactly the same if you made changes to the
view in your Simple Blog module.
194
to change the number of items in the pager to 25. You do this by going to the Views
Administration page, clicking Edit and changing the pager settings to 25 Items per page. Click
the Apply (all displays) button.
The view Pager settings section will now look like this.
195
You then click Add in the Filter Criteria section and add the Content: Published or admin filter
by selecting the checkbox on the left and clicking Apply (all displays). On the next dialog that
shows up also click the Apply (all displays) button to add the filter to the Filter Criteria section
of your Blog Posts view.
196
You can now remove the Content: Published filter from the view (since it is redundant and no
longer needed). You can do this by clicking the Content: Published filter link and clicking the
Remove button. Your Filter Criteria section should look like the image below.
197
Now from the Features administration page, we can recreate the Simple Blog feature and see
the additional options added by the StrongArm module.
Notice that the StrongArm module automatically pulls in a number of variables. These variables
are related to the Blog content type we created and store additional settings information such as
whether or not comments should be enabled by default. You can also see there are a number of
additional variables stored in your Drupal database such as the site name, site email address,
and much more.
198
We will leave the selected StrongArm variables at their default and click the Generate Feature
button in the Advanced Settings section. This will recreate our Feature module so that it
contains the pager change we made in our view and the comment settings change we made on
our content type.
199
After recreating your Simple Blog feature module, you should be able to go to the Features
administration page and see that the Simple Blog is at the Default status. If it still says
overridden, you will need to clear the cache on your Drupal site. You can do this by going to
Configuration in the admin toolbar, then click on Performance. On the Performance page,
click the Clear all caches button.
Ninja Lesson: Its often helpful to use the Version numbers in your Feature
module when you make changes. This will help you track if your staging or live
website is using the correct version of your Feature module or if you have
changes that need to be pulled down.
This is the part of your process where you would commit your changes to Git and pull them
down to your staging site (or live site if you only use two environments). The exact details of this
differ depending on your development process, but just make sure to pull down your updated
code for your Feature module on the next site in the development process. You will also need to
make sure you enable the StrongArm module on your staging site after you pull in all of your
code changes.
Once you have the updated code, you need to tell your staging site to use the code you just
pulled in. This process happens using the Feature revert function. This can be performed in two
ways. The first is from the Drupal Features administration page. When on the Features
administration page, click on the Simple Blog Feature module.
200
You will notice the overridden sections. There are checkboxes to the left of these sections that
can be clicked. After these are checked, the Revert Feature button can be clicked. This will tell
your current site to use the settings that are in your updated Simple Blog Feature module.
You can also use Drush to make this process even faster. You can run the drush featuresrevert [module-name] command or the drush fr [module-name] command for short.
Drush Command
drush fr [module-name]
201
In this case we run drush fr simple_blog and enter y when asked if we want to continue (this
will revert the staging sites database settings for the content type and view you changed to
match the simple_blog module code).
After the Feature revert process has been completed, you will notice that Simple Blog feature
now shows up as Default on the Features administration page. You will also notice that all the
changes you made on your development site are now on your staging site.
This process is repeated for the live site, simply pull down the code from Git, run the Feature
revert function using one of the two methods mentioned above (preferably the Drush method),
and you have your changes on the live site. Using this process it does not matter if you have 2
changes, or 100, the process for migrating the changes across your different environments is
the same. Behold the power of the Features module!
Ninja Lesson: To really streamline your development, you could set up your
development environment to have your test and live websites run the drush
features-revert-all command after code has been updated. This will
automatically revert all your features. Different hosting providers will have
different ways to
What the Features Module is actually doing and how it works
It is important to understand what is happening in the background when you build a Feature
module and begin following the process outlined above. The two important concepts to separate
is what is stored in the Drupal database, and what is stored in the code of your Feature module.
Anytime you create or modify a Drupal content type or view, those changes are saved in the
Drupal database. When you or another user on your site, looks at the content or view you
created, this information is pulled from the Drupal database. This always remains true, even if
you use the Features module.
202
If you are using a Feature module for that content type or view, and you go to the Features
administration page, the Features module compares what is currently in the Drupal database
with what is stored in your Feature module code. If the Feature module code matches what is in
the Drupal database, the Feature module will show up as default. If the Feature module code
does not match what is in the Drupal database, the Feature module will show up as overridden.
This means your Drupal database has changes that are overriding the code in your Feature
module.
When your Feature module is in an overridden state, you have two options. If you have made
changes to the database that you want to keep (perhaps you made a change to a view that you
want to be added to the Feature module code), then you need to perform a Feature update.
This will update the code of your Feature module to match what is in the Drupal database. This
is the process you will typically follow on a development site where you are actually building out
features and functionality.
203
The second option is to do a Feature revert. This will revert any changes that are in the Drupal
database to reflect what is in the code of your Feature module. This process is typically what is
used on a staging or live site. When you pull down the newest changes from Git, you may pull
down changes to your Feature module. This will mean that your Drupal database does not
match the new code changes in your Feature module. In order to get your database to match
the new code changes, you do a Feature revert to revert your Drupal database settings to
match the updated Feature module code.
As you can see, all the Features module really does is get your configuration from your Drupal
database and store that configuration information into a module. This module can then be used
to sync your Drupal database to the correct configuration settings across multiple environments.
It is through this process that you can really take advantage of the power of the Features
module.
204
precision and migrated between Drupal environments. A Drupal Ninja doesnt like clicking the
same buttons twice.
205
Wrap Up
Well if you are still with me this far, then congratulations! You have started down the path to
becoming a Drupal 7 Ninja. You think about Drupal projects in a different way, you are more
efficient, and you have a deeper respect for quality and the Drupal development process. Keep
in mind, you are now just starting to scratch the surface. There are many more things to learn,
and things will always be changing. It is your duty to keep learning and improving.
206