All Posts in drush

September 13, 2012 - Comments Off on Drush de Jour: The Case of the External Links and Broken JS

Drush de Jour: The Case of the External Links and Broken JS

The External Links module for Drupal is a nice, unobtrusive addition that adds an arrow icon next to off-site links to let users know the link will take them to a new site and open a new browser window. There is also a cool feature to include or exclude links based on regular expressions. Wheeeee!!!!!

Be warned, however, that you may enter a valid regular expression that could cause the javascript on your site to take a header. You will immediately know this is the case when you save your changes and the fieldset for the pattern matching is no longer collapsible. What happens is that the regular expression you entered is not validated against potential conflicts in the javascript that parses it on rendering. We had this issue when we tried to add an inclusion rule for PDF's. We wanted all PDF's hosted on the site to open a new window, despite the fact that they were 'internal'. Seems easy, add a wildcard and the extension and call it a day....

*.pdf

That didn't work. This isn't command line DOS, or *nix- add an escape to look for the period. It also broke Javascript on the site!

Drush to the rescue.

This went from a quick module addition to a murder mystery, minus the murder. Well, when clients aren't happy it might. Here's how we diagnosed the issue, which turned out to be fairly simple, but the troubleshooting process is important.
First off, since we work in a development site no one was going to be adversely affected. Next we know what was going on at the time things broke. I was the only one working on the site at the time so that narrowed it down to me and the changes I was making. If you have multiple developers working on a site concurrently, then version control, and backups are paramount.

So, we know I broke the site, and it was something to do with the External Links and specifically the regular expression I had just tried to save. This most likely means that the module saves data to the database in a custom table, or as a site variable. Drush can help inspect the second route very quickly-

% drush vget extlink
extlink_alert: 0
extlink_alert_text: "This link will take you to an external web site. We are not responsible for their content."
extlink_class: "ext"
extlink_exclude: ""
extlink_include: "*.pdf"
extlink_mailto_class: "mailto"
extlink_subdomains: 1
extlink_target: "_blank"

There it is! If no variables were found, then the next step is to check out the .install file for the offending module and look for a schema hook. But, we lucked out and can move along to spewing poorly formed regular expressions.

% drush vdel extlink_include and refresh, and we're back in business.
*.pdf

That didn't work, duh. This must be a 'javascript supported' pattern as the documentation says.

.*.pdf.

And now PDF's will open in a new window.

Links:

External Links

The Drush de Jour brings you the latest and possibly greatest bits of drush wisdom we use for developing and maintaining our Drupal sites.

 

Published by: chazcheadle in The Programming Mechanism
Tags: ,

July 31, 2012 - Comments Off on Drush de Jour: Drush aliases, aka… Drush aliases

Drush de Jour: Drush aliases, aka… Drush aliases

The complexity of developing and maintaining multiple Drupal sites can grow like kudzu. Keeping on top of them is important not only for version control of your codebase but also for streamlining development to production site transitions. Until now we've just shown examples of how to drush it up nice with a single site- go to that site's directory, type drush, be happy. But when you have multiple sites on one or more servers that you need to interact with, Drush can help make your life easier.

Instead of writing scripts to 'cd' here, or 'cd' there to get into the right Drupal installation directory to perform a Drush task, you can create aliases for each site that work like nicknames. For example, we have a 'dev' and a 'prod' site on a server. Instead of changing back and forth between the directories to Drushify, we create aliases for them and can call them from anywhere.

First, create a new file in ~/.drush called <aliasname>.alias.drushrc.php and put this code in it:

<?php
$aliases['prod'] = array(
  'root' => '/var/www/vhosts/themechanism.com',
  'uri' => 'www.themechanism.com',
  );
?>

Now, from anywhere on the system, you can call Drush and perform commands on your site.

$ drush @prod status

You can set an alias for a remote site, copy files between prod and dev, sql-sync your database between sites, etc. etc.

Further Drush alias examples can be found in drush/examples/example.aliases.drushrc.php or wherever you installed drush.

 

The Drush de Jour brings you the latest and possibly greatest bits of drush wisdom we use for developing and maintaining our Drupal sites.

Published by: chazcheadle in The Programming Mechanism
Tags: ,

July 25, 2012 - Comments Off on Drush de Jour: Module machinations

Drush de Jour: Module machinations

If you are running one Drupal site, or multiple sites, or multiple muiti-site installations, you will at some point be wrangling modules. Drush can help you list, install, and uninstall modules.

% drush pml

If you want to see a specific module you can filter the result through grep.

%drush pml | grep <pattern>

