the 5 secrets to becoming a drupal 7 ninja shane thomas 2014 diypromo.pdf

The 5 Secrets to Becoming a Drupal 7 Ninja 1

The 5 Secrets to Becoming a Drupal 7 Ninja by Shane Thomas - Codekarate.com


Contents Let’s 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

IDE’s ..................................................................................................................................17

Any others? ........................................................................................................................18

Why You Shouldn’t 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… Don’t 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 Shouldn’t 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 Shouldn’t Dismiss this Secret ............................................................................... 204

Wrap Up.................................................................................................................................. 206

The 5 Secrets to Becoming a Drupal 7 Ninja ....................................................................... 206

In Closing ............................................................................................................................ 206


Let’s 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 don’t think a

blog post will do it justice. I also don’t 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 don’t 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. Don’t 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 don’t 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 don’t 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.

http://codekarate.com/



● I upgrade all my Drupal modules one by one. I update Drupal core manually as well.

● I don’t 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.

Don’t 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 don’t 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, let’s 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… don’t 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, don’t 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 don’t 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.

https://api.drupal.org/


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.

https://api.drupal.org/api/drupal/modules!system!system.api.php/function/hook_form_alter/7


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


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.


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 wouldn’t think of using it for my day to day code editing. If

http://www.vim.org/


you do give this one a try, don’t give up at the first sign of struggle. Without learning the shortcut

keys and the extra features, you might dismiss it before you realize it’s 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.

IDE’s

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

http://komodoide.com/komodo-edit/

http://notepad-plus-plus.org/

http://macromates.com/

http://komodoide.com/

https://www.eclipse.org/


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 can’t 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 haven’t found

“the one” yet. Here is a good link to a Drupal.org page that goes over a number of tools I haven’t

covered here - https://drupal.org/node/147789

Why You Shouldn’t 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

https://netbeans.org/

https://drupal.org/node/147789


Secret 2: Drush… Command line Kung Fu Dynamite comes in small packages, but that doesn’t 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 doesn’t tell the entire story. Even if you don’t 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 won’t 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 won’t 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.

https://github.com/drush-ops/drush



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:


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 site-install standard --db-url=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


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:


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 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:

https://drupal.org/project/module_filter


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:


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.


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 doesn’t look very pretty out of the box, Zen is a very good

https://drupal.org/project/zen


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 isn’t 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.


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 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.


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

website’s 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 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 won’t 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.


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.


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.


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.


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 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.


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 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.


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.


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.


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.



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.


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.


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 Drupal’s built

in Cron.


drush cron Runs Drupal cron process.

You can manually run the Drupal cron process using Drush by running the drush cron

command.


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 isn’t 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 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.


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 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 can’t 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.


Now we can use Drush to restore our website to our previous backup (before the article was

created).


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.


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 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.


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.


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 Drupal’s

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:


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 isn’t 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).



Use Drush in all of your Drupal projects


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 it’s 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 it’s fees on the number of private repositories you require.

http://git-scm.com/

http://git-scm.com/about/free-and-open-source

http://git-scm.com/book/en/Getting-Started-About-Version-Control

https://github.com/

https://bitbucket.org/


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. Github’s interface and collaboration tools are slightly better than

Bitbucket’s 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 don’t 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 won’t be covering Git GUI clients because frankly I

don’t 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.

http://git-scm.com/downloads

http://git-scm.com/downloads/guis


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 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.


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 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 don’t 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.


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.


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.


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 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.



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 let’s 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 log View a history of commits to the Git repository containing the author, date, and description of the commit.


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. Let’s

add an additional line to our test.txt file.


We will also create a new subfolder inside our git_test folder. Let’s call this directory

test_folder.


Inside this new test_folder directory, we will create a new file called test2.txt.


We can now view the status of our git repository with the git status command.


Notice the command output of the git status command let’s us know that the test.txt file has

been modified. It also lets us know about an untracked directory called test_folder.


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.


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 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.


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.


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 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.


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 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.


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).


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.

Let’s 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.


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 it’s own unique

Git branch. If you need to fix a bug, you create a new branch to fix that bug, and when it’s ready,

merge it into the master branch. If there is a new feature to be built, you create a new Git


branch, develop the new feature, and when it’s 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

don’t 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.

Let’s 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


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 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 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.


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.


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 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.


Fixing a Conflict

It is inevitable, eventually something will happen that will cause some type of conflict in your

commit. Don’t 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 can’t 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.


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.


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.


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 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


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.


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]”.

https://github.com/


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.


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.


We will grab that first line of code and paste it on our command line (inside our Git repository).


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.


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.


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 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.


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


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.


Once you create the repository, you will see a page that displays information on how to add

your code.

If you click the I’m starting from scratch link, you will see information on how to create a new

Git repository and add Bitbucket as a Git remote.


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 don’t want to create a remote

called origin. We will want to add a new remote and call it bitbucket.


Now we need to push up the repository to bitbucket using the git push command. We don’t

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 it’s 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 clone [git-url] [folder-name]

Clone a Git repository at [git-url] and place it in a new directory called [folder-name]


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.


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.

http://git-scm.com/docs/gitignore


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


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


Secret 4: Development Process and Hosting… Don’t 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 it’s 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:


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


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. Let’s 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


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 can’t be overlooked is your hosting provider.

Choosing how to host your Drupal website

While your website hosting doesn’t 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.

https://www.getpantheon.com/


https://www.getpantheon.com/pricing

https://dashboard.getpantheon.com/register

https://dashboard.getpantheon.com/register


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.


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.


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.


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.


Your Pantheon Dashboard may feel intimidating at first, however it’s 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.


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.


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.


Now complete all the necessary steps and add in the site information at the end of the

installation process.


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.


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).


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.


If you open up the pantheon.aliases.drushrc.php file, it will contain information to access your

Dev and Live environment with Drush.


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.

http://help.getpantheon.com/pantheon/topics/using_drush_60_pantheon_how_set_strict0_globally


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.


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 don’t 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


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 can’t 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, don’t 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 Acquia’s 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.

http://www.acquia.com/products-services/acquia-cloud

http://www.acquia.com/cloud-pricing

http://www.acquia.com/acquia-cloud-free


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.


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.


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.


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.


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.


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.


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.


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.


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.


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


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.


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.


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 it’s complete, you will see

that your new database has been added to all environments.


You will now have both databases listed on your Databases page.


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.


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.


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.


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.


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/cron-

wrapper.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 * * * *






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 don’t 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.


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.


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.


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.


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.


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.


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.


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 SSH’ing 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.


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

"[email protected]" command followed by git config --global user.name "Your Name"

command to identify yourself to Git and re-run the commit.


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.


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.


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 Acquia’s 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 it’s own, so feel free to really spend some time using Acquia’s documentation if

you want to learn more about Acquia’s other services.

What I love about Acquia Cloud

There are so many awesome things about Acquia Cloud I don’t 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?

https://drupal.org/project/acquia_connector

https://drupal.org/project/acquia_connector


What I don’t 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 Acquia’s 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 it’s 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.

http://www.stemfuse.com/


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 company’s 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 don’t 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… it’s 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 don’t 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.


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 Drupal’s 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 Aegir’s 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.

http://www.aegirproject.org/


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 wouldn’t 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.

https://github.com/omega8cc/boa

https://drupal.org/project/barracuda

https://drupal.org/project/octopus

https://drupal.org/project/hostmaster

https://omega8.cc/


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.


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.


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.


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.


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.


To view a more complete list of the tasks, you can click the More tasks link.


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).


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.


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.


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.


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.


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.


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.


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.


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


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.


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.


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.


The process will create a task to migrate the site to the new platform.


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.


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 don’t like about Aegir

Aegir introduces additional terminology you probably won’t 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).


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


● 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 don’t 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 don’t expect to


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 don’t 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 wouldn’t 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 don’t. 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.



Define your development process and choose a quality hosting provider


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 can’t 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.

Let’s 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

bike’s 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. It’s

helpful to look at the problem first, then it’s 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

https://drupal.org/project/features


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 it’s 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.

Don’t 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.

Let’s 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

https://drupal.org/project/strongarm


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 it’s 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 it’s

ready for prime time. Imagine you had to make 20 changes on your development site. No

problem, the process is the same and doesn’t 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.


Ninja Lesson: The Features module isn’t 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.


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. It’s 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.


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.


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.


Now go ahead and add a few example blog posts and go to your /blog-posts page to take a

look.


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.


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


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 it’s default in this section).

https://drupal.org/project/fserver

https://drupal.org/project/fserver


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.


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.


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.


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.


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, let’s 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.


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.


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.


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 let’s 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 it’s the field instances section.


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.

https://drupal.org/project/diff


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 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).


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 don’t 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.

Let’s assume you need to change the view for your blog to display more items in a pager and to

allow admin’s to see unpublished items. Let’s 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



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.


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.


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.


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.

https://drupal.org/project/strongarm


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.


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: It’s 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.


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 features-

revert [module-name] command or the drush fr [module-name] command for short.


drush fr [module-name] Reverts the current Drupal database to match whatever is stored in the [module-name] Feature module code.


In this case we run drush fr simple_blog and enter y when asked if we want to continue (this

will revert the staging site’s 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.


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.


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


precision and migrated between Drupal environments. A Drupal Ninja doesn’t like clicking the

same buttons twice.


Use the Drupal Features module to manage the configuration of all your

Drupal websites


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.

The 5 Secrets to Becoming a Drupal 7 Ninja

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

the 5 secrets to becoming a drupal 7 ninja shane thomas 2014 diypromo.pdf

Documents

Transcript of the 5 secrets to becoming a drupal 7 ninja shane thomas 2014 diypromo.pdf