The 5 Secrets To Becoming A Drupal 7 Ninja Shane Thomas 2014 Diypromo PDF

The 5 Secrets to Becoming a Drupal 7 Ninja
by Shane Thomas - Codekarate.com
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

Secret 3: Version Control (with Git)... Never lose your code or your mind again........................49
Choosing the Right Service to Host Your Git Repository .......................................................49
Getting Started with Git .........................................................................................................50
Git Configuration ...................................................................................................................50
Creating Your First Git Repository .........................................................................................51
Viewing Your Project Status ..................................................................................................52
Adding Files to your Repository .............................................................................................55
Committing Your Changes.....................................................................................................55
Viewing Your Commit History ................................................................................................56
Viewing What Has Changed ..................................................................................................57
Undoing Changes ..................................................................................................................62
An Introduction to Git Branches .............................................................................................67
Creating a Git Branch ............................................................................................................69
Checking out your Git Branch ................................................................................................70
Making changes on your new branch ....................................................................................71
Merging a Git Branch.............................................................................................................72
Fixing a Conflict .....................................................................................................................73
Pushing your Repository to Github ........................................................................................78
Learning about Git remotes ...................................................................................................83
Pushing your Repository to Bitbucket ....................................................................................85
Cloning an Existing Git Repository ........................................................................................88
The .gitignore file ...................................................................................................................90
Bringing It All Together With Drupal ...................................................................................91
Secret 4: Development Process and Hosting Dont you dare touch production......................93
Why you should define your development process ................................................................93
What does a typical development process look like ...............................................................93
Define your release process ..................................................................................................95
Choosing how to host your Drupal website ............................................................................96
Pantheon ...........................................................................................................................96
Acquia Cloud ...................................................................................................................112
Custom VPS Solutions .....................................................................................................144

Aegir ................................................................................................................................146
Shared hosting .................................................................................................................169
Which one is right for me? ...............................................................................................171
Why You Shouldnt Dismiss this Secret ...............................................................................171
Secret 5: Features Module Get your site configuration in order ...........................................173
What is a Drupal Features Module ......................................................................................173
How Features fits into your development process ...............................................................173
Getting Started with Features ..............................................................................................176
Creating Your First Drupal Features Module........................................................................177
Making Changes to your Drupal Feature Module .................................................................188
Using Features to Migrate Changes between Drupal Websites ...........................................194
What the Features Module is actually doing and how it works .............................................202
Why You Shouldnt Dismiss this Secret ...............................................................................204
Wrap Up..................................................................................................................................206
The 5 Secrets to Becoming a Drupal 7 Ninja .......................................................................206
In Closing ............................................................................................................................206
Lets get this party started

Hey there, I am Shane Thomas. You have probably read some of my blog posts or watched
some of my Daily Dose of Drupal videos over on codekarate.com. Despite if you have or have
not heard of me, I will tell you a little about myself. I was first introduced to Drupal in 2009. I
immediately felt the pain of the Drupal Learning Curve. Although I could see the power in a
Drupal website, I also noticed how difficult it was to get started. Over the years I have worked on
hundreds of Drupal websites of all sizes, and I eventually realized that there needed to be a
place where I could document the things I learned through trial and error so that others (like
yourself) would not have to struggle as much as I did. I launched Code Karate in March of 2011
to try to do my part to help other Drupal developers, site builders, and designers who were
getting started with Drupal and feeling the pain of the Drupal learning curve.
Why write an Ebook and What to Expect?

The reason for writing an Ebook is simple. I want to get this information out, but I dont think a
blog post will do it justice. I also dont think it will be taken as seriously if it just sits in a single
blog post on the Code Karate website.
You can expect a good dose of reading along with a lot of hands on examples. If you are
already familiar with a specific secret, I still recommend browsing through it (you dont have to
necessarily follow along with the examples). This way you might be able to pick up on a few
tricks you were not aware of. You will also find I try to keep the writing style light and personal. I
might throw in some humorous analogies or references. My goal was not to write a textbook or
a strict reference guide. Dont take it too seriously and try to have fun with it I know I had fun
while writing it.
Who is this for?

This Ebook is for beginning to intermediate Drupal developers, site builders, and themers who
want to learn more about the best practices for building Drupal websites and learn tips to
become more efficient with Drupal. These 5 secrets are not revolutionary by any means, but
they are evolutionary if you are not using them. By evolutionary I mean that if you are not
using these secrets then start, it will take your Drupal website development process to the next
level. Any one of these secrets in itself is helpful, but using all 5 will not only improve your
development process, it will change how you think about a Drupal website.
If any of these statements sound familiar, then reading this Ebook will be able to help you.
If I need to make a change to one of my Drupal websites, I just change the live site. I am
just really careful not to make any mistakes or I just try to make the change quickly so
the website visitors dont notice any problems.
When I make a change to my Drupal website it is pretty much permanent. If I messed
something up and find it a few days later, I dont really have a way to roll the site back.
I download all my Drupal modules manually or through the admin interface on the Drupal
website.
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.
What is a Drupal Ninja?

In this Ebook I will occasionally come back to the terminology of a Drupal Ninja. So what
exactly is a Drupal Ninja? A Drupal Ninja is a Drupal developer that goes out of their way in the
beginning of a project to craft their development processes and their Drupal skills in order to
complete their project with speed, efficiency, and minimal errors. This often means spending
extra time upfront in order to save time, or improve quality during the project. One more quick
tip, you can only ever become a Drupal Ninja, if you dont yet think you are a Drupal Ninja. It is
the through the process of continuous learning that you will continue to improve. Others may
call you an expert, a guru or even sometimes a genius, however with Drupal (like any
software) change is always happening, and you must continually learn and adapt. I am just
getting started in my journey are you ready to join me?
Enough of the introduction, lets learn the 5 secrets to get you started in your quest.
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.
Komodo Edit Features I could not live without

For the most part Komodo Edit is a fairly lean and mean editor. But there are a number of nice
to have more complex features that make my life as a Drupal developer much easier.
Syntax Highlighting for any language I would ever need

Komodo Edit has syntax highlighting for PHP, HTML, JavaScript, CSS, and anything else a
Drupal developer would ever need. This makes it easy to read your code and to see if you have
any syntax errors. Here are some examples of Komodo Edit syntax highlighting using code from
the Views module, starting with a PHP example.
Komodo is also a great editor for CSS.
I also use Komodo Edit for Javascript and Jquery development.
Nice indenting that match the Drupal development best practices

Drupal development best practices say that you should use two spaces for your indenting.
Komodo Edit lets me easily set that up for all different languages so I can still use the tab key to
quickly indent or two spaces and it all works out the same. This is useful if you have a number
of developers working on a project and are trying to follow the same indenting procedure.
Code Completion for Drupal

Sometimes I know a function exists but I dont remember exactly what the function parameters
are or what the function does. With Komodo Edit, I can drop in a copy of Drupal 7, and it will be
available to popup in my code completion tool (often called autocomplete). In the examples
below I am typing in the Drupal functions called drupal_goto and watchdog. You can see that
it gives me enough information to write my code without having to visit the api.drupal.org site
nearly as often. This saves a lot of time for me if it has been a little while since I have used a
specific Drupal function.
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
Remote File Editing

There are a number of circumstances in which you may have to edit a file on a remote server.
Typically you would use some type of FTP tool to push and pull file changes to your Drupal
website. There is a tool within Komodo Edit that allows you to make changes to remote files. In
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
Other nice features

Here are a few other nice features that I use in Komodo Edit
Color Schemes - If I am going to spend a lot of time editing code, I want it to look good
while I do it. Komodo Edit gives me the ability to change and completely customize the
color scheme.
Add ons - Komodo Edit has a bunch of add ons that can be used to enhance the editor.
Go to definition - This handy little feature allows you to quickly jump to the function
definition. To put it in easier to understand terms, you can right click on the name of a
function, and click Go to definition. Komodo Edit will then take you to that function. This
works well if you need to dive into a specific core Drupal function, or other functions in
your module or theme.
What are some other Code Editors to look into?

Here is a list of various code editors that I have found that you may want to look into for your
day to day code editing.
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
Why You Shouldnt Dismiss this Secret

You will probably spend more time with your Code Editor than any other tool. You may try to
dismiss the importance of this by thinking that all code editors are the same or that the code
editor does not really matter. Thinking this way is incredibly shortsighted. If you find the right
editor, you can save yourself hours of time and have a lot more fun along the way. Becoming a
Drupal Ninja is about efficiency always spend the time sharpening the weapons that you use
the most.
Becoming a Drupal 7 Ninja: Secret #1

Find the right Code Editor for you
18
Secret 2: Drush Command line Kung Fu

Dynamite comes in small packages, but that doesnt mean you should underestimate its power.
The same can be said of Drush. Drush stands for DRUpal SHell and according the the Drush
github page:
Drush is a command-line shell and scripting interface for Drupal, a

veritable Swiss Army knife designed to make life easier for those
who spend their working hours hacking away at the command
prompt.
While I think that is a fine definition, it doesnt tell the entire story. Even if you dont spend your
working hours at a command prompt, I am telling you that Drush will help you if you give it a
chance. If you are nervous or reluctant to spend time on the command line, I can promise you
that you are missing out. If you do even a modest amount of Drupal development, spending just
one hour learning how to use the command line and Drush commands will save you countless
hours of time. In the next few sections I am going to show you how Drush can be used to
automate and simplify a lot of common Drupal administrative tasks.
In the sections that follow, I am going to go through the steps to set up a basic Drupal site with
the help of Drush commands. I will leave out all the extra details about the installation such as
setting up the MySQL database. If you are looking for more information on installing Drupal,
keep an eye out for future Code Karate videos on the subject.
Getting Started By Installing Drush

The first step is to get Drush installed. Installing Drush is not an overly complicated process, but
because it varies depending on the operating system your website runs on, and if you are
running the site locally or on a remote server, I wont go through all of the installation
possibilities here. There is a page on Drupal.org that provides information depending on the
type of platform you are installing Drush on. Typically you need to install Drush on the server
that is hosting your Drupal website (you can get around this with something called Drush
aliases, however we wont be covering that topic). For the installation instructions, go to
https://drupal.org/node/1791676.
Downloading Drupal with Drush

In order to get started with a fresh Drupal 7 website, we will use a Drush command to download
the latest Drupal 7 release.
19
Drush Command
What does it do?
drush dl drupal
Download a fresh copy of the latest stable Drupal 7 release.
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
What does it do?
drush site-install standard --dburl=mysql://[MySQLUser]:[MySQLPassword]@localhost

/[MySQLDatabase]
Installs Drupal 7 website.

Note: this defaults your
username to admin and gives
you a random password.
Note: You can also use the Drush command drush si instead of drush site-install and get the
same results.
ninja less
21
Now if I go back to my new Drupal website, it will look like this:
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
Downloading and installing New Drupal Modules

We are now ready to begin installing some Drupal modules and themes on our new Drupal
website. I am going to start with one simple example. Downloading and installing the
module_filter module.
Drush Command
What does it do?
drush dl [project-name]
Downloads a Drupal module or theme. The name can be

grabbed from the drupal.org project name. For example in
https://drupal.org/project/module_filter the project name is
module_filter
drush en [module-name]
Installs a Drupal module. Keep in mind when you

download a Drupal module, it may contain multiple
modules. You can get the correct module name from the
output of the drush dl command.
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:
Here is the Drupal modules page after 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.
Downloading and installing New Drupal Themes

We will now download and install a new Drupal 7 theme. We will go ahead and download and
install the Zen theme. Although it doesnt look very pretty out of the box, Zen is a very good
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
What does it do?
drush status
Displays information about your Drupal website.
drush status theme
Displays only the theme information about your Drupal

website.
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
What does it do?
drush vget
View all Drupal variables.
drush vget [variable-name]
View a specific Drupal variable.
drush vset [variable-name]

[new-value]
Set a Drupal variable to a new value.
drush vdel [variable-name]
Deletes a Drupal variable. Note: we wont be going

over this, but use caution when deleting Drupal
variables.
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
Disabling a Drupal Module/Theme

There may come a time where you need to uninstall a Drupal module. If this is the case, you
can do so with the drush dis command.
Drush Command
What does it do?
drush dis [module-name]
Disables a Drupal module.
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.
Listing Drupal Modules and Themes using Drush

Sometimes it is useful to view the modules and themes that have been downloaded or installed
on your Drupal website. Drush provides a drush pm-list command that will allow you to easily
see a list of all the themes and modules on your Drupal website.
Drush Command
What does it do?
drush pm-list
Lists all modules and themes available to the Drupal

website.
drush pm-list -type=module
Lists only the modules that are available to the Drupal

website.
drush pm-list --type=theme
List only the themes that are available to the Drupal

website.
drush pm-list -status=enabled
List the enabled modules and themes on the Drupal

website.
34
drush pm-list -type=module -status=disabled
Lists only the disabled modules on the Drupal website.
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.
Uninstalling a Drupal Module

You can uninstall a Drupal module using the Module Uninstall page that was listed above, or
you can use the drush pm-uninstall command. This command will completely uninstall your
module removing any database tables and variables that the module has stored.
37
Drush Command
What does it do?
drush pm-uninstall [module-name]
Uninstalls a Drupal module.
drush pm-list --type=module -status=not installed
Views all the Drupal modules that are not

installed on your website.
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.
Running Cron on your Drupal website

Drupal uses a maintenance task called cron to run actions periodically. Drupal cron should be
set up to run periodically on your Drupal website. The frequency of the Drupal cron task
depends on the specific needs of the website and will vary depending on the number and type
of modules you have installed. Drupal comes with a way to configure cron from the
administration interface. You can get to the Cron administration page by going to
Configuration in the admin toolbar and clicking on the Cron link.
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
What does it do?
drush cron
Runs Drupal cron process.
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.
Clearing your Drupal cache

If you ever make changes to your site and do not know why something isnt showing up
correctly, it may be getting cached by Drupal. Drupal caches a variety of things in the database
to help speed up the performance of your Drupal site. While you are developing or after making
changes on your site, you may need to occasionally clear the Drupal cache.
Drush Command
What does it do?
drush cc
Clear the Drupal cache.
drush cc all
Clear all of the available Drupal caches.
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
Backing up your Drupal website

Backing up your Drupal website can sometimes be a hassle depending on the setup of your
website and where your website is hosted. Drush provides an easy alternative to backing up
your entire Drupal website.
Drush Command
What does it do?
drush archive-backup
Backs up the code, files, and database of a Drupal

website.
You can simply run the drush archive-backup command to quickly and easily backup your
entire Drupal website.
Restoring your Drupal website from a backup

A backup is not very helpful if you cant easily restore the backup. First we are going to test the
process, by creating a new article on our Drupal website. After creating the article, the front
page of our Drupal website is no longer empty.
42
Now we can use Drush to restore our website to our previous backup (before the article was
created).
Drush Command
What does it do?
drush archive-restore
[backup-path]
Restores a Drupal website to a previously backed up state.
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
What does it do?
drush up
Updates the modules, themes, and core Drupal code on

your Drupal website. This command will also perform any
necessary database updates.
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.

You may be thinking that everything you saw above can easily be done from the Drupal user
interface. You are exactly right, but then again you are wrong. Becoming a Drupal Ninja is about
efficiency and getting things done as painlessly as possible. Just like learning any other skill, it
will take a little time to master, but it will pay dividends in the end. I will end this section with a
simple analogy. You can definitely get where you need to go by walking, but isnt it much faster
to drive there? Using the Drupal admin section of a Drupal website is like walking, it can get the
job done, but there are much faster alternatives (in this case Drush).
47

Use Drush in all of your Drupal projects
48
Secret 3: Version Control (with Git)... Never lose your code or

your mind again
You have probably heard of Version Control or Git before. If you are not already using a
Version Control system now is the time to start. According to the Git website:
Git is a free and open source distributed version control system

designed to handle everything from small to very large projects with
speed and efficiency.
So what exactly is a Version Control System? To keep things simple, it is basically a way to
track changes that you have made to files over a period of time. It gives you the ability to not
only track those changes, but roll back to a previous point in time if something goes bad. A
version control system also makes it much easier for multiple developers to work on a single
project without stepping on each others toes.
Git is a Distributed Version Control System, which means that every developer working on a
project has a full copy of the repository. A repository is just another name for how the project
and its files are stored in the version control system. Generally when working with Git you will
have some type of server that you push your changes too. Often this will be a third party service
like GitHub, Bitbucket, or one of the many other alternatives.
Choosing the Right Service to Host Your Git Repository

There are a lot of options to consider when choosing where (and if) you want to use a third party
service to host the Git repository for your project. These services provide a lot of useful tools
that make working with your Git repository easier. Some standard tools to keep an eye out for
include:
Ability to view the code of your Git repository

Issue or Bug tracking
Create and manage Git branches of code
Built in Code Review Tools
Collaboration tools to make building a software project with a team easier
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.
Getting Started with Git

So how do you go about getting start with Git if you have never worked with a Version Control
System before? The first steps are to start by downloading Git for your operating system. Once
you have Git downloaded and installed, you may be tempted to download a Git GUI client. You
can browse for one of your choosing and try one out (I have used GitEye with some success in
the past as it provides a Linux version). I wont be covering Git GUI clients because frankly I
dont like using them and I think they shroud what is actually happening (sometimes making it
seem more confusing than it has to be). Even if you do want to use a Git GUI client, I highly
suggest learning the basics from the command line first. This will give you a much deeper
understanding of what various commands are doing and how the entire Git process works.
In the subsequent examples, you will be able to follow along to create your first Git repository,
learn the basics of Git commands, create a larger Git repository for your Drupal website, and
learn how to pull down external Git repositories (like those on Github or Bitbucket).
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
What does it do?
git config --global user.name

[name]
Configure the username for Git to use for the current

logged in user.
git config --global user.email

[email_address]
Configure the user email address for Git to use for

the current logged in user.
You will first want to configure your name.
Then you will want to configure your email address.
You should now have your basic Git configuration set up. You are now ready to create your first
Git repository.
Creating Your First Git Repository

Git Command
What does it do?
git init
Creates a Git repository in the current directory.
git init [folder]
Creates a new directory and Git repository.
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.
Viewing Your Project Status

Git Command
What does it do?
git status
View status information about your current Git repository.
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
What does it do?
git add [file]
Add a specific file to the Git staging area of your repository.
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.
Committing Your Changes

A Git commit is a way to finalize and log the changes that we have added to our Git staging
area. This essentially creates a new revision of your project at this particular point in time.
55
Git Command
What does it do?
git commit
Commits all changes from the Git staging area, and

launches a text editor to create a commit message. Save
and close the text editor to complete the commit.
git commit -m My commit

message goes here
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.
Ninja Lesson: Commit early and commit often.

Viewing Your Commit History
What good is creating new revisions using Git commits if you cannot easily see what has
changed.
Git Command
What does it do?
git log
View a history of commits to the Git repository containing the

author, date, and description of the commit.
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).
Viewing What Has Changed

Now that we have our first Git commit under our belt, we will make a few more changes. Lets
add an additional line to our test.txt file.
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
What does it do?
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
What does it do?
git reset [file]
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
What does it do?
git checkout [file]
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
What does it do?
git revert [commit]
Provides a way to safely remove a previous commit. Git will

automatically remove the changes, and then create a new
commit. This way you still have a history of the change being
removed.
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
An Introduction to Git Branches

To me, Git branches are the most powerful feature Git has to offer. Initially they seem very
complicated, but they are actually simple once you understand their uses and their benefits.
One thing to keep in mind is that Git branches are incredibly flexible. Entire books and blogs
have been written on how Git branches can be used in a specific way to build the ideal
development process for various types of software. With that in mind, we will only be scratching
the surface of what Git branches offer.
Lets start with a practical, and possibly old fashioned example. Assume you are writing some
type of paper. Assume you are using an old word process that is not online, but is instead a
program on your computer. You write the paper and decide that it needs a lot of work. Instead of
editing the document directly, you make a copy and work on that document. This way if you
really mess something up, you can just delete the copy and start over. When you are done with
this copy and you like the changes, you may manually copy in the changes you like, or if you
like all the changes, just get rid of your old version and use this new version as your paper.
This example is similar to how a Git branch works. You are essentially making a complete copy
of your repository so you can either work on new features, fix bugs, or keep different versions of
your code. There are two common ways that I have used Git branches in the past.
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).
Ninja Lesson: If you use some type of project management or task

management system (and you should), you can name your branches containing
the id number of the task. For example if I have a task to add a newsletter
signup form to a website with a task id of 123, I would create my branch and
call it 123_newsletter_signup_form to make it easy to track down exactly
what it is and why it was created.
There is a third and more complex way. If you are building more complex software with longer
release cycles a method known as Gitflow (or various versions of it) can be used. The reason I
dont mention it in more detail is because it is slightly more complex and can lead to longer
release cycles for your software. I enjoy having the ability for myself or the developers I work
with to be able to make a change and have it released on the live website in the same day
(sometimes in a matter of a few hours). This keeps the process lightweight and simple. In most
cases with websites you do not want long release cycles and instead want the process of
getting something launched on the live site to be managed but not difficult.
Lets look at the paper example again. You could email your paper to a friend for editing. Your
friend would make some changes and suggestions and send it back to you. You would then
decide which changes you want to keep and those that you are not going to use. In this
example, think of your paper as the master Git branch. Your friend gets a copy (a new Git
branch), makes some changes (some Git commits), and requests that the changes be merged
in (a Git merge request). Now that you understand the basic concepts, we are ready to try out a
few real examples.
Creating a Git Branch

The first step to learning how to actually implement Git branches is to create your first Git
branch. In the following examples, we will go through the process of implementing a new branch
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
What does it do?
git branch [branch_name]
Create a new branch (copy of the code) to use to

develop a new feature or fix a bug.
git branch
Lists all of the available branches
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.
Checking out your Git Branch

Now that we have the branch created, we need to checkout the branch in order to start
committing our code changes to it.
Git Command
What does it do?
git checkout [branch_name]
Checks out an existing Git branch. This simply

switches your code to a different Git branch.
git checkout -b [branch_name]
Creates a new Git branch and checks it out. This is

a shortcut so you do not have to create the branch
and check it out using two steps.
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.
Making changes on your new branch

Making changes on your new branch is exactly the same as before. Simply make the changes,
add your changes to the staging area, and commit your changes to your Git branch. In this
example we make a small change to a text file, add the change, and make the Git commit.
71
Merging a Git Branch

After you make your changes and you have those changes tested and ready to go, the time will
come to merge in your changes from your feature branch into your master branch. Again, the
master branch is typically the Git branch used for your production level code.
Git Command
What does it do?
git merge [branch_name]
Merge [branch_name] into your currently checked

out Git branch.
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
What does it do?
git mergetool
Opens up an external Diff viewer or merge tool for

merging conflicts.
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.
Pushing your Repository to Github

In the next few sections we will look at both Github and Bitbucket and how to push your Git
repository up to these Git hosting services. This section will only prove to be a really quick
getting started. There is ample documentation on both of these services online if you choose to
pursue using one or the other. First we will look at Github.
You will first need to create an account at github.com. Once you are logged into your account,
you will want to set up your SSH keys. Your SSH Key is how Github knows who you are. This
way when you push up your changes, Github will be able to determine if you have access to the
Git repository you are trying to push or pull from. The first step is to make sure you have an
SSH key setup on your local system. Since the setup varies depending on your operating
system, you will want to search for something like Generate SSH Key [operating-system].
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
What does it do?
git remote add [remote-name]

[remote-url]
Adds a remote repository called [remote-name]

located at [remote-url]. We can now push and pull
from this repository (assuming we have
permission).
git push -u origin master
Push our master Git branch to the remote called

origin.
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
Learning about Git remotes

You already ran your first git remote command. But what exactly is a Git remote anyway? A Git
remote is a remote Git repository that you can synchronize with. Because Git does not have a
centralized repository, you can have multiple Git remotes setup for one project. There are a
couple commands that are useful when working with Git remotes.
Git Command
What does it do?
git remote
Lists the available remotes for your current Git

project.
git remote -v
Provides more information about your Git remotes,

such as the location and what operations can be
performed.
83
git remote rm [remote-name]
Remove a Git remote from your current Git project.
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.
The other is a Create a repository link in the Repositories section.
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.
Cloning an Existing Git Repository

It is not only useful to know how to push up your Git repository to a third party service, it is also
useful knowing how to pull this repository down so you can make changes to it.
Git Command
What does it do?
git clone [git-url] [foldername]
Clone a Git repository at [git-url] and place it in a

new directory called [folder-name]
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
The .gitignore file

You may need to have certain files inside your project folder that you do not want inside your git
repository. You can tell Git to ignore these files using a file named .gitignore. The gitignore file
simply lists file patterns that tell Git to ignore those files. In the case of a Drupal website, it is
important to ignore the settings.php which contains your database connection information. You
will also want to make sure to ignore any user uploaded files that have been uploaded to the
files directory.
In a gitignore file the * character can be used as a wildcard character, meaning it will match any
file or directory name. The * character can not be used to traverse multiple directories though,
so the pattern sites/*/settings.php would match sites/default.settings.php but would not
match sites/default/test/settings.php.
You will not actually look at a gitignore file until the next section when you add your Drupal site
to a new repository. There is a lot more to gitignore than is mentioned above, for more
information you can visit http://git-scm.com/docs/gitignore.
90
Bringing It All Together With Drupal

Now that you know the basics of Git, you are ready to apply this to your Drupal website. Go to
your document root of your Drupal website and run the git init command.
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.

Learning Git is intimidating. There are a lot of moving parts and a lot of things that can seem to
go wrong. You will run into problems such as merge conflicts or trying to figure out how to undo
commits, but these hurdles are worth the effort. Everyone makes mistakes, but what separates
a Drupal developer from a Drupal Ninja, is the Drupal Ninja knows how to quickly and painlessly
recover from those mistakes. You probably use some type of backup system for the hard drive
91
of your computer. Git is like a supercharged collaborative backup and recovery system for your
entire project.

Use Git to keep track of how your project has changed over time
92
Secret 4: Development Process and Hosting Dont you dare

touch production
One mistake I made in the past and I have seen countless other developers make is thinking
that one Drupal website is enough. When a change needs to be made it simply was made on
the live website. I have used excuses to myself in the past such as the website does not get a
lot of traffic so no one will notice or it is a really simple change. Talk about famous last words.
Bad things happen when you touch production, not all the time, but more often than you will
probably ever think.
The solution is simple, but its far from easy. It requires that you change the way you think about
your Drupal development process. You are no longer just building a single website, you are
creating a development process that will improve your quality. Yes it will take a little bit more
time, but the extra effort will save you headaches down the road and decrease your chances of
bugs or issues getting to the live website.
Why you should define your development process

Spending times thinking about and actually defining your development process is one of the
best uses of your time you can spend as a Drupal developer at the beginning of a project or
website. By defining a specific process, you will find that your quality will improve, you will have
more peace of mind when making changes, and you will allow less errors to get to your
production website.
In the next sections we will explore what some typical development processes look like and how
they are used to help you become a Drupal 7 ninja.
What does a typical development process look like

Making your first step in setting up a development process typically involves setting up one of
these site configurations. You may choose to start with a single development site and your live
site:
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.
Define your release process

The next step is to optimize your release or deployment process. Git is the first step to
simplifying this process. By using Git you can easily migrate code changes to modules or
themes. Just using Git is one thing, but figuring out how to make the entire process work is
another. There are many ways you can design this process out to make it work for you, however
we will look at a simple example. In this example we will assume you are using just a
development and a live websites, using a single master branch in your Git repository.
You start by developing your changes on your development environment. This development
environment may be a localhost on your computer, or on a development server. When you are
finished with the development of the new feature, you use Git to commit and push your changes
to a Git hosting service (like Github or Bitbucket).
The next step is to pull down these changes on your live environment. You will then most likely
run through a process of running Drupal updates and clearing the Drupal cache. This step is
necessary if you update any modules that require database updates. This process can be as
simple as running the drush updatedb command on your live site.
That is all there is to getting a simple development release process setup. Lets look at the
process one more time.
On the development site you:
1. Develop your new features, update contributed modules, modify the theme, or do any
other type of code changes necessary.
2. You add these changes to your Git staging area using the git add command.
3. Next you commit these changes to your Git repository using the git commit command.
4. Finally you push your changes up to your Git hosting service using the git push
command.
On the live site you:
1. Pull down the most recent changes to the repository using the git pull command.
2. Run the dush updatedb command. This will perform any necessary database updates
and clear the Drupal cache.
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.
Choosing how to host your Drupal website

While your website hosting doesnt necessarily define your entire development process, it
certainly has an effect on how the process works. In this section we will look at various different
types of hosting solutions and how they may affect your development process.
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.
Paste in your SSH key and click Add Key.
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
In the top right you will notice a Getting started link.
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
In this case we will select the radio button next to Drupal.
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
What I dont like about Acquia Cloud

Since there is so much flexibility, the interface is a little difficult to learn. There are links in
multiple places that do the same thing and this can be a little confusing when you are just
getting started. The pricing is slightly more expensive, but you get a lot more with it than with
other comparable services. The setup process is not quite as smooth as it could be, but overall
is not a bad experience.
When to use Acquia Cloud
If you are looking to build a more enterprise level site or collection of sites, Acquia Cloud might
be a great option for you. It works wonders for smaller sites too, but the cost is a little inhibitive
for a small Drupal website. With the ability to scale your Drupal website and eventually take
advantage of Acquias top notch support services, you can not go wrong with this route if you
have the budget. It provides a streamlined workflow that is very customizable to whatever
development process you want to use, and it allows some flexibility in the configuration of your
server.
We use Acquia Cloud at STEM Fuse and it is perfect for all our Drupal development needs.
Custom VPS Solutions

If you like to have fine grained control over your Drupal hosting and want to be the one doing
the server setup, update, and maintenance, then a Custom VPS Solution might be the choice
for you. This solution is often cheaper than other hosting alternative and puts you in the drivers
seat.
What is a custom VPS Solution
A VPS is a virtual private server. Essentially you get your own virtual server (on some other
server in a data center). On this server you can choose from a variety of server operating
systems and can set up this server however you want. Although its not 100% accurate, I am
going to bucket VPS services and public cloud services together in the same category. The
pricing structure may be slightly different sometimes, but there is so much overlap that it is often
difficult to tell the difference.
To host a Drupal 7 website, you will need to install things on the server such as a web server
(Apache, Nginx, etc), a database server (MySQL, MariaDB, PostgreSQL) and PHP. You may
also install things like Memcached, Varnish, and other performance enhancing tools.
With your custom VPS setup, you may choose to run everything on a single server, or split your
database, and web server across multiple servers. You could eventually add things such as a
caching server and load balancer to help really scale out your Drupal website. You may also
look into tools such as Chef or Puppet to control how you set up servers in the future. These
tools allow you to manage your server configuration through code to make it easy to build
identical copies of servers quickly. When you get all of that setup and configured, it might be
time to look into a continuous integration server such as Jenkins.
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
Getting Started with Shared hosting

When get started with Shared hosting there are a few general steps you will need to follow. If
you are migrating an existing site, you will need the Drupal code and your Drupal database
ready. You will typically create your database, create your database user, import your database
code, and then upload your Drupal code. You will need to make sure that your settings.php file
correctly connects your Drupal website to your new database.
Once you have that setup, you will then need to test your site to make sure everything was
pulled over correctly. Be aware that you may run into PHP memory problems on shared hosts
(depending on how many modules you have enabled on your Drupal site). Each shared host
has a slightly different process to increasing the PHP memory settings and there are some
limitations.
If you are creating a new Drupal website, some shared hosting providers have a one click
Drupal website creator that will create a Drupal website for you. If not, you simply need to
download the latest version of Drupal from drupal.org and upload this to your shared hosting
provider. You can then create your database, create your database user, and create your
settings.php file to connect the site to the database.
What I like about Shared hosting
Price. That is about the only reason you should ever really consider using a shared hosting
provider. Even then, only use a shared hosting provider if you are hosting a relatively small
Drupal website. If the website is going to get a lot of traffic or require constant development, this
is not the option you are looking for.
What I dont like about Shared hosting
There is a reason that you hear a lot of negative things about shared hosting from other Drupal
and web development professionals. It is simply not as reliable, not as customizable, and has
worse performance than any of the other options listed above. It is a little bit like gambling, if you
know when to place your bets, you can win sometimes with shared hosting, but there will
eventually come a time when you are going to lose. If you do a lot of Drupal development, you
might eventually find out the hard way that the risk was not work the small cost savings.
When to use Shared hosting
Do not make the mistake of falling into the trap of thinking that shared hosting is just the easiest
solution. This is often not the case. Although the initial setup may be the quickest, there is a
good chance you will run into website performance issues, development process issues, and
more down the road. If you need cheap hosting, have a small Drupal site, and dont expect to
170
make a lot of changes to your site, then maybe, just maybe, this is the option you are looking
for.
Which one is right for me?

This is difficult question, but one I know many Drupal developers ask. If you dont want to worry
about server setup or maintenance, then go with Pantheon or Acquia Dev Cloud. If you are
stuck between those two, it is a good problem to have because both are great in their own
respects. I think Pantheon is quicker to get started with and requires much less time to get your
website up and running. However, Acquia provides a more customizable development workflow
and provides a little more configuration options (although it requires a little more time to figure
out how it all works). Acquia Cloud is more expensive, but provides additional services such as
Acquia Support that you can eventually add to your Drupal website hosting service. No matter
which you choose, you will be in good hands.
If you want to do the server setup, administration, and maintenance on your own, and you want
to save a little money (at the expense of spending more time), the a custom VPS option might
be your best bet. I have learned through the years that this option is not good for me, as I often
struggle to find the time to keep the server up to date. Also, I prefer to spend my time
developing instead of working on a server. However, if you like that kind of thing (and I know a
lot of people that do), then this option could be right for you.
If you want to manage your own server, and you are going to be developing and hosting a lot of
Drupal websites, then Aegir could be worth looking at. I have had a lot of success with it in the
past, but it does require you to change how you think about Drupal websites and makes it more
difficult to manage staging and development sites. It can work very well if you are willing to
invest the time into learning how it works best. You can also consider the hosted option of Aegir
using Omega8.cc if you want the benefits of Aegir without the server management.
I wouldnt recommend shared hosting unless you are very limited in your budget. Then try to
make sure to find a shared hosting provider that offers SSH access or Git deploy functionality so
you can use Git with your Drupal website.

The average Drupal developer does what is easiest at the time to get the job done. Because of
this, the average Drupal developer is constantly fighting similar problems over and over again. A
Drupal ninja fights a much broader, higher level battle at the beginning. This is the battle to
determine how all your other development battles will be fought and won. It is because of this
initial step of coming up with a streamlined and consistent development process, that a Drupal
Ninja can win future development battles more quickly and efficiently. It also provides peace of
mind knowing exactly how things are supposed to work and how to easily recover from the
things that dont. It is not necessarily the specific process that matters most, it is the fact that
you have specifically defined a process that works for you and your team.
171

Define your development process and choose a quality hosting provider
172
Secret 5: Features Module Get your site configuration in order

One of the biggest pitfalls of going to a development, staging, live site environment is that
Drupal stores so much of your website details in the database. This includes things like content
types, fields, views, panels, and much more. Since you cant easily migrate database changes
from one Drupal site to another (without doing so manually), you need to have a way to get your
site configuration (content types, field, views, panels and more) out of your database and into
your code. This way you can track these things with Git and push them to your different
environments. This is where the Drupal 7 Features module comes in.
What is a Drupal Features Module

The Drupal Features module allows you to export your site configuration into a special Drupal
module (often called a Features Module). This module can be installed on your Drupal site just
like any other Drupal module (but requires the Features module to be installed). This allows you
to package your site configuration into a bundled module.
Lets assume you are a Drupal development company, and you want to offer clients specific
packages where a client can choose what features they want on their website. You could build a
collection of features modules and depending on what the client wants, just install those specific
features modules to turn on that functionality on the client website. If the client wants an image
gallery, a pressroom, and a blog, you simply enable those three features modules and all of the
basic functionality is there. You just need to theme or style the features to match the rest of the
site and your client quickly has those features. This can be a huge time saver and helps from
having to develop the same type of functionality over and over.
Unfortunately though, the way mentioned above is the most common way that the Features
module gets used. Only using the Features module for this purpose is like riding a bike with a
flat tire, you can still get to where you are going, but you are only using a tiny amount of the
bikes full potential. A Drupal ninja knows there is a lot more to the Features module then there
initially seems.
How Features fits into your development process

The Features module is the glue that holds a great Drupal 7 development process together. Its
helpful to look at the problem first, then its easy to see the full potential of the Features module.
Imagine you have a development, staging, and live Drupal 7 website for a client. Assume there
is a view on the site that displays Blog posts and the client wants to have a field added to the
blog posts. On the development site, you go into the content type and add the field, you then go
into the view and add the field to the view. No problem, that was a pretty easy change. Now,
however you have this fancy development process and you need to get these changes on your
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
Ninja Lesson: The Features module isnt just to package re-usable

functionality, the Features module is also used to migrate configuration
changes across all the different environments of your Drupal 7 website.
Getting Started with Features
In this first step we will create a simple Features module with basic blog functionality. This
Features module will have a content type and a view. To get started make sure you have at
least two Drupal sites to test on. One will act as your development site, and the other act as a
staging or live site. If you followed along with the hosting section above, you can use either
Pantheon or Acquia Cloud to really test this process out. In this example I will use Pantheon.
Start by downloading the Ctools, Views, and Features modules on your development site. You
can use the Drush command drush dl ctools views features to download them all at once.
You can then install the necessary modules with the drush en ctools views views_ui features
command.
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.
Making Changes to your Drupal Feature Module

Now that you have your Feature module created, you will sometimes need to make a change to
your created module. In this case, lets add a taxonomy term field to our Blog content type. We
first go to the Manage Fields page of our Blog content type and go to the Add existing Field
section. We select the field_tags term reference field and click the Save button. You can also
create a new term reference field if you would prefer to not use the field_tags field that is
already available.
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
What does it do?
drush fu [module-name]
Updates a Drupal feature module to whatever is currently

in the Drupal database.
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.
Using Features to Migrate Changes between Drupal Websites

At this point you have a Feature module called Simple Blog that can be dropped into any Drupal
site to create simple blogging functionality. This is the first main use of the Features module, to
create re-usable functionality so you dont have to manually create the functionality on multiple
Drupal sites. However the secret and real power in the Drupal Features module is leveraging
the module to migrate changes between development, staging, and live sites. This is what we
will look at next.
You have your Simple Blog feature module created on your development site right now, the next
step is to migrate this module to your stage site and enable it. If you are using Pantheon or
Acquia Cloud this process is easy. Just commit up your changes to your Git repository and
migrate your development environment code to your staging environment.
Once the module is available on your staging site, make sure to enable it. This will provide you
the content type and view to create your simple blog. You could of course follow this process
and push your Simple Blog feature module up to your live site too. In order to really test this
process you will need to make sure you have your Feature module installed and enabled on
your stage or live site (depending on how your development process is setup). You will also
want to make sure it is at the Default state.
If you need to make a change to some configuration (content types, views, etc) on your live site
(or in this case just the staging site), you need to start the development of this change back on
your development site.
Lets assume you need to change the view for your blog to display more items in a pager and to
allow admins to see unpublished items. Lets also assume you want comments to be turned off
by default for your blog posts. First you make the change to the view on your development site
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.
Click the Save button to save your changes to the view.

Now you need to get the comments to be Closed by default on your Blog content type. You can
do this by going to the Content Types administration page, and clicking the edit link on the Blog
content type. In the Comment settings section change the Default comment setting for new
content to be set to Closed.
197
Click the Save Content Type button.

If you go back to your Features administration page you will see that the Simple Blog feature
module is overridden (just as you would expect). If you click the Overridden link you will notice
that only the Views section shows that it is overridden. Nothing shows up for the content type
that you just changed (to switch the comments to closed by default). This is because the
comment settings for a content type is actually a variable stored in the Drupal variables
database table. These variables can be exported to a Feature module, however they require the
help of an additional Drupal module called StrongArm.
Using Drush we can download and enable the StrongArm module.
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
What does it do?
drush fr [module-name]
Reverts the current Drupal database to match whatever is

stored in the [module-name] Feature module code.
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.

Just when you thought you understood what a Drupal website was, there is an extra variable
the configuration. The configuration of your Drupal website typically lives in the database, where
the average Drupal site builder is comfortable. A Drupal Ninja steps out of their comfort zone
and brings their Drupal configuration into the code, where it can be managed with absolute
204
precision and migrated between Drupal environments. A Drupal Ninja doesnt like clicking the
same buttons twice.

Use the Drupal Features module to manage the configuration of all your
Drupal websites
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.

1. Find the right Code Editor for you
2. Use Drush in all of your Drupal projects
3. Use Git to keep track of how your project has changed over time
4. Define your development process and choose a quality hosting provider
5. Use the Drupal Features module to manage the configuration of all your
Drupal websites
In Closing
Drupal is a great tool to build all different types of websites. It can be used for simple blog
websites, incredibly complex websites, and everything in between. However, because it is such
a powerful tool, many developers do not know of some basic tricks to get the most of their
Drupal website and their Drupal development processes and procedures. There will always be
new tools available to learn about and use within your project. So much so that it can become
exhausting trying to keep up. Your job is to find the right balance between learning, and doing.
You can always learn about more tools, but eventually you will hit a point of diminishing returns,
where you will spend more time learning than actually building. Drupal is meant to be used to
build and create. You can also spend too much time on the other end of the spectrum. Spending
all your time building and creating, and never taking time to step back and try to find ways to do
things better. Find that balance, and you will truly become a Drupal Ninja.
Keep Learning, Keep Improving, Keep Building

Shane Thomas
Founder of Codekarate.com
Drupal Developer and aspiring Drupal Ninja
206

The 5 Secrets To Becoming A Drupal 7 Ninja Shane Thomas 2014 Diypromo PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

The 5 Secrets To Becoming A Drupal 7 Ninja Shane Thomas 2014 Diypromo PDF

Загружено:

Авторское право:

Доступные форматы

The 5 Secrets to Becoming a Drupal 7 Ninja

by Shane Thomas - Codekarate.com