IntroductionWelcome| 00:00 | (music playing)
| | 00:03 | Hi! I am Jon Peck and welcome to
Simplified Drupal Sites with Drush.
| | 00:09 | I am a Zend-certified PHP engineer
with more than a decade of web application
| | 00:13 | development experience.
| | 00:15 | In this course we'll look at Drush, the
command-line utility for managing Drupal sites.
| | 00:21 | I'll start by describing exactly what
Drush is and why it can be helpful, then
| | 00:25 | show you how to install it and perform
core functions including module, user,
| | 00:30 | and cache management,
| | 00:32 | plus other techniques useful for
quickly assembling and manipulating a
| | 00:35 | functional Druple site from the ground up.
| | 00:38 | Let's get started with
Simplified Drupal Sites with Drush.
| | Collapse this transcript |
| Using the exercise files| 00:00 | In this course, I'll be creating a
Drupal 7 site from the ground up using the
| | 00:04 | Drush command-line utility.
| | 00:06 | Drush typically resides in the same web
hosting environment as the sites it manages.
| | 00:11 | The recommended configuration for the
host environment is PHP 5.3 or above,
| | 00:17 | Apache 2 or above and MySQL 5 or above.
| | 00:21 | Other web servers such as Nginx or
IIS and other databases like PostgreSQL
| | 00:26 | should function but will not be supported.
| | 00:29 | Setting up an AMP stack is
beyond the scope of this course.
| | 00:32 | If you do not already have a
development server I recommend using a local
| | 00:36 | development server running on your workstation.
| | 00:38 | The Up and Running with Linux for PHP
Developers course here in the lynda.com
| | 00:43 | Online Training Library will allow
you to have an optimized virtual server
| | 00:47 | running like any other program
in your existing operating system.
| | 00:51 | Additionally, an overview of how to
interact with the Linux command-line is
| | 00:55 | provided with many principles
that also apply to Mac OS as well.
| | 00:59 | I will be demonstrating using a
server created using this technique.
| | 01:03 | Alternatively, you can use a web
server solution stack package in your
| | 01:07 | native operating system.
| | 01:08 | XAMPP from apachefriends.org has
distributions for Linux, Windows, Mac OS X, and Solaris.
| | 01:15 | WampServer from wampserver.com is
explicitly for Windows and MAMP from mamp.info
| | 01:23 | is for Mac OS X only.
| | 01:25 | Each of these packages will allow you to
execute the exercises found in this course.
| | 01:30 | Installing additional software within
your native operating system is covered in
| | 01:34 | the course installing Apache, MySQL,
and PHP with David Gassner here in the
| | 01:39 | lynda.com Online Training Library.
| | 01:42 | If local development is not an option,
remote and third-party hosted servers
| | 01:46 | that have the appropriate versions of PHP,
MySQL, and Apache also support Drupal 7.
| | 01:52 | SSH access to a command-line shell
is required to be able to use Drush.
| | 01:56 | So verify that the third-
party provide shell access.
| | 02:00 | You will need access to the command-line in
the location of the Drupal site installation.
| | 02:04 | For Mac and Linux the terminal allows
you to access the command-line which
| | 02:08 | includes access to the SSH
command if the site is hosted remotely.
| | 02:13 | In Windows the Command prompt will
work with Drush, but does not provide SSH access.
| | 02:19 | You can use the free program PuTTY
to connect via SSH to remote servers
| | 02:23 | available from the official PuTTY website.
| | 02:26 | The exercise files for this course are
contained in a folder named "sandbox"
| | 02:30 | that my virtualized Linux server can access.
| | 02:33 | Depending on your web server
configuration, you may need to store these files in
| | 02:37 | a different place such as a remote web
server or in a folder accessible by a
| | 02:41 | local Apache, MySQL and PHP stack.
| | 02:44 | In addition to these files, a quick
reference to the Drush commands covered in
| | 02:49 | this course is provided as a PDF.
| | 02:51 | Feel free to print out and
distribute this quick reference.
| | 02:54 | A final note, as different web hosts
and configuration serve content from
| | 02:59 | different URLs, the address you see in
my browser may not exactly match what you
| | 03:04 | see on your workstation.
| | 03:06 | Additionally, the location shown in
the command prompt demonstrations will
| | 03:09 | differ depending on the location of site files.
| | 03:12 | The commands will still apply in the same way.
| | Collapse this transcript |
| What you should know| 00:00 | This course is designed with the
assumption that you have the foundational
| | 00:03 | knowledge of Drupal 7 installation and
management, including modules and themes,
| | 00:08 | user management and so forth.
| | 00:11 | Drupal 7 Essential Training by Tom
Geller here in the lynda.com Online
| | 00:15 | Training Library demonstrates how to
download and install Drupal, add content
| | 00:20 | and graphics to a site, change layout
and design elements, control visitor
| | 00:24 | interactions, and expand the site's
capabilities beyond what's available in Drupal's core.
| | 00:30 | Drush is designed for use on a server
running a UNIX like OS such as Linux or Mac OS.
| | 00:35 | So you should have some base
knowledge of working with a command-line shell
| | 00:39 | interface such as Linux or Mac terminal.
| | 00:43 | If you aren't familiar with Linux or
the Mac terminal, I recommend the Up
| | 00:47 | and Running with Linux for PHP
Developers course here in the lynda.com
| | 00:51 | online Training Library.
| | 00:53 | It includes some thorough descriptions
and demonstrations of how to work with
| | 00:56 | the Linux command-line,
which is very similar on the Mac.
| | 01:00 | If you require Windows for your
development in server environment Drush does
| | 01:04 | support most functionality on Windows
and provides a dedicated installer that
| | 01:08 | often lags in both functionality and timeliness.
| | 01:12 | As the implementation is incomplete and
has known issues only the installation
| | 01:16 | procedure for Drush for Windows will be
covered for completeness and will not be supported.
| | 01:22 | Finally, this course covers a large
number of everyday commands contained with
| | 01:26 | Drush, but is not a comprehensive
survey of every single command available.
| | 01:31 | Additionally, depending on the version
of Drush that you are using some commands
| | 01:35 | may have evolved slightly.
| | 01:37 | This course was written using Drush 5
.8 and is intended to be compatible
| | 01:42 | with future versions.
| | 01:44 | If any inconsistencies arise using a
newer version check the documentation
| | 01:48 | and change logs.
| | Collapse this transcript |
|
|
1. Getting Started with DrushWhat is Drush and why should I use it?| 00:00 | Before describing what Drush is, I am going
to take a step back and outline what Drupal is.
| | 00:05 | From a high-level perspective, Drupal
is an open-source content management
| | 00:10 | framework that can be used to
build a content management system.
| | 00:13 | By providing a highly modularized
architecture, the building blocks and the base
| | 00:17 | framework can have functionality added
through modules and designs in themes.
| | 00:23 | Drupal is used to power websites of
many different scales from simple static
| | 00:28 | portfolios and brochures to
interactive blogs, and enterprise grade web
| | 00:33 | applications and corporate sites.
| | 00:36 | The management of these sites and
features is done almost exclusively through an
| | 00:40 | administrative web interface.
| | 00:42 | By providing an interface without
requiring the use of a client other than a web
| | 00:46 | browser virtually anyone
can build and maintain a site.
| | 00:50 | This versatility comes at a price.
| | 00:53 | By providing an exclusive web interface
Drupal site administrators are met with
| | 00:57 | a number of frustrating limitations.
| | 01:00 | Each page load consists
of multiple transactions.
| | 01:04 | The browser makes a request, the server
generates a response, and the browser
| | 01:08 | interprets the response.
| | 01:10 | This is a number of steps.
| | 01:12 | Markup is also transferred along with
CSS and JavaScript, so on and so forth.
| | 01:17 | Building a page on the server takes
resources and time, depending on the number
| | 01:22 | of modules that are enabled, a single
page request can take over 128 megs of RAM
| | 01:27 | and generate dozens of database queries.
| | 01:29 | An additional overhead is introduced by
providing a menu and form genuine user interface.
| | 01:35 | Options can be buried in a maze of menu items.
| | 01:39 | To clear the cache for example, I'll
have to log into the site, click on
| | 01:45 | Configuration, click on
Performance, then click Clear all caches.
| | 01:54 | From start to finish, this
manual process took a lot of work.
| | 01:58 | Given that these interfaces are web-
based, scripting actions is impractical
| | 02:03 | due to the number of HTML elements in
responses that need to be parsed and interacted with.
| | 02:08 | Yes, testing framework such as
Selenium provide a mechanism to script
| | 02:12 | activities, but in this context it's
like wanting a cup of tea and flying to
| | 02:16 | India, instead of just putting the kettle on.
| | 02:19 | Finally, web interfaces restrict
access to potentially damaging activities.
| | 02:24 | I hesitate calling this a limitation as
there's hundreds of fantastically good
| | 02:28 | reasons for preventing someone who
has just enough knowledge to do damage
| | 02:31 | from wreaking havoc.
| | 02:33 | With that said, sometimes it's good to pop
the hood if you know what needs to be done.
| | 02:38 | With that context, I can describe what Drush is.
| | 02:41 | Starting with the name,
Drush, stands for Drupal shell.
| | 02:45 | A shell is a software that provides
an interface to a particular component,
| | 02:50 | typically an operating system.
| | 02:52 | Shells can be command-line and graphical.
| | 02:54 | Drush is a command-line shell.
| | 02:56 | In particular, Drush can be used as a
scripting interface, allowing groups of
| | 03:01 | actions to be performed with a single command.
| | 03:04 | Drush has two official pages.
| | 03:06 | A website drush.org, which primarily
consists of generated documentation any
| | 03:11 | project page on drupal.org.
| | 03:14 | Drush has been around since 2006
when it was initially developed by Arto
| | 03:19 | Bendiken to manage Drupal 4.7 sites.
| | 03:22 | A partial redesign and
reimplementation for Drupal 5 in 2007 increased
| | 03:27 | visibility of the project, which has
since evolved into a full Drupal.org
| | 03:31 | project maintained and
expanded by the community.
| | 03:35 | Today Drush supports Drupal 6, 7
and 8, and works on Linux, Mac OS, and
| | 03:41 | Windows Operating Systems.
| | 03:43 | Why use the command-line tool like
Drush when functionality is available
| | 03:47 | elsewhere in the Graphical User Interface?
| | 03:50 | Most simply, Drush will save time
with sheer speed and versatility.
| | 03:54 | For example, clearing the cache can be
done with one simple command instead of
| | 03:59 | navigating through
multiple menus and interfaces.
| | 04:02 | Using the scriptable capabilities
operations such as downloading and installing
| | 04:06 | modules can be automated
and placed in version control.
| | 04:10 | Providing the tools that interact with
Drupal from the ground up, the overhead
| | 04:14 | of browser transactions is eliminated
and precise actions can be performed with
| | 04:18 | less chance of missing a checkbox or option.
| | 04:21 | Drush is a fantastic tool that I use on
a daily basis, but it has some drawbacks
| | 04:26 | in terms of approachability.
| | 04:28 | The documentation for Drush, while
thorough and improving, can be intimidating and
| | 04:33 | obtuse for people who don't
live, breathe, and code a Drupal.
| | 04:37 | Drush.org the homepage is an example of this.
| | 04:41 | It's a very useful source for information,
but it's literally dozens of commands
| | 04:45 | and all of their arguments are
displayed on one page. Where to start?
| | 04:48 | My goal is to educate and inform about
how Drush can be practically leveraged to
| | 04:53 | administer Drupal sites.
| | 04:55 | To do that, I will be building a fully
functional Drupal site from the ground up.
| | 05:00 | This includes module installation and
administration, user and cache management
| | 05:04 | for troubleshooting and
maintenance, to copying entire sites.
| | 05:08 | I will be performing all
demonstrations in this course using Drush 5.8.
| | 05:14 | If you look at the Drupal.org homepage, you
will see the version displayed as 7.x-5.8.
| | 05:21 | This is due to the way
drupal.org versions files.
| | 05:25 | Drush 5.8 is compatible with
both Drupal 7 and Drupal 6.
| | 05:30 | In this course, I will
demonstrate using Drupal 7.
| | 05:33 | The tools and techniques described in
this course are common core functionality
| | 05:37 | that should be safely future proof.
| | 05:39 | In the next segments I will
demonstrate how to install Drush.
| | 05:43 | The README.TXT included with Drush
provides installation instructions as well.
| | 05:48 | Refer to them for additional
guidance if needed. I'll be upfront.
| | 05:52 | Installing Drush can sometimes be
complicated and using Drush is actually
| | 05:56 | easier than installing it.
| | 05:58 | With that said, most of the time
installation is easy and straightforward.
| | 06:03 | I will demonstrate multiple
techniques that will cover the vast majority of
| | 06:06 | system setups and installation options.
| | 06:09 | Not all steps are necessary for every system.
| | 06:12 | Use your best judgment to determine
which combination is best for your needs.
| | Collapse this transcript |
| Installing the prerequisites wget and unzip| 00:00 | This section installing the
prerequisites is intended for Linux and Mac users.
| | 00:05 | Windows users do not need to do
this and should skip to the Windows
| | 00:09 | installation segment.
| | 00:11 | Before I start installation the first
step I need to take is to ensure that the
| | 00:15 | prerequisites are installed. Drush
leverages a new Wget, a free and open source
| | 00:22 | software package, for retrieving files.
| | 00:24 | And Unzip, a mechanism for extracting archives.
| | 00:28 | Without them Drush just won't work properly,
so these prerequisites need to be installed.
| | 00:33 | Most hosting environments and
operating systems will already have both
| | 00:36 | these commands installed.
| | 00:39 | Open a terminal and connect to
your development environment.
| | 00:42 | I'll first demonstrate on my Linux
virtual server, verify that Unzip is installed.
| | 00:49 | To verify, type the following: unzip.
| | 00:53 | If you do not see help listing
then Unzip needs to be installed.
| | 00:56 | If the command line environment is
Linux then Unzip can be installed using
| | 01:00 | the package manager.
| | 01:01 | For example, with Ubuntu and Debian
systems use the command "sudo apt-get
| | 01:08 | install unzip".
| | 01:13 | On CentOS and other systems using
the yum package manager use the command
| | 01:18 | "sudo yum install unzip".
| | 01:22 | When complete verify that Unzip is installed.
| | 01:29 | Next, determine whether
or not Wget is installed.
| | 01:32 | To do that just type "wget", if it is
installed a simple error stating that no URL
| | 01:39 | was given will be shown.
| | 01:40 | If this error from the Wget is shown
then no further work is required and you
| | 01:44 | can skip to the next segment.
| | 01:46 | If Wget is not installed then it'll need
to be installed before Drush can be used.
| | 01:51 | If the environments that will be used
for Drush is a third party shared host
| | 01:55 | that does not provide you privileges
to install programs, please contact the
| | 01:59 | host and request that Wget be made available.
| | 02:02 | Similar to Unzip, Wget can be installed
using the package manager on Linux systems.
| | 02:08 | Ubuntu and Debian systems can use
the command "sudo apt-get install wget".
| | 02:16 | On CentOS and the other systems using
the yum package manager use the command
| | 02:20 | "sudo yum install wget".
| | 02:27 | Then verify that the Wget has
been installed by typing "wget";
| | 02:31 | I'm going to exit out here and clear.
| | 02:37 | If you are using Mac OS X Lion or
Mountain Lion there is a strong possibility
| | 02:41 | that you do not have Wget installed.
| | 02:44 | To do so it'll need to be compiled
and installed as there is no officially
| | 02:49 | recommended binary available.
| | 02:51 | This will take some additional
steps, but I'll demonstrate them.
| | 02:55 | To install Wget it must be compiled
which on a Mac requires either Xcode 4 or
| | 03:00 | Xcode 4 command-line tools to be installed.
| | 03:04 | If you already have Xcode 4 installed,
you do not need to explicitly install
| | 03:08 | the command-line tools.
| | 03:10 | If you don't have Xcode 4 installed
visit developer.apple.com/downloads
| | 03:16 | and download the current version of
the command-line tools for Xcode 4
| | 03:19 | your operating system.
| | 03:21 | Once these tools are
installed installation can continue.
| | 03:25 | First, I will download Wget
directly from the home page using the cURL
| | 03:29 | command-line utility which comes
installed with Mac OS X. From the command-line
| | 03:33 | enter the following command: curl Space -O
| | 03:37 | http://ftp.gnu.org/gnu/wget/wget-1.14.tar.gz.
| | 03:58 | Next, decompressed the downloaded files
using the tar archive utility, "tar Space
| | 04:03 | -xzf", then the name of the file;
change directory to the decompressed files.
| | 04:13 | Before compilation a configuration
step is needed, only one option is required
| | 04:18 | specifying that SSL support will be
handled with open SSL, meaning files can be
| | 04:23 | downloaded from secure sites.
| | 04:25 | So type: ./configure --with-ssl=openssl.
| | 04:36 | Once the configuration is
complete build the source by typing "make".
| | 04:45 | This will take a minute or two.
| | 04:47 | When compilation is been completed
install the file into the default location
| | 04:52 | user local bin, so type "sudo make
install", it will ask me for my password.
| | 05:01 | Following installation, verify
that the Wget is installed, wget.
| | 05:06 | Now that the-based dependencies of
Drush have been fulfilled I can install
| | 05:10 | Drush itself.
| | Collapse this transcript |
| Installing Drush with PEAR| 00:00 | The preferred method for installing and
maintaining the Drush utility is to use PEAR.
| | 00:05 | PEAR is an acronym that stands for the
PHP Extension and Application Repository,
| | 00:10 | which provides a library of open source
PHP code including a code distribution
| | 00:15 | and package maintenance system.
| | 00:17 | This method is preferred as it's
relatively OS agnostic and makes it easy to
| | 00:21 | stay up-to-date and manage dependencies.
| | 00:24 | PEAR is not required to use Drush, if
you prefer to manage software installation
| | 00:29 | more directly use the manual
installation instructions in the next segment.
| | 00:33 | While there are a number of steps
required it is a one-time setup.
| | 00:38 | I'm going to open a terminal and
connect my sandbox environment.
| | 00:44 |
| | 00:44 | To determine whether or not PEAR is
installed type the following command "pear version".
| | 00:50 | If PEAR is installed the version
will be displayed, if the version is not
| | 00:54 | displayed then PEAR needs to be installed.
| | 00:57 | More in-depth instructions
are available at pear.php.net.
| | 01:01 | I will demonstrate the most common techniques.
| | 01:04 | If you are using a Linux distribution
such as Ubuntu or Debian the apt package
| | 01:09 | installer can be used to install
PEAR, "sudo apt-get install php-pear".
| | 01:17 | It'll ask me for my password, I say
I wish to continue and it installs.
| | 01:26 | If you are using a Linux distribution
such as CentOS, type the following command
| | 01:31 | "sudo yum install php-pear".
| | 01:36 | If you would like to install PEAR on
any other system including MacOS X without
| | 01:40 | using a package manager, type the
following: cd Space user/local, sudo wget
| | 01:48 | http://pear.php.net/go-pear.phar then
pseudo php -d detect_unicode=0, and then,
| | 02:05 | go-pear.phar, everything is correct,
press Enter to continue and Enter again and
| | 02:14 | then verify the PEAR is
installed by typing "pear Space version".
| | 02:20 | If you're using a third-party host
that does not provide PEAR there is a web
| | 02:23 | front-end mechanism that can be used to
install PEAR, this method is a bit more
| | 02:27 | involved that can provide an
installation mechanism in some circumstances.
| | 02:32 | Due to the variations between third-
party hosts the PEAR web installer will not
| | 02:36 | be covered in this course.
| | 02:38 | With that said documentation is available on
| | 02:40 | pear.php.net/manual/en/installation.getting.php.
| | 02:48 | Before installing Drush ensure that
PEAR is updated, depending on your
| | 02:53 | environment you may not need the sudo
command at the beginning of the line.
| | 02:56 | If you get error stating that you do
not have permission, login as root or use
| | 03:00 | the sudo command: sudo pear
upgrade Space --force pear.
| | 03:13 | Drush has PEAR specific dependencies
that need to be installed, type "sudo pear
| | 03:19 | upgrade Space --force Console_
Getopt and then Console_Table".
| | 03:32 | Finally, make sure everything else
is up-to-date "sudo pear upgrade-all".
| | 03:39 | Now that the groundwork is
set Drush can be installed.
| | 03:43 | First, specify the location of the
Drush installation files, "sudo pear
| | 03:48 | channel-discover pear.drush.org".
| | 03:55 | Finally, install Drush itself "sudo
pear install drush/drush", verify that Drush
| | 04:05 | is installed by using the "which" command,
"which" locates a command. Use "which" to
| | 04:09 | locate Drush, "which drush" then
attempt to execute Drush, "drush".
| | 04:17 | If you see a message like Drush needs
to download a library from etcetera,
| | 04:22 | you're seeing a non-permissions issue,
to resolve: "execute sudo drush", and the
| | 04:29 | error message will go away.
| | 04:30 | Type the following to remove the
administratively created directory: sudo rm -Rf
| | 04:40 | ~/.drush, then verify that
Drush is properly installed, "drush".
| | 04:46 | Now that Drush is installed via PEAR
it can be upgraded with both the PEAR
| | 04:50 | "upgrade all" command demonstrated
earlier and the command specific to upgrading
| | 04:54 | Drush, "sudo pear upgrade drush".
| | 05:00 | Drush will inform you when an upgrade
is available during normal usage with
| | 05:03 | a simple notice to the command-line which
won't affect the operation you're performing.
| | 05:07 | Drush and all its dependencies
have been installed. Now what?
| | 05:12 | In the next chapter, I will demonstrate
how to install a site using Drush, how
| | 05:15 | to get information about the site and
the modules, and how to manage modules,
| | 05:19 | users, and more.
| | Collapse this transcript |
| Installing Drush manually| 00:00 | Depending on the available permissions
and comfort level a manual installation
| | 00:04 | may be the most appropriate.
| | 00:06 | At the highest level, Drush manual
installation is just unzipping the archive.
| | 00:10 | However, there are couple steps involved in
making it useful which I will demonstrate.
| | 00:14 | First, download Drush using Wget.
| | 00:16 | Wget in its simplest operation just
takes URL which it will download to the
| | 00:22 | current directory, type
"wget" then URL of Drush 5.8,
| | 00:27 | http/ftp.drupal.org/files/
projects/drush-7.x-5.8.zip.
| | 00:41 | Now that the archive has downloaded,
extract it using the Unzip command, "unzip drush".
| | 00:48 | Now that the contents have been extracted,
I no longer need the archive, so I'll
| | 00:52 | remove it to keep my home directory clean.
| | 00:57 | The zip file contains a single
directory named Drush, change directory to the
| | 01:01 | Drush directory "cd drush".
| | 01:05 | Next, I'm going to use the chmod
command to grant myself execution permissions
| | 01:09 | on the Drush executable, chmod u
stands for user, plus (+) means to add, and x
| | 01:16 | stands for execution followed
by the name of the command, "drush".
| | 01:21 | Drush can now run, but if I was in any
other directory then I would have to know
| | 01:25 | the full path to be able to
execute it, which is frankly a pain.
| | 01:29 | Instead, I'm going to make the commands
available no matter which directory I'm in.
| | 01:34 | To do that, I first need to know
exactly what directory I'm in right now, so I
| | 01:38 | will use the pwd command which
returns the working directory.
| | 01:42 | I'm currently in users John Peck Drush;
| | 01:45 | your directory will be different
depending on the operating system and user.
| | 01:49 | If you have administrative privileges,
you can perform the following command to
| | 01:53 | symbolically link Drush to the user
bin directory which will make the command
| | 01:57 | available throughout the entire system.
| | 01:59 | As the directory is protected, elevated
privileges are required, so either use
| | 02:03 | sudo or log in as root for the step,
I'll be using "sudo" followed by "ln" for
| | 02:08 | link "-s" for symbolic.
| | 02:11 | Next, I'll provide the path to be
linked to, which is the directory shown
| | 02:14 | with the pwd command: /Users/johnpeck/
drush followed by slash (/), and then
| | 02:22 | "drush", the command itself.
| | 02:24 | Finally, Space then the path for the
symbolic link, which I will put in user/bin/drush.
| | 02:32 | Change directory back to the home directory
and test that the link worked "which drush".
| | 02:37 | The result should show that the Drush
command is available at user/bin/drush.
| | 02:43 | If you do not have administrative privileges
then there is another method that can be used.
| | 02:48 | By editing the shell configuration file, I
can manually specify the location of Drush.
| | 02:53 | Depending on the system that is
being installed the file may be slightly
| | 02:57 | different. It's highly likely that you
have one of the following files already
| | 03:00 | installed: bash_profile which is
what's available on Mac, bashrc which is the
| | 03:07 | default on Ubuntu and Debian, and .
profile which is another possibility.
| | 03:12 | To check for the files, use the list
directory contents command ls and I'll look
| | 03:18 | for a: ~/.bash_profile, it's not there;
let's try ls ~/.bashrc, it's also not
| | 03:29 | there; and then profile, also not there.
| | 03:34 | If none of these files exist,
you will need to create one.
| | 03:37 | So start with .bashrc first, on a
Linux system, and bashprofile on a Mac. I'm
| | 03:42 | going to edit the file and I'm
going to use the text editor, nano.
| | 03:46 | So, "nano Space -w", currently I'm on the
Mac, so "~/.bash_profile", add the following
| | 03:57 | line to the end of your file.
| | 03:59 | I am going to use the directory shown
with PWD command, this will be different
| | 04:03 | for your system: export PATH="$PATH:/
Users/johnpeck/drush" exit and save by
| | 04:17 | pressing Ctrl+X then Y to confirm.
| | 04:19 | Load the configuration file using the
source Command, "source", I'm going to load
| | 04:25 | bash profile, so you may need to load
bashrc or profile depending on the system.
| | 04:31 | The next time I log in, the
configuration will be loaded, so this is a one-time
| | 04:36 | thing: ~/.bash_profile.
| | 04:40 | Verify the Drush is available by using the
"which" command to locate Drush, "which drush".
| | 04:47 | Drush has now been manually installed.
| | 04:50 | To upgrade Drush, you'll need to
remove the Drush directory and repeat the
| | 04:54 | extraction, and make the Drush command
executable as previously demonstrated.
| | 04:59 | In the next chapter, I will demonstrate
how to install a site using Drush, how
| | 05:03 | to get information about the site and
the modules, how to manage modules, users
| | 05:08 | and more.
| | Collapse this transcript |
| Installing Drush for Windows| 00:00 | An official installer for Drush is
available for Microsoft Windows, providing a
| | 00:04 | convenient method for installing
Drush and its needed components.
| | 00:09 | The homepage is at: drush.org/drush_
windows_installer, and it provides current
| | 00:18 | project status, links to the
files, and installation instructions.
| | 00:23 | The Windows installer usually lags a
bit behind the officials Drush release,
| | 00:27 | illustrated by the rest of the
course using Drush 5.8 and the Windows
| | 00:31 | installer still on 5.7.
| | 00:33 | The Drush installer supports Windows 7,
Windows Vista Service Pack 2 or higher,
| | 00:38 | Windows XP Service Pack 3 or higher,
Windows Server 2003 Service Pack 2 or
| | 00:44 | higher, Windows Server 2008,
and Windows Server 2008 R2.
| | 00:50 | There are also a couple of
supported shells, minsw and msysgit which are
| | 00:55 | recommended, the command prompt, and PowerShell.
| | 00:59 | Msysgit is not distributed with the full
Drush installer as it's a separate project.
| | 01:04 | However, it does provide Git in patch support.
| | 01:07 | The full installer for official Git is
recommended but Shell installation is not
| | 01:12 | covered in this course.
| | 01:13 | There are some limitations.
| | 01:15 | Most SQL commands will work with SQL Server
but the dump database command will not work.
| | 01:21 | SQL-sync is not really working, and
Drush make does not work correctly in 5.7.
| | 01:28 | To use the Windows installer, download
the installer then run it with the user
| | 01:31 | account that has administrator privileges.
| | 01:38 | Click Next on the Welcome page, you
will be given a number of options.
| | 01:42 | The first three items are
required runtimes, leave them alone.
| | 01:46 | The fourth, add support for the
Rsync command if you're interacting with
| | 01:50 | Linux and UNIX servers.
| | 01:52 | Register Environment Variables is a
useful shortcut that will automatically add
| | 01:55 | all required paths to the Path
Environment Variable. The last option,
| | 02:02 | Configure Windows Remote Management, allows
remote commands to be used from the client.
| | 02:06 | Where Drush is installed to a remote
Windows server where Drupal is hosted.
| | 02:11 | For more in-depth details on these
options refer to the installation guide
| | 02:14 | linked from the bottom of
the Windows installer homepage.
| | 02:18 | When I'm done configuring the
options, click Next and then Install.
| | 02:23 | If prompted, say yes to run as
administrator, then click Finish.
| | 02:30 | Verify that Drush is installed by double
-clicking on the Drush command's prompt
| | 02:34 | and typing the following, "drush".
| | 02:38 | In the next chapter, I will demonstrate
how to install a site using Drush, how
| | 02:43 | to get information about the site and
the modules, and how to manage modules,
| | 02:47 | users, and more.
| | Collapse this transcript |
|
|
2. Core Functionality for Everyday OperationsSite installation and introspection| 00:00 | Throughout this course I will be
building a Drupal site piece by piece.
| | 00:04 | In this segment I will start by
downloading the Drupal core, gathering
| | 00:08 | information about site status
then performing a site installation.
| | 00:12 | Throughout this process I'll describe
how each command works, and how it relates
| | 00:16 | to everyday operations.
| | 00:19 | Before you begin identify the location
of your Web server root that you want to
| | 00:23 | build your site and determine the
following about the database, the username
| | 00:27 | and password, database name, and the port
that you wish to use for connection settings.
| | 00:34 | I'll start by opening a command
line, connecting to my sandbox, and
| | 00:41 | navigating to the Web server root
where I will start the base installation,
| | 00:45 | cd /media/sf_sandbox.
| | 00:48 | I'll list the content to the directory to
ensure that there are no files on it, ls - la.
| | 00:55 | If you type drush help, you will see
a comprehensive list of all commands
| | 01:00 | that drush is aware of.
| | 01:02 | To get help on any command type
'drush help' then the name of the command.
| | 01:07 | The first command I will
demonstrate is pm-download, which stands for
| | 01:12 | Project Manager download.
| | 01:17 | Project Manager is a group of commands
within Drush that allows you to download,
| | 01:20 | manipulate, and analyze the Drupal
extensions both modules and themes.
| | 01:25 | While I can type the entire
command there is a shorthand alias, dl;
| | 01:29 | that I will use to save time.
| | 01:31 | Drush will display high-level
information about the command, followed by
| | 01:35 | examples, arguments, options,
and finally any aliases.
| | 01:46 | The first of the examples is the
commands that I will be using, downloading the
| | 01:49 | latest recommended release of Drupal core.
| | 01:52 | The only argument that the Project
Manager Download command takes is a comma
| | 01:56 | separated list of projects to download,
which in this case is the Drupal core
| | 02:00 | itself, drush dl and then
the project name drupal.
| | 02:05 | As there is no site installed Drush
will just default to downloading Drupal and
| | 02:09 | extracting the contents into a
directory named Drupal 7.17 which is as of this
| | 02:15 | writing the current version.
| | 02:16 | Once Drupal core is downloaded Drush
will be aware of the context, and will not
| | 02:20 | append to the project version to
any downloaded modules or themes.
| | 02:24 | I see a success message describing
what happened, followed by a summary of
| | 02:28 | everything that was in the downloaded project.
| | 02:30 | In this case 3 profiles,
4 themes, and 47 modules.
| | 02:36 | I can also manually specify a
particular release by version using drush dl
| | 02:40 | Drupal 7.x, which will download the
latest version of Drupal 7 now 7.15;
| | 02:48 | we'll expressively download Drupal 7.15.
| | 02:54 | Perform a directory listing
to see what changes were made.
| | 02:56 | There is one directory Drupal 7.17
as described in the status message.
| | 03:03 | Drush keeps all the temporary files
and results of its operations out of the
| | 03:07 | site root, which helps keep the workplace clean.
| | 03:09 | Change directory to Drupal 7.17
then list the directory contents.
| | 03:15 | All of the contents that Drupal
project have been extracted which is
| | 03:18 | exactly what I wanted.
| | 03:19 | Let's get some introspection into
Drupal, the command core status aliased as
| | 03:24 | just status, so 'drush help status'
provides a bird's eye view of the current
| | 03:30 | Drupal installation.
| | 03:31 | I'll show the help on the core status command.
| | 03:35 | There not nearly as many options for this
Command, but it doesn't mean that it is not helpful.
| | 03:39 | For now I just want to get
the status report, drush status.
| | 03:44 | The Drupal version Default and
Administrative theme, PHP configuration, Drush
| | 03:49 | version and configuration,
and Drupal root are displayed.
| | 03:53 | This is incredibly helpful for giving
context when asked to help out with another site.
| | 03:58 | When a Drupal site is installed this site
will give connection information as well.
| | 04:03 | The next command I will demonstrate is
site-install aliased as si, drush help si.
| | 04:11 | Site Install is a powerful tool
allowing an administrator to complete the
| | 04:15 | install a site using a given
installation profile with a single command, rather
| | 04:19 | than slogging through pages of configurations.
| | 04:22 | It also creates the first user UID1
and randomly generates a password for the
| | 04:26 | user displaying the result.
| | 04:28 | There are also a large number of
options for the site-install command.
| | 04:33 | In its simplest form site-install will
use the database configuration that was
| | 04:36 | specified in settings.php, but as this
is as freshly downloaded installation
| | 04:41 | that information is missing.
| | 04:43 | So if I just do drush si, Drush
rightfully complaints that there is no database
| | 04:49 | connection so I will need to
specify it using drush si --db-url=.
| | 04:58 | This is only required for the
initial install not reinstalls.
| | 05:02 | The DB URL is specified using the Drupal
6 database URL for conciseness and will
| | 05:07 | generate the regular
array structure automatically.
| | 05:10 | I'm using a MySQL database
connection with a username and password root.
| | 05:15 | I'm going to put it on the
localhost at 127.0.0.1, on port 3306.
| | 05:26 | That's the default port
using the database Drush.
| | 05:30 | Your connection settings may be
slightly different than the ones I'm using,
| | 05:34 | please adjust them to
reflect your working environment.
| | 05:37 | Before I perform the command I'm
going to specify one more option the
| | 05:42 | password of the admin user, so I
don't have to keep track of the randomly
| | 05:46 | generated password.
| | 05:47 | This is fine for a development
environment but avoid doing this in a
| | 05:49 | production context.
| | 05:51 | --account-pass=admin, press Enter and
Drush will install the site, but first it
| | 06:01 | will prompt to you about what it's about to do.
| | 06:03 | Create the database tables which
include dumping any existing database tables.
| | 06:08 | So it wants to be sure that
this is what should be performed.
| | 06:11 | I am sure so I'll just say y for yes.
| | 06:13 | A few moments later an installation
is complete and the admin password is
| | 06:18 | displayed for my records.
| | 06:21 | I'll switch to my browser and navigate
to where my site is installed which in my
| | 06:25 | case is http://sandbox.dev:8080/
drupal-7.17, Welcome to Site-Install.
| | 06:37 | This site has been installed using the
standard Drupal installation profile.
| | 06:42 | Login using the username and password,
admin, admin, to verify everything
| | 06:48 | is working properly.
| | 06:49 | Switch back to the terminal.
| | 06:52 | Now that the site is installed drush
status is going to be a lot more helpful.
| | 06:58 | In addition to the status
information shown before the site URL database
| | 07:03 | connection information, ability for Drupal to
bootstrap, site and file paths are displayed.
| | 07:09 | Now that the site has been installed
and I have some perspective into the site
| | 07:13 | I'm going to start managing the modules
including listing, searching, enabling,
| | 07:17 | and disabling modules.
| | Collapse this transcript |
| Listing and managing modules| 00:00 | The Start Drupal interface for module
administration works but doesn't scale
| | 00:04 | well when dealing with large numbers
of modules and doesn't allow filtering
| | 00:08 | without a third-party module.
| | 00:10 | Additionally, it won't allow downloading
of new modules which I've demonstrated
| | 00:14 | in the previous segment.
| | 00:16 | Drush can also provide a
fire hose of information.
| | 00:19 | I'll demonstrate how to control that firehouse.
| | 00:22 | The command, Project Manager List,
aliased as PML shows the list of available
| | 00:27 | modules and themes, "drush help pml".
| | 00:32 | To be clear this list is what is
available in the Drupal installation, not
| | 00:36 | what's available to download on drupal.org.
| | 00:39 | I'll start by listing every
single available extension, "drush pml".
| | 00:45 | A fantastic amount of information, the
package, name, type, status, and version are shown.
| | 00:53 | Let's filter this down a bit
and only show Enabled extension.
| | 00:57 | The option, Status, takes a comma
separated list of options including an; Enabled,
| | 01:02 | Disabled, and Not Installed.
| | 01:04 | I will start with: drush pml status = "
not installed", as this requires quotes.
| | 01:16 | The list can also be changed using a
comma, to demonstrate this I will show
| | 01:20 | every module that is not
installed and/or disabled.
| | 01:23 | So, status = "not installed, disabled".
| | 01:32 | Another useful argument is type
which filters by extension type.
| | 01:39 | There are two options, Module and
Theme, I'll list only themes, type=theme.
| | 01:47 | The four core themes are now shown.
| | 01:49 | I will get into theme management in the
next segment as it's similar to module
| | 01:53 | management but has
enough quirks to set it apart.
| | 01:56 | The next argument I will
demonstrate is filtering by package.
| | 02:00 | Before I do that, I'm going to
download the develop project, so there will be
| | 02:04 | some variety, "drush dl devel".
| | 02:08 | The develop projects also
provides Drush commands if enabled.
| | 02:11 | In fact, many Drupal
projects provide Drush support.
| | 02:15 | Now that devel has been downloaded,
list all extensions again, drush pml.
| | 02:22 | I can see that devel is in package development.
| | 02:25 | I'd like to only show
extensions in the development package.
| | 02:29 | So I will use "drush pml" with the option
package=development, which also takes a
| | 02:36 | comma separated list of
package names, case insensitive.
| | 02:41 | The modules in the devel package are now shown.
| | 02:44 | I just downloaded a new extension devel.
| | 02:47 | But what information can drush
tell me about the devel module itself?
| | 02:51 | Two commands are available, the first,
Project Manage Info aliased as PMI, "drush
| | 02:58 | pmi devel" can give me some
technical information about the module.
| | 03:04 | A second command, Product Manage
Release notes, aliased as RLN, "drush rln",
| | 03:10 | will show release
notes on a particular package.
| | 03:16 | Use arrow keys to scroll, press Space to
go down a page and then press Q to quit.
| | 03:23 | What if I want to search for a
particular package, but I don't know exactly what
| | 03:26 | package it's in? Drush doesn't
support this functionality explicitly.
| | 03:31 | But I will show you a trick
that's available on UNIX like systems.
| | 03:35 | By piping the output of the package
manager list dgrep, I can search using a keyword.
| | 03:40 | Let's say I want to determine whether
or not the comment module is enabled.
| | 03:43 | I will start with "drush pml" to get the
list, then the pipe character, to send the
| | 03:50 | output of PML to another command.
| | 03:51 | I will use grep which will filter based
on a regular expression which can also
| | 03:56 | be just the word I'm looking for.
| | 03:58 | I will use "Space -i" to make
the search case insensitive.
| | 04:03 | I am looking for comment, so I
will just type the word "comment".
| | 04:08 | I can see that there is
one module named "comment";
| | 04:12 | by combining the list command with grep
I can quickly filter the list of modules.
| | 04:17 | It looks like the comment module is enabled.
| | 04:19 | I don't want anyone
commenting on my development site.
| | 04:23 | So I will just disable it using the
Project manager disable command, which can
| | 04:27 | also be shortened to just
dis, drush help dis.
| | 04:31 | The Disable command will disable an
extension and any dependent extensions if any.
| | 04:37 | So, "drush dis" and then "comment".
| | 04:41 | I'm prompted if I want to disable comment.
| | 04:44 | While I'm sure I want to, I just want to say
yes to any prompt that's given to me by Drush.
| | 04:50 | I'll say no for now.
| | 04:51 | Then redo the command, drush dis comment.
| | 04:55 | But this time with an additional option, -y.
| | 04:58 | Which will say yes to any prompt.
| | 05:02 | Same as using the web interface
disabling the module isn't the same as
| | 05:05 | completely uninstalling it.
| | 05:07 | Drush supports this as well with
the Project Manager Uninstall command,
| | 05:11 | drush help pm-uninstall.
| | 05:15 | Notice that there's no alias for this
command, pm-uninstall takes a list of
| | 05:20 | modules to be uninstalled.
| | 05:21 | I will uninstall the comment module and
I will use the same yes option right at
| | 05:26 | the front to show that it
doesn't matter where it is.
| | 05:29 | So, drush -y pm-uninstall comment.
| | 05:36 | The Comment module is now
completely disabled and uninstalled.
| | 05:40 | The inverse is also possible using the
Command Project Manager enable, aliased as
| | 05:44 | just en, drush help en.
| | 05:48 | Enable will enable the
extension along with any dependencies.
| | 05:53 | Enable will by default also download any
libraries that may be used by the module.
| | 05:58 | For example, the devel module
downloaded earlier can use fire PHP.
| | 06:03 | Let's enable the devel module now to see the
automatic Library download: drush -y en devel.
| | 06:14 | Devel was enabled but if you don't
have subversion installed then fire PHP
| | 06:19 | was not downloaded.
| | 06:21 | This is one of the
admittedly goofy bits of Drush.
| | 06:24 | I will occasionally find these little
weirdnesses like commands not working
| | 06:27 | quite right and it turns out that
there's a missing dependency that it
| | 06:31 | doesn't explicitly state.
| | 06:33 | That's why I went through the trouble
of making sure you had Wget an Unzip
| | 06:37 | installed, as that's caused problems in
the past when I was trying to figure out
| | 06:40 | why it was failing silently.
| | 06:42 | In this particular case, you can use
the package manager of your system
| | 06:45 | to install subversion.
| | 06:47 | In this case, I'm going to use
"sudo apt-get install subversion".
| | 06:58 | Then, "drush -y", I am going to disable devel.
| | 07:04 | And then, "drush -y en devel" to enable it.
| | 07:11 | This time fire PHP was installed.
| | 07:14 | One more trick, were you ever curious
how many modules were installed on a site?
| | 07:18 | I will list every extension of type
module in package core that is enabled.
| | 07:22 | I will use an additional argument "--pipe"
to only show of module names: drush pml
| | 07:29 | --type=module package=core
status=enabled, and then, --pipe.
| | 07:38 | As it stands this would work, but I
don't want to count each of these lines.
| | 07:42 | I can pipe the results into the WC or
Word Count command with the option -l to
| | 07:48 | count the number of lines. So, Space pipe wc -l.
| | 07:54 | There are 28 modules in core
that are enabled right now.
| | 07:58 | This technique is useful, especially
when trying to make the case that there are
| | 08:01 | a large number of modules on a site
and someone says, "it's not so bad."
| | 08:06 | Now there's a quantifiable
number to back up your claims.
| | 08:10 | Now that I've demonstrated the
foundation of listing, enabling, and disabling
| | 08:14 | extensions, let's explore
theme management and variables.
| | Collapse this transcript |
| Theme and variable management| 00:00 | Downloading and enabling themes is
the same as downloading and enabling
| | 00:04 | modules, to a point.
| | 00:06 | I will describe the
differences in how to mitigate them.
| | 00:09 | First, let's list the themes that are
currently available, drush pml --type=theme.
| | 00:17 | There are four themes and
two of them are enabled.
| | 00:20 | However, Drupal themes have some
differences for modules, in particular there
| | 00:24 | are default themes which are used
unless otherwise specified and admin themes
| | 00:29 | which are used on admin pages only.
| | 00:31 | The project manage list
doesn't show this information.
| | 00:34 | These settings are stored
as Drupel site variables.
| | 00:37 | In Drupal development, there are two
functions, variable_get and variable_set, that
| | 00:42 | are used to retrieve and save settings
and other one-off types of information
| | 00:46 | from hardcoded settings in
settings.php and from the database.
| | 00:51 | Drush provides an interface to these
site variables with a variable_get and
| | 00:54 | variable_set commands
aliased as vget and vset.
| | 00:58 | I will start with variable_get, help vget.
| | 01:02 | vget takes one argument, the
partial or complete name of the variable.
| | 01:07 | If ommited, vget will return all variables.
| | 01:11 | The next bit isn't explicitly
documented so I will demonstrate it for you.
| | 01:15 | The default theme is saved in
a variable named theme_default.
| | 01:20 | Let's get the value of theme_default now:
| | 01:23 | drush vget theme_default.
| | 01:27 | Currently the default theme is bartik.
| | 01:29 | I am going to switch to the garland theme
which is included in core but not enabled.
| | 01:34 | First, I'll enable garland using project
manage command enable garland, drush -y en garland.
| | 01:42 | Then, I will set the variable using
the vset command, drush help vset.
| | 01:47 | Variable set has a lot of options, but
in the simplest mode it can just set a
| | 01:53 | given value to a particular named variable name.
| | 01:56 | So in this case, drush vset
theme_default, to "garland".
| | 02:04 | Theme default is now set to garland.
| | 02:06 | Verify this by using vget again: drush
vget theme_default, and it's set to garland.
| | 02:16 | Switch back to the browser and go to the
homepage and reload, make sure that you
| | 02:23 | can see the difference.
| | 02:24 | As the administrative theme is
distinct from the theme default there is a
| | 02:28 | different variable, going back to the
terminal use vget again, but this time on
| | 02:33 | the variable admin_theme,
drush vget admin_theme.
| | 02:40 | This time two variables will be shown,
by default vget searches for variables
| | 02:44 | that contain the search term.
| | 02:46 | To be more specific pass an
additional option called Exact, which will only
| | 02:51 | match the exact variable:
| | 02:52 | drush vget admin_theme --exact.
| | 02:59 | This is functional but what if I
wanted to change to a different admin
| | 03:02 | theme such as Rubik.
| | 03:03 | Three steps are required, first,
download the Rubik theme which also has a soft
| | 03:08 | dependency with the Tao theme.
| | 03:10 | Usually, dependencies are auto
enabled, but in this case it hasn't been
| | 03:14 | explicitly defined by the theme author
so it will need to be explicitly
| | 03:18 | downloaded and enabled:
| | 03:20 | drush dl rubik tao.
| | 03:25 | Next, enable the Rubik in Tao themes.
| | 03:28 | So, drush -y en rubik tao.
| | 03:34 | Finally, set Rubik as the admin theme.
| | 03:37 | If there was one exact match, variable
set will just set that one variable and
| | 03:42 | will not set the additional variables.
| | 03:44 | If there is not an exact match, like
when a variable has never been set, then the
| | 03:48 | exact option will allow the variable to be set.
| | 03:52 | So in this case I'll just type,
drush vset admin_theme rubik.
| | 04:01 | Return to the browser and navigate
to the Configuration page to see the
| | 04:05 | difference, which is very striking.
| | 04:08 | I'm going to put the admin
theme now back to default:
| | 04:11 | drush reset admin_theme seven.
| | 04:16 | Going back to the browser and refreshing.
| | 04:20 | And it's back to normal.
| | 04:21 | The vget command can be very useful for
tracking changes over time on UNIX like systems.
| | 04:26 | On the configuration
page go to site information.
| | 04:31 | Now we will switch back to
the terminal for just a moment.
| | 04:34 | By default, variable get
will return all variables.
| | 04:37 | I will write every variable in this
site to a flat file before I make a change
| | 04:42 | then do a second file and compare the
differences to see what was written.
| | 04:45 | This can be useful when storing
variables and code, either in settings.php or
| | 04:51 | when explicitly setting a
variable in a hook update.
| | 04:54 | I'm going to give the command "drush vget"
and write the output to a file named "before".
| | 05:03 | Next, go to the browser and set the
site name to Drush and the slogan to "a
| | 05:08 | command line shell and
scripting interface for Drupal".
| | 05:14 | Save the changes then
navigate to the site home page.
| | 05:20 | The new site name and slogan are shown.
| | 05:22 | Return to the terminal then dump
the variables into a file named "after":
| | 05:27 | drush vget to after.
| | 05:32 | Finally, use the diff command to show the
difference between the two files: diff before after.
| | 05:39 | There are two symbols the greater
than symbol indicates that something was
| | 05:42 | written and the less than symbol
indicates that something is removed.
| | 05:46 | With this view, I can see that not only
were the variables, site name and site
| | 05:50 | slogan, written but so are
some other values as well.
| | 05:53 | If I wanted to hardcode these
variables in the settings.php I can use another
| | 05:58 | feature of variable get, the pipe option.
| | 06:01 | In this context, I will render
the variables as a line of PHP:
| | 06:05 | drush vget site_name --pipe.
| | 06:11 | And, drush vget site slogan --pipe.
| | 06:18 | I can take these two lines and copy
them into settings.php, renaming the dollar
| | 06:23 | $variables to dollar sign $conf to
force the site name and slogan to be
| | 06:27 | whatever I specified.
| | 06:29 | For more information on defining
variables in the site's settings.php conf
| | 06:33 | array, see drupal.org/node/1525472.
| | 06:41 | I have demonstrated how to enable,
disable, and set the site default and admin
| | 06:45 | team without using the site interface.
| | 06:47 | This can be extremely useful, especially
when a mistake was made when developing
| | 06:51 | a theme and a failsafe is needed.
| | 06:53 | In the next segment, I will demonstrate
how to manage users, including creating
| | 06:57 | and disabling users, then changing passwords.
| | Collapse this transcript |
| User management| 00:00 | Managing users is an everyday task
for many Drupal site administrators.
| | 00:04 | So Drush provides an interface for that as well.
| | 00:07 | Let's start with getting
information about a user.
| | 00:09 | drush help user information.
| | 00:14 | The User information command, aliased as
uinf, displays information about a user.
| | 00:20 | The argument passed as a comma separated
list of usernames UIDs and email addresses.
| | 00:26 | Right now there's only one user on the
system, the admin user that was created
| | 00:30 | during site installation.
| | 00:32 | So I will get information
about that user, drush uinf admin.
| | 00:38 | The user id, name, mail,
roles and status are displayed.
| | 00:44 | Additional information can be
shown using the option --full.
| | 00:50 | The full view is a bit more extreme
and is useful for low-level debugging.
| | 00:54 | For example, the password is shown in a sense.
| | 01:00 | It's the hashed password not the
actual password which in this case is admin.
| | 01:04 | A common problem is that users are
constantly forgetting their passwords.
| | 01:08 | Drupal's Password API hashes passwords
using a secured stretched hash, meaning
| | 01:15 | that it's both salted and hashed
multiple times to increase the complexity of
| | 01:19 | the stored password to reduce
the risk of brute force decryption.
| | 01:22 | Due to these privacy and security
restrictions this means the passwords cannot
| | 01:26 | be read even by administrators, despite
whatever a client may request or demand.
| | 01:32 | Instead, Drupal's administrative
interface provides a mechanism that allows
| | 01:36 | users to request one time Logins and allows
administrators to arbitrarily set a user's password.
| | 01:43 | I will demonstrate both of
these techniques using Drush.
| | 01:46 | First, setting passwords manually,
this is useful when working on a local
| | 01:50 | duplicated copy of a client site and
the particular password is not known.
| | 01:55 | drush user password, or just aliased
as upwd sets, the password for a user.
| | 02:03 | The only argument is the username
and there is a required option, yes
| | 02:06 | that's oxymoronic but it is
required names password containing the new
| | 02:10 | password in plain text.
| | 02:12 | So I am going to set password for admin
with the required option, password =hello.
| | 02:20 | I can also put quotes around the password if
the target password contains quotes or spaces.
| | 02:25 | "Hello" isn't a good password so set it
back to admin which is still insecure but
| | 02:29 | easy to remember in a development environment.
| | 02:32 | drush upwd admin password=admin.
| | 02:38 | The second technique, generates a one-
time login URL which can be given to a user.
| | 02:44 | This is preferable to setting a password
for user as administrators should never
| | 02:48 | know a users password.
| | 02:50 | The user login command aliased uli will
generate these log in URLs for a given
| | 02:56 | user, drush uli admin.
| | 03:01 | Depending on the way the site was set
up Drush may not know the actual site URL
| | 03:05 | and out-of-the-box the URL is not set
which is why it's showing as http default.
| | 03:11 | Always look at the output before
blindly passing it on to the user.
| | 03:15 | These generated one time log-ins are
not emailed by Drush, the administrator
| | 03:19 | needs to manually use these
URLs in whatever way they see fit.
| | 03:23 | Drush user interaction goes beyond
passwords, users can be created, blocked and
| | 03:28 | unblocked and even canceled.
| | 03:30 | I will start by creating a test user
using the User Create command aliased as
| | 03:35 | ucrt, drush help ucrt.
| | 03:39 | User create takes an argument
containing the username followed by the two
| | 03:43 | options with a mail and password.
| | 03:46 | drush ucrt test mail="test@
example.com" and password=test.
| | 03:58 | Now if I get user information on the
test user, drush uinf test, I will see the
| | 04:04 | same information as I was
shown when I created the user.
| | 04:07 | While user create is used on one user
at a time the block and unblock commands
| | 04:13 | will work on multiple users at a time.
| | 04:15 | The user list can be separated by
commas and the users can be specified by
| | 04:19 | UID, email or username.
| | 04:22 | Be careful with this command as
there is no prompt and Drush will respect
| | 04:26 | whatever email preferences that have
been set on the site such as not notifying
| | 04:30 | on blocks and sending an
activation email when unblocking.
| | 04:33 | To block a user I would use the user
block command aliased as ublk followed by
| | 04:39 | an argument containing the users.
| | 04:41 | drush ublk, let's get the help for that,
I will block both the admin user by UID
| | 04:48 | and the test user, by user name.
| | 04:53 | Notice that I am not using the
additional options specifying that I'm using a
| | 04:57 | UID or username, Drush will do the work for me.
| | 05:01 | Verify that the admin user is blocked
with the command line. drush uinf 1.
| | 05:08 | Then, return to the browser and
attempt to navigate to a page.
| | 05:15 | Being blocked, the admin user is kicked out.
| | 05:20 | The user status is shown as blocked,
given that it's easy to block someone
| | 05:24 | without a prompt the block can be also
similarly removed, user unblock operates
| | 05:29 | in a very similar manner and
has a similar alias, uublk.
| | 05:34 | I will leave the test
user blocked, drush uublk 1.
| | 05:41 | I'm shown an error regarding e-mail
as my local development environment was
| | 05:44 | not set up to send email at this time
and by default Drupal will send an email
| | 05:49 | upon account activation.
| | 05:51 | Finally, if I want to gracefully get rid
of an account I can cancel a user using
| | 05:55 | the user cancel command.
| | 05:57 | Ironically aliased as ucan, drush help ucan.
| | 06:03 | By default all contents owned
by the user reverts to UID 1.
| | 06:07 | I will cancel the test
account now as I'm done with it.
| | 06:11 | User cancel takes one argument a
single user to cancel, an optional argument
| | 06:16 | will just arbitrarily delete all content
created by the user as well, drush ucan
| | 06:21 | test delete content.
| | 06:25 | Following a prompt the user in
all their content will be deleted.
| | 06:29 | Throughout this chapter I've covered
a number of core functionalities for
| | 06:34 | everyday operation, including: site
installation and introspection for building a
| | 06:38 | site from the ground up and
getting a high-level perspective of site
| | 06:41 | configuration, listing and managing
modules which is useful for downloading,
| | 06:46 | enabling and disabling modules, theme
and variable management using variable
| | 06:51 | set and get in user management including
creation, blocking and unblocking and cancellation.
| | 06:58 | In the next chapter, I will
discuss more advanced and low-level site
| | 07:02 | management techniques
| | Collapse this transcript |
|
|
3. Site Management TechniquesControlling cache and cron| 00:00 | Drupal is like an engine, a complex
system with many moving parts working in
| | 00:04 | conjunction with one-another to deliver power.
| | 00:07 | By opening the metaphorical hood and
working directly with the engine, using the
| | 00:11 | right tool, a properly equipped
site administrator can quickly perform
| | 00:15 | potentially cumbersome tasks with ease.
| | 00:18 | This chapter will cover a number of
tools and techniques useful for performing
| | 00:22 | low-level operations on a Drupal site.
| | 00:24 | Out of the box, Drupal provides a
number of caching mechanisms to improve site
| | 00:29 | performance and avoid heavy or repetitive tasks.
| | 00:32 | For example, both the menus and the
blocks are extensively cached and Drupal
| | 00:38 | gives precedence to these caches
over configuration stored in code.
| | 00:42 | This can present a problem when
developing modules as code changes will not be
| | 00:46 | immediately shown on a site.
| | 00:48 | Additionally, when transferring a
site between hosting environments, cache
| | 00:52 | settings for file locations and paths
can cause problems when attempting to
| | 00:55 | access the transferred site without
clearing the cache which tends to result in
| | 00:59 | an incomplete or broken site.
| | 01:02 | Log back into the site: admin, admin.
| | 01:07 | Drupal provides an interface for
clearing all caches deep within the Admin menu.
| | 01:11 | If you go to Configuration>Performance,
you see a button, Clear all caches.
| | 01:18 | It's time-consuming to wade through the
menus to find this button and sometimes
| | 01:21 | there's no need to clear every cache,
only a certain cache such as the menu or
| | 01:26 | aggregated and compressed CSS files.
| | 01:28 | Drush provides a mechanism to handle
these issues with the Cache Clear command
| | 01:32 | aliased as cc, drush cc --help.
| | 01:38 | The Cache Clear command takes an optional
argument, the name of the cache to clear.
| | 01:42 | If the argument is omitted, Drush will
give a choice of the available caches,
| | 01:46 | type: drush cc, and press
Enter without any arguments.
| | 01:51 | All will do the same as clear all
caches and often this is used as a magic
| | 01:55 | bullet to fix strange caching issues.
| | 01:58 | Do be cautious however, as this will
degrade performance for the next few page
| | 02:01 | views until the caches are regenerated.
| | 02:04 | Press 1 to clear all caches.
| | 02:06 | The same command can be executed
by specifying "all" as the argument.
| | 02:10 | I use this often enough that it's
practically muscle memory, drush cc all.
| | 02:16 | The second cache to clear, drush, is
specific to commands used by Drush.
| | 02:21 | If new Drush functionality was
installed in the module, but Drush does not
| | 02:24 | recognize the command when
accessed, clear the drush cache.
| | 02:28 | I personally have not had to use
the clear drush cache very often.
| | 02:32 | Theme registry is useful when
developing themes and adding a new template.
| | 02:37 | The rest of the options are
straightforward, the menu is the menu cache; css-js
| | 02:41 | clears the aggregated in cache style
sheets and JavaScript files; block clears
| | 02:46 | the block cache, and so forth.
| | 02:48 | To explicitly clear one of these
caches either use drush cc, press Enter and
| | 02:52 | type the number of the selection, or
give the machine name of the cache to clear
| | 02:56 | such as: drush cc menu.
| | 03:00 | Caches typically have an
expiration date and therefore have a
| | 03:02 | chronological context.
| | 03:04 | With that in mind, caches are not the only
time-based mechanism that executes in Drupal.
| | 03:10 | A cron job is a time-based event
that executes some regularly scheduled
| | 03:15 | operation such as: checking site updates,
indexing site content with the search
| | 03:20 | module, importing site content
from a third-party, and so forth.
| | 03:24 | In Drupal 6, cron execution needed
to be set up manually or leverage the
| | 03:28 | contributed module poormanscron, which
triggered these time-based events after a
| | 03:33 | regular page load from a visitor.
| | 03:35 | poormanscron was included in Drupal 7
Core eliminating the need for additional
| | 03:40 | configuration or module installation.
| | 03:42 | However, regardless of the mechanism
that triggers them, sometimes it's useful
| | 03:46 | to manually execute these time-based events.
| | 03:49 | The drush command cron, which has no
alias, runs all cron hooks for every active
| | 03:57 | module in a given site.
| | 03:58 | The drush cron command takes no
arguments or options: drush cron.
| | 04:04 | Upon completion, feedback is given.
| | 04:06 | On the topic of feedback, the Drupal
logging system contains a vast wealth of
| | 04:10 | feedback and debugging
information from various side events.
| | Collapse this transcript |
| Reading the "watchdog" logs| 00:00 | The term 'watchdog' is a bit of a Drupal
anachronism, as it refers to a
| | 00:05 | deprecated module for monitoring a
Drupal site and recording system events for
| | 00:09 | review and debugging.
| | 00:11 | However, the name persists in both
function and table names individual triggered
| | 00:15 | by the word 'watchdog' tends
to get the message across.
| | 00:18 | Starting in Drupal 6, Drupal defaults
to using the dblog module for logging to
| | 00:23 | the watchdog database table and
these logs are visible in the site.
| | 00:27 | From the browser, go to
Reports, then Recent log messages.
| | 00:32 | There are a number of filters that
can be applied in a single button to
| | 00:36 | clear all log messages.
| | 00:38 | It's functional, but it's a bit cumbersome.
| | 00:42 | Switching back to the commands line, I will use
Drush to retrieve and search for log messages.
| | 00:47 | There are three commands relating to
watchdog, the first, "watchdog list" aliased
| | 00:52 | as wd-list shows a list of available
message types and severity levels in a very
| | 01:00 | similar way to the select
list from the browser interface.
| | 01:03 | And it will prompt the user for a
choice to show messages, drush wd-list.
| | 01:09 | Type "1" to see a list of access denied messages.
| | 01:13 | Next, the proverbial
firehose, watchdog show, drush ws.
| | 01:19 | It's a much more powerful tool for
displaying messages and it has a number of
| | 01:23 | useful options, drush ws --help.
| | 01:27 | A single argument allows the operator
to specify a particular watchdog log id
| | 01:32 | for additional details.
| | 01:34 | If emitted, watchdog show will
default to the last 10 messages.
| | 01:38 | This option can be combined to
provide strict controls over what is shown.
| | 01:42 | For example, drush ws --count =5 --type=system.
| | 01:49 | This will show five messages
which in this case are just info.
| | 01:53 | Combine the type and severities shown
from the watchdog list with the options in
| | 01:57 | watchdog show and the potential
power of this tool can be realized.
| | 02:00 | One of the options, tail, is an easily
overlooked, but extremely useful utility
| | 02:06 | that will continuously show
watchdog messages as they are generated in
| | 02:09 | real-time until interrupted.
| | 02:11 | For example, I will launch it for failed
logins, drush ws --type="access denied" --tail.
| | 02:24 | Keeping the council window open, I will
open a browser, log out, and attempt to
| | 02:30 | access a page that I do not
have access to, such as /admin.
| | 02:36 | Notice the new log entry shown in
watchdog show with a type access denied and
| | 02:41 | the message containing the URL
that was attempted to be accessed.
| | 02:44 | To break out of this view, press
Ctrl+C.Reviewing logs can turn up
| | 02:49 | important items that may have gone
unnoticed such as the need to update
| | 02:52 | Drupal or a module.
| | Collapse this transcript |
| Updating Drupal and modules| 00:00 | Keeping Drupal in the various
modules up-to-date can be a pain.
| | 00:03 | In Drupal 6, downloading and
extracting individual modules was cumbersome and
| | 00:08 | repetitive in a very manual process.
| | 00:11 | In Drupal 7, module updates were
streamlined through the browser interface, but
| | 00:15 | it still took a number of steps.
| | 00:17 | To make this task easier, Drush
provides some utilities that will update both
| | 00:21 | core and contributed modules.
| | 00:23 | To demonstrate these utilities, I'm
going to quickly set up an intentionally
| | 00:27 | out-of-date site using Drush
package manager download and site install.
| | 00:32 | Change directory out of the siteroot.
| | 00:36 | Next, download an older version of Drupal,
I'll use Drupal 7.15, so, "drush dl drupal-7.15".
| | 00:48 | Change directory to "drupal-7.15" and
then we'll perform a site install again.
| | 00:54 | This is going to overwrite the
database used by Drupal-7.17.
| | 00:59 | If you're sure that there's nothing to
lose, say yes to the prompt, so, drush si
| | 01:04 | --db-url=mysql://root:root@127.0.0.1:
3306/drush, and then, account-pass=admin.
| | 01:26 | If you're sure, say yes.
| | 01:30 | Next, download an old version of the Devel
module, in this case 1.2, drush dl devel-1.2.
| | 01:36 | Enable devel in one command
without saying yes, drush -y en devel.
| | 01:51 | Now that an out-of-date version of
Drupal has been installed and an out-of-date
| | 01:54 | module has been enabled, execute the cron;
| | 01:57 | this will among other things
check for updates, drush cron.
| | 02:04 | Notice that this time cron
attempted to send an email.
| | 02:07 | This is because Drupal is not up-to-date.
| | 02:10 | Open a browser and navigate to Druple-7.
15 and log in using the admin username
| | 02:19 | and password, navigate to Reports>Status report.
| | 02:31 | The Drupal core update status is not
secure, out-of-date and Module and theme
| | 02:37 | update status is also out-of-date.
| | 02:40 | The devel module can be updated through
the web interface, but when I click on
| | 02:43 | information about the Drupal update,
I see that this is a manual update.
| | 02:50 | Normally, this would be a big
production needing many steps, but Drush allows
| | 02:54 | everything to be done in one Command.
| | 02:57 | It's best practice to back up the
siteroot and database before doing an
| | 03:00 | arbitrary update, as usually module
and core updates go smoothly, but there's
| | 03:05 | always the edge case that can give
you a in capital letters a Very Bad Day,
| | 03:09 | if you don't back up.
| | 03:10 | Out of the box and by default,
project manager update will also back up the
| | 03:15 | replaced code automatically, but not
the database, I'll go into greater detail
| | 03:20 | about manually archiving and
restoring sites in the next segment.
| | 03:23 | For now, since this is a freshly installed
demonstration site, it's safe to proceed.
| | 03:28 | The Drush command pm-update code
aliased as "drush upc" is a powerful tool;
| | 03:37 | upc will display the currently
available information for Drupal core and all
| | 03:41 | enabled projects that allow updating
to the latest recommended releases.
| | 03:45 | I look at the help shows the
scope of all the options available.
| | 03:52 | If I wanted to exclude core from the
updates or only apply security updates,
| | 03:57 | there are options that are
available for that level of granularity.
| | 04:01 | For now, I'll stick with an arbitrary update.
| | 04:05 | For database updates the manual
command, drush pm-updatedb, which is aliased as
| | 04:13 | updb, replaces the need to
navigate to update.php with the browser.
| | 04:21 | While both of these commands are
available separately, they've been combined
| | 04:25 | for convenience into one mega command,
project manager update, aliased as "up", drush up.
| | 04:32 | Following the update,
database updates will be applied.
| | 04:36 | Each step provides an interactive yes
or no option which can be overridden with
| | 04:40 | -y like other commands, drush up.
| | 04:45 | Information about all the pending
updates and the potential consequences of
| | 04:49 | proceeding are shown.
| | 04:50 | Am I sure that I wish to continue? Yes.
| | 04:55 | Do I really want to continue
with updating Drupal core? Yes.
| | 05:00 | This pause is the downloading
and extraction of the updates.
| | 05:06 | Additionally, all database updates are
shown and the option to continue is given.
| | 05:11 | drush up, automatically downloads,
installs both the core upgrade and module
| | 05:15 | upgrade, then applies the
pending database update.
| | 05:19 | Next, execute cron to
check for updates, drush cron.
| | 05:25 | Navigate back to the status report,
everything is now shown as up-to-date.
| | 05:34 | Now in a production site, additional
care should be taken to back up both the
| | 05:38 | database and files of a site.
| | 05:40 | Drush provides convenient
utilities to archive and restore a site.
| | Collapse this transcript |
| Archiving and restoring sites| 00:00 | To give context for archiving and
restoring sites, I will first describe the
| | 00:04 | three primary structural
components in a Drupal site.
| | 00:07 | The database, which stores all the site
content; the codebase which contains all
| | 00:12 | the executable scripts such as
Drupal core, modules, and themes;
| | 00:16 | Drupal specific hosts typically store
the codebase in a revision controlled
| | 00:19 | repository; and files, which contain
generated and uploaded files such as
| | 00:24 | images, icons, and other media.
| | 00:27 | By default, these files reside in
the same web root as the codebase.
| | 00:31 | Before performing updates or making
major changes to a site, it's best practice
| | 00:35 | to back up the site first.
| | 00:37 | I'll demonstrate how to back up and
restore the database, then the entire site
| | 00:41 | including the codebase and files.
| | 00:44 | Drush provides a built-in utility
for creating a database dump known as
| | 00:47 | sql-dump: drush sql-dump --help.
| | 00:55 | This exports a Drupal site database
as SQL using MySQL dump or equivalent.
| | 01:01 | As of this writing, this command has known
compatibility issues with Drush for Windows.
| | 01:05 | sql-dump takes no arguments, only parameters.
| | 01:09 | By default, sql-dump exports
the entire schema and data.
| | 01:13 | Unless otherwise specified, the
database dump is placed in the drush-backups
| | 01:18 | directory in the user's home directory.
| | 01:21 | Typically, it makes sense to
specify the location of the file.
| | 01:25 | I'm going to back up the database to
the directory above the Drupal root,
| | 01:28 | something to keep in mind.
| | 01:30 | Drush uses relative file locations
to the Drupal root or absolute paths.
| | 01:34 | Using tilde (~) to indicate
a home folder will not work.
| | 01:38 | I prefer to add a date to the file
name to give context, and I'll use generic
| | 01:42 | placeholders for demonstration, drush sql
-dump, and then I'm going to specify the
| | 01:49 | result-file =, then back one directory,
backup-YYYY for the year, month (MM),
| | 01:58 | and day (DD) dot sql.
| | 02:01 | Now that the database dump has been
created, I'm going to import the contents.
| | 02:05 | Before I can do that, I need to get rid
of all the tables in the Drupal database.
| | 02:09 | If I don't, then very bad things
will happen and the site will be broken.
| | 02:13 | I'm going to use the command: drush sql-drop.
| | 02:17 | First, I'll show the help.
| | 02:19 | Only use this command if you know
exactly what you're doing, as this is a
| | 02:22 | destructive command and will wipe
out all the tables in the site's
| | 02:25 | database, drush sql-drop.
| | 02:29 | A prompt will be given, am I sure? Yes.
| | 02:32 | Now that the contents of the database
have been completely removed, I will now
| | 02:36 | import the site dump created previously using
drush sql query aliased as sqlq: drush sqlq.
| | 02:43 | SQL query executes a query
against the site database.
| | 02:50 | I will specify the location of the
database dump using the option file which
| | 02:54 | takes the relative path to the Drupal root.
| | 02:56 | This command does not prompt for
confirmation, so be aware of what you're
| | 02:59 | doing: drush sqlq --file=../backup, and then
the name of the file that you wish to restore.
| | 03:12 | No messages are shown unless there's a problem.
| | 03:15 | Verify that the site has been properly
restored by returning to the browser and
| | 03:18 | reloading to see a working site.
| | 03:25 | Next, I will archive and
restore the entire site.
| | 03:28 | The command archive dump, aliased as
ard, backs up a site code, files, and
| | 03:36 | database into a single tar file.
| | 03:38 | Archive dump takes one optional
argument, the sites to be dumped.
| | 03:42 | This is only useful with multi-sites.
| | 03:45 | I'm going to specify the destination
of the archives as the parent directory.
| | 03:49 | As the resulting file is a tar archive
I will need to specify .tar as the file
| | 03:54 | extension. Similar to the sql-dump, I
prefer to name the archives with a date
| | 03:58 | for clear distinction: drush ard --
destination=../backup-YYYY-MM-DD.tar.
| | 04:12 | When complete, Drupal will show the site
status and tell where the archive was created.
| | 04:16 | I'm going to drop the database now to
ensure that everything is removed, drush
| | 04:21 | sql-drop, am I sure? Yes.
| | 04:24 | Change directory back to the parent
directory, then remove the archived site:
| | 04:32 | rm -Rf drupal-7.15.
| | 04:38 | Let's take a look at the archived contents.
| | 04:41 | Normally, there is no need to do this,
but it's useful to know what's inside.
| | 04:45 | Opening the sandbox folder, I'm going
to use double-click on the tar file to
| | 04:50 | look at the contents.
| | 04:53 | Inside, there is a folder containing
the siteroot, a database dump named after
| | 04:57 | the database used, and a manifest.ini,
which describes the context from which
| | 05:01 | the archive was created from.
| | 05:03 | Looking in the sandbox directory, I'll
also remove the drupal-7.17 directory:
| | 05:09 | rm -Rf drupal-7.17.
| | 05:14 | Between dropping the table and removing
these folders everything has been removed.
| | 05:18 | Remember to leave the backup archive.
| | 05:21 | The Drush command, "drush archive
restore" aliased as arr, expands a site archive
| | 05:27 | into a Drupal website, drush arr -help.
| | 05:32 | Archive restore takes two arguments:
| | 05:36 | the first is the path to the file
containing the archive and the second optional
| | 05:40 | argument is the name of the sites
within the archive to be extracted.
| | 05:43 | Again, this is only useful for multi-sites.
| | 05:44 | An option for destination allows me to
specify where the archive is to be extracted;
| | 05:52 | the default is the current working directory.
| | 05:56 | I'm going to restore the site from the archive.
| | 05:58 | Since I changed directories, the path
to the archive is slightly different:
| | 06:02 | drush arr backup.tar.
| | 06:09 | Open the browser and refresh the site.
| | 06:15 | The site has been fully restored.
| | 06:16 | It's a best practice to clear the
cache after restoring from a backup,
| | 06:20 | especially if the archive was restored
in a different environment from which it
| | 06:23 | was created, drush cc all.
| | 06:28 | In this chapter, I've demonstrated a
number of everyday activities that I use on
| | 06:32 | a regular basis including controlling
the cache and cron, reading the watchdog
| | 06:37 | logs, updating Drupal and modules,
and archiving and restoring sites.
| | 06:43 | One question remains, where to go from here?
| | Collapse this transcript |
|
|
ConclusionWhere to go from here| 00:00 | Throughout this course, I've provided
context for what Drush is and how it can
| | 00:04 | be used on a daily basis to
simplify Drupal site administration.
| | 00:08 | I've covered a large number of commands and
command aliases, and there's a lot to remember.
| | 00:13 | To help, I've written a quick reference
document and provided it as a free download.
| | 00:18 | The Quick Reference includes all of
the commands covered in this course and
| | 00:21 | several useful examples.
| | 00:23 | Feel free to print out the Quick Reference
and give it to anyone who may find it useful.
| | 00:28 | I've not covered every
command available in Drush.
| | 00:31 | There are several dozen commands
available in total, many of which have their
| | 00:34 | own arguments and options.
| | 00:35 | I'll share a technique I used to
quickly search for Drush commands.
| | 00:39 | I pipe the output of Drush into grep
case-insensitive and give it a word
| | 00:43 | that I'm looking for.
| | 00:44 | For example, if I want to search commands
for download, I would type the following:
| | 00:49 | drush | grep -i download.
| | 00:56 | Drush also includes additional in-depth
documentation beyond what is shown in the help files.
| | 01:02 | To see a list of all topics available
type "drush topic", type the number of the
| | 01:08 | topic that you wish to see,
or press zero to cancel.
| | 01:13 | Downloading particular versions of Drupal,
modules and themes, applying patches,
| | 01:18 | installing libraries, and including
custom functionality can be an arduous
| | 01:22 | process if done manually.
| | 01:24 | A formerly contributed project,
Drush make is now available in Drush and
| | 01:29 | allows for the use of a standardized script,
known as a Make file to create a Drupal code base.
| | 01:34 | For more information on the
Make command, type "drush help make".
| | 01:41 | Drush make is very useful when creating
a site-building process in conjunction
| | 01:45 | with the continuous
integration or delivery process.
| | 01:48 | Drush also has the ability to
securely connect to remote sites via SSH and
| | 01:53 | perform commands remotely, storing
connection and site information in local
| | 01:56 | configuration files.
| | 01:59 | The end result is that multiple sites can be
aliased and acted on as if they were local.
| | 02:03 | Drupal site aliases are also provided
by several commercial Drupal hosts which
| | 02:07 | facilitates remote administration.
| | 02:10 | For more information, look at "drush site
-alias --help", and "drush docs-aliases",
| | 02:18 | and press Q to exit.
| | Collapse this transcript |
| Goodbye| 00:00 | Drush is a fantastic utility for
managing Drupal site installations, and I use
| | 00:04 | it daily for both
administration and development.
| | 00:07 | By providing a guided introduction
into this richly populated world of
| | 00:10 | commands, I hope to have given enough
context and examples to increase your
| | 00:14 | comfort level enough to discover new
functionality and to leverage Drush to its fullest abilities.
| | 00:19 | I greatly enjoyed writing and recording
this course and I appreciate your time.
| | 00:24 | Please take a moment to provide
some feedback on the course homepage.
| | 00:27 | Thanks for watching!
| | Collapse this transcript |
|
|