e.g., %drush pml | grep token will show you modules with 'token' in the name.

 

You can also install, enable and disable modules if you need to debug or test.

Download a module:

%drush dl <module name>

 

Enable the module:

%drush en <module name>

 

Disable the module

%drush dis <module name>

 

If you need to fully uninstall a module, which will also run any hook_uninstall() in a module which can be handy for debugging.

Uninstall the module:

%drush pm-uninstall <module name>

 

You can script these commands as well with aliases, allowing you to enable/disable modules across multiple sites.

The Drush de Jour brings you the latest and possibly greatest bits of drush wisdom we use for developing and maintaining our Drupal sites.

Published by: chazcheadle in The Programming Mechanism
Tags:

July 10, 2012 - Comments Off on Drush de Jour: Debugging Drupal modules

Drush de Jour: Debugging Drupal modules

Ever want to see what's happening behind the scenes on your Drupal site? With Drush you can do just that. Whether you are building, debugging or unintentionally breaking a Drupal site, the system logs are an invaluable way to see what is going on. Strange behavior of a module? Rules not working as expected? the logs can tell you a great deal. You can access the logs by browsing to Reports>Recent log messages (/admin/reports/dblog) and view and filter the messages. You can however get a realtime view of everything being written to the log with Drush.

% drush watchdog-show --tail

This command will let you all the messages as they come in. Keep that terminal window open and you can see users log in, rules being fired, module/php errors, and your own custom debug() and watchdog() messages. You will even see PHP warnings being thrown that may not break your site but indicate coding errors that won't be obvious by just using a browser to test.

Logic loops in modules can get complicated and sometimes you can't print out a standard debugging message to the browser with print or dpm depending on where in the rendering process your code occurs. You can however put in watchdog() statements inside your loops to let you see where your code is taking you. You could add logging to an existing module if you want to learn how it works and how you can hook into it. Just be sure to make backups if you're not working in a development environment.

All your log are belong to Drush!

The Drush de Jour brings you the latest and possibly greatest bits of drush wisdom we use for developing and maintaining our Drupal sites.

 

Published by: chazcheadle in The Programming Mechanism
Tags: ,

July 3, 2012 - Comments Off on Drush de Jour: Getting your backup back up

Drush de Jour: Getting your backup back up

Last week we saw a couple of quick ways to get a database backup of your Drupal site with Drush and the command line. Here is a drushy way to restore that backup.

% drush vset --yes maintenance_mode 1
% drush sqlc < sitebackup.sql

Login as admin and check that everything is ok (www.yoursite.com/user).

% drush vset --yes maintenance_mode 0

We're using drush's sqlc command which is taking the sitebackup.sql file and dumping it back into your database. If you omit the < and backup file you will be taken to the mysql (or whatever database backend) cli, logged in as the drupal site sql user.

Taking your site offline ensures no one is making changes to the database and is a nice way to let people know that the site is not broken. You can additionally specify a maintenance mode:

% drush vset --yes maintenance_mode_message "The website is currently being updated. Please check back in a few minutes"

Drush vset (variable-set) and its partner in crime, vget (variable-get), allow you to access the variables table from your site's database. Wonderful things can be done with these two commands, like putting the site into maintenance mode. You can also check your site's current theme:

% drush vget theme

And yes, vget will pull all variables that match the substring you enter. so 'vget theme' will pull the admin_themedefault_theme, etc.

The Drush de Jour brings you the latest and possibly greatest bits of drush wisdom we use for developing and maintaining our Drupal sites.

Published by: chazcheadle in The Programming Mechanism
Tags: ,

June 26, 2012 - Comments Off on Drush de Jour: Painless database backups for your Drupal site

Drush de Jour: Painless database backups for your Drupal site

Proceed directly to drush.
Do not pass Go.
Do not enter your site name.

When you first set up your Drupal site- install drush, the command line shell for Drupal. With drush, you can backup your db, create users, reset passwords, re-index search, start/stop migration, check logs, etc. etc. etc.

From the root of your Drupal install: (e.g., /var/www/<sitename>).

% drush archive-backup --destination=sitebackup.sql

That's it. Your entire drupal database is written to a file.

% drush sql-dump > sitebackup.sql

This method uses drush's Mysql command line interface to do a mysqldump of the site database

And if you want to be stubborn and not install drush:

mysqldump -u -p <sitedatabase> > sitebackup.sql

Links

The Drush de Jour brings you the latest and possibly greatest bits of drush wisdom we use for developing and maintaining our Drupal sites.

Published by: chazcheadle in The Programming Mechanism
Tags: , ,