Feed aggregator

Heather James, Acquia's Manager of Learning Services, has been in and around Drupal since the version 4 days. She says people new to Drupal "have an easier time at this stage coming to Drupal" than they did 6 years ago. Nonetheless, her early experiences learning how to use Drupal are still reflected by the questions people ask learning Drupal today. This, combined with her excitement about Drupal's potential and her background as an educator, motivated her to become a Drupal trainer. She is passionate about education ("When you're teaching, you're building a bridge from what people know to what they don't know.") and says about her job at Acquia, "I feel like I have a patron who helps me do the things I like to do, which is get out there and teach people."

heather_james_final.mp3

In this week's episode Addison Berry is joined by Lullabots Joe Shindelar, Andrew Berry, and Ben Chavet to talk about automating server set up with tools like Puppet and Jenkins. Building a Drupal site is only part of the equation to a complete project, and setting up the servers you will need, and making sure that you can reproduce the site set up consistently is hugely important. It becomes even more important as your projects and teams grow in size. We cover the basics of what the goal is, and what tools we use at Lullabot, and why we use them. This is a great overview of the topic for people who keep hearing these terms thrown around, and would like to understand more of what it's all about.

Podcast notes

• New videos out on Views Bulk Operations and Entity Views Attachment
• Lullabot is looking for a Sales Representative
• DrupalCamp London Introduction to Drupal workshop, March 1
• Drupal Sprint Weekend, March 9-10

Release Date: February 22, 2013 - 10:00am Album: Lullabot Podcast Length: 38:50 minutes (22.4 MB) Format: mono 44kHz 80Kbps (vbr)

Search Krumo is a very simple module that extends the Devel module to give us an enhanced developing experience. It provides the krumo() function's output - created by the Devel module - with a search box to look through the function results. And if you are a developer, you are gonna love this.

Sometimes, instead of using features, you need to be able define server settings in settings.php. This is especially useful when you do a lot of sql syncing as you only need to do a cache clear to start using the server settings defined in the file thus eliminating the need for feature reverts.

So without further due here is a quick snippet which will use settings.php $conf variables for Search API Solr server:

/**
* Implements hook_default_search_api_server().
*/
function yourmodule_default_search_api_server() {
 $items = array();

 $host = variable_get('solr_search_api_host', 'localhost');
 $port = variable_get('solr_search_api_port', '8983');
 $path = variable_get('solr_search_api_path', '\\/sorl');

 $items['solr'] = entity_import('search_api_server', '{
   "name" : "Solr server",
   "machine_name" : "solr",
   "description" : "",
   "class" : "search_api_solr_service",
   "options" : {
     "host" : "' . $host . '",
     "port" : "' . $port . '",
     "path" : "' . $path . '",
     "http_user" : "",
     "http_pass" : "",
     "excerpt" : 1,
     "retrieve_data" : 1,
     "highlight_data" : 1
   },
   "enabled" : "1",
   "rdf_mapping" : []
 }');
 
 return $items;
}

Then add the following in settings.php:

$conf['solr_search_api_host'] = 'https://my.search.server';
$conf['solr_search_api_port'] = '8080';
$conf['solr_search_api_path'] = '\\/sorl';

...and you're done :)

The Title Override module allows you to change page titles on nodes and generic pages. The module is really useful if you need to change a page title within the administration section of Drupal.

By using Title Override, you can manage simple page title changes in a single interface and avoid having glue code all over the place. That being said this module is great at handling static changes to a title. However, if you need to modify a specific content type title with a custom token then look at the Page Title module.

Hackathons, Code-a-thons, Code sprints, Hack days, Hackfests, Codefests, call them what you will; they have been going on for quite some time. In recent years, this has moved past the idea of a specific programming language or software to such things as civic hacking, fashion, icons, and more.

As Code Across America and International Open Data Day approach and people across the world come together to help release and utilize public data and make technology that helps their communities, I have been thinking critically about what is the real value and purpose of what I will generally call Hackathons (we so need a better word).

My main idea is this: Hackathons are community building events. Plain and simple; that is their sole purpose. Dress them in whatever activity you want, its still all about strengthening connections among people. I see many organizers let this idea go wayside in place of activities like building apps or clearing the issue queue. I also often hear the idea of community building talked about as a side benefit of hackathon events, but by defining succes of a hacakthon in terms of community building, I fully believe these events will become much more meaningful and productive to everyone involved. So let me explain in more detail.

Let's describe a hackathon a bit first

Hackathons are pretty general events where people of a community come together and work on project(s). Often the actual activities of a hackathon resemble something like the following:

• People meet in person
• Idea generation or task delegation
• Team or group forming
• Building or working (hacking)
• Presentation or judging period

To better define the space that is a "hackathon", here are some general examples of what I would lump into the term "hackathon event"; trying to provide enough variety to show that subject and tasks can be quite different.

• Civic Hackathon. Technologists and civic leaders making applications for their communities.
• Iconathon. Designers and artists coming together to make reusable icons for everyone.
• Code Sprint. Coders sprinting towards the next release of a software product.
• Data Day. Data nerds come together to try to liberate and utilize (public) data.
• Internal Hackathons. Like a code sprint, but for a specific organization or company.

What is community building?

Just to make sure we are on the same page, let's define this a bit more. Community building is simple; its the act of bringing people together for a shared cause and creating connections where there were none before and/or strengthening existing connections. That's it. But keep that in mind as we go through this.

The value of community building is that you grow the size of your community with more participants and also strengthen everyone's ties to the community as a whole, which translates to your community becoming more sustainable and more capable of accomplishing its mission, whatever that may be.

By building a stronger community, you are building more sustainable solutions.

• If your community is focused on creating civic technology, better connections produce sustainability and ensures real needs are met.
• If your community is designing icons, building relationships means knowledge and inspiration sharing, enhancing the artistic pool.
• If your community is all about a specific software, building community means less burnout, more throughput, and more adoption.

So, why a hackathon?

If our primary goal is community building, why not just hold an ice cream social and let people mingle and talk to each other? Good point. Holding a happy hour or ice cream social in your community would be a great idea and would probably strengthen your community, given the audience.

And that's where the answer comes in -- given the audience, i.e. the members of these communities, a hackathon is the best activity for community building. The people in these communities want to build and create and learn with and from each other. In fact, these communities are defined by the things they make Their members want to feel productive. Working together and collaborating builds bonds and strengthens personal ties much better than a beer will (beers can pretty great too).

Sunlight Foundation's recent article says that community building is not the focus of a hackathon and that application building is, and the article makes the comparison of a hackathon to a Habitat for Humanity event. But here's the thing, hackathons are about coming together to find new and innovative ways to tackle problems or otherwise lending one's specific skills to a problem; a Habitat for Humanity event is focused on getting bodies to help build things that have already been planned out, but the skills of the individuals are not important at all. This would translate to a Habitat for Humanity session where a foundation was set, then the volunteers would try to find the best way to build a house; it would probably be really bad unless you had experienced contractors, carpenters, and electricians. But I am not trying to knock what Habitat does; getting volunteers together to build a house is a great activity, and if your community has a set project and plan and all you need are volunteers, do think about it in this way, but a hackathon should not be run like this.

Hackathons are not for everyone, and depending on your community and goals, you may want to hold other sort of events.

What about the apps, the issue queues, the code, the icons?

The activities of the day are not the same as the reason for holding an event. The activities of a hackathon can be fairly different, stretching from everyone working on an existing project in a code sprint, to building new apps at a hackathon, to data wrangling at a open data day, to drawing icons at an iconathon, and more. These are really important and are the focus of what people are practically doing; telling people to come to a Community Building Marathon would probably not convince many folks to attend. But this is not the reason for holding the event; people could do these things by themselves, but they come together because they value their connection to the community.

You aren't going to finish these activities at the hackathon. You aren't gonna come out with anything more than prototypes for applications; even if you close out every issue in the queue, there will still be more tomorrow; you can ship a new release, but there's always another one; you will draw lots of icons, but probably not make any finished ones; there's always more work to be done. This does not mean its not worth the time and energy that people are willing to put into the event, but expectations need to be realistic. Again, it's not about the activities, its about how the activities actually build stronger communities so that this work can continue into the future.

Prototyping and experimentation

The ideas of experimentation and prototyping are very critical to successful community building. These are the ideals that have led to such a strong community of computer hackers. By providing an event where experimentation and prototyping are promoted, people can feel more comfortable with taking risks, learning new things, and being more open with each other. Focusing on finishing activities will often conflict with this.

Promote the work

Given that people are giving their time, energy, and expertise to draw icons, triage issues, scrape data, and more, it is really important that these activities are collected and put on a pedestal after the event. This is not about the actual work, its about promoting the people that did the work.

But we want to create sustainable, stable applications to help your community, you say?

That's great! But a hackathon won't make that happen. Don't get me wrong, some amazing projects have come out of hackathons that have gone on to be great things. But these are rare cases, and at best the hackathon simply played the role of getting the right people together, not providing an environment to fully foster that project. Holding a hackathon that is solely aimed at making great applications is like playing the lottery; sure, you might get a winning ticket, but most of the time you are gonna be disappointed. This is not even to speak to the mechanics of making good applications in which a day, a weekend, or even a week could not produce a sustainable solution to a problem.

If you really want to foster sustainable applications and projects, hold an event or series of events that brings together real funders and established product teams and build those relationships. A hackathon can be a real good step in getting those product teams together, but it will not provide sustainability to them.

What about contests?

First, let's distinguish between hackathons that are contests, and long-running, remote (not in-person) contests, for instances ones that are on Challenge.gov. The latter is actually a productive way to promote innovation and given certain conditions, will actually lead to some significant, long-term projects. The former is a bad idea in my opinion.

Contests at hackathon promote competition, which in a community of people where you want to strengthen relationships with, could have negative results. Also, as discussed above, hackathons do not create long-term projects, and giving significant money to a project that was prototyped over a day or two with a team that may have never met before is not a good investment of money.

On the flip side, contests do provide incentives to people that might not have them in the first place; but it is arguable if this is actually the type of behavior you want to promote. If the prize money is in small, relatively trivial amounts, and almost everyone gets a prize, contests can provide a level of competition that promotes innovation and experimentation that might not be there.

What is success?

If you accept the premise that a hackathon is a community building event, then what does success look like? It is the number of connections made and the quality of relationships at the end of the event; it is not the number of apps built or issues closed or even the quality of the projects produced. Some specific metrics:

• Fun was had
• New connections were made
• People learned new things
• People know how to keep in touch with the community
• Teams continue to work on their projects
• People come to the next event

Planning your hackathon

When you plan your hackathon, ensure that your primary focus is community building and that your activities lend themselves to that idea; you will have a fun and successful event if you do this. Some ideas to keep in mind:

• Do no harm. Make sure you are not doing things that sever connections or lessen community.
• A charismatic, empathetic, vibrant facilitator is so crucial. The person that leads the event needs to understand the core of community building and what needs to happen to facilitate it.
• Ensure everyone feels productive, no matter the skill level, or if they show up late, or even if they dont have a computer. You'll need extra facilitators for this.
• Make sure everyone can speak their ideas if they want to. This needs to be constructive, of course.
• Make sure all relevant audiences are there. Go out and get them! Only having coders working on applications will result in incomplete ideas and solutions.
• Everyone is equally important. Seriously. Make sure this is activated.
• Collect names of participants and promote their work after the event.

In conclusion

I am not trying to say that people are doing bad jobs when running their hackathons, but by keeping in mind that hackathons are just community building events, you will find a lot more success with your events.

Let me know what you think.

Credits

I have had the amazing fortune of being apart of some great communities and knowing fantastic people that have allowed me to participate, lead, and critically think about these sort of events. I have not fully attributed them in this article, but will soon.

Note that the Sunlight Foundation article linked to above is really great; I just think the original premise is a bit off.

Topics: communitydrupal-planet

Going from static design files to a completed Drupal theme can be a daunting task. I often get asked "strategic" questions by companies who are looking to hire a designer/themer for an upcoming redesign and aren't quite sure what skills they should be looking for. And I often get asked by new-to-Drupal designers how they should approach the task of transforming their design into a Drupal theme. In these conversations the following question (almost) always comes up:

Should I create a static HTML page of my design and convert that into a Drupal theme?

Can you guess what my answer is?

Five years ago, when I was first writing Front End Drupal, the answer would have been "Yes!" Five years ago there were fewer moving parts to creating a Drupal theme. There were fewer contributed modules. Responsive design wasn't even an idea yet. Five years ago I don't think that "mobile" was even a thought for most businesses, let alone a concern.

But today, in 2013, my answer has definitely changed. Now when asked if people should create a static HTML page of their design before converting it into a Drupal theme, my answer is "No!" In fact, depending on your budget size for the entire build and the type of site you're building, you may actually want to skip "static" design files for each layout (and layout variant if you're building a responsive site) and have your designer supplement their work by creating "style tiles" instead of piles and piles of page-specific layouts.

Designing for a style, instead of a specific layout, is a different workflow though. You'll need to have a relatively experienced content strategist, designer *and* themer to help you navigate this workflow for theming Drupal. Pixel precise designers are much easier to find. But here's the problem with pixel perfect design: it relies on exact markup. Drupal is markup-heavy and can drive a themer crazy if every single tag, and every single class must be exactly perfect. These days, it's easier to skip the "static" step and get into Drupal as fast as possible. Sure, you'll still want to refactor some markup (or maybe just start with a different base theme), but the point is that you aren't starting from thin air.

Themers who want markup purity tend to be coming at their work from an Model-View-Controller (MVC) perspective...which isn't what Drupal does. We're a Presentation-abstraction-control (PAC) framework. The main difference between the two (in laymen's terms) is the fragmentation of the output/markup files. Our system has lots of little nested template fragements which are compiled, or collected, into a whole. This means if you want very, very precise markup, you have to alter a lot of little files. Some of us love it because you can get really fine grained control in very tiny places without having to touch all of the markup, others hate it for exactly the same reason.

Regardless of which camp you're in, there doesn't seem to be a lot of information about building themes that talk about these software design patterns. A quick search reveals the following tutorials and articles (most are quite old). If you've got others you'd like to add to the pile, please leave them in the comments. Things get very technical very quickly...but hey, this is a list of links about software design patterns. It's supposed to be technical.

• MVC vs. PAC (from Crell in 2006!)
• Building a site on Drupal using MVC
• Drupal as an MVC Framework (the difficulties of integrating Zend + Drupal)
• An Object-Oriented Approach for Drupal Module Development (or how you will go slowly crazy if you try to treat Drupal like an MVC framework)
• A pretty awesome description of the MVC pattern and how module developers can take advantage of it (when it's appropriate): MVCZ: Model, View, Controller, and Zombies.
• (Software) Design Patterns of Drupal

As web applications become richer and more complicated the amount of JavaScript running them increases. More code means longer download times which means more waiting before your application or web site is usable. Thankfully there’s an easy solution that’s already widely used in the web development community: minification. Minified JavaScript strips whitespace and renames variables to produce a smaller download size.

Removing whitespace is pretty straightforward, but renaming variables is a more abstract concept. With tools like UglifyJS this is handled for you but here’s an example of what’s going on. Let’s look at this simple function that takes a parameter and alerts a message with that variable:

var sayHi = function(name) { alert('Hi ' + name + '!'); };

With script minification the above code will be changed to this:

var sayHi=function(a){alert("Hi "+a+"!")};

without altering the behavior of the function. As you can see, all whitespace that can be removed has been and the variable “name” was changed to “a”. The end result is the removal of 26 characters from the code. It’s not hard to see that the savings from minification will quickly add up!

You can take this one step further by wrapping your code in immediately-invoked function expressions (IIFEs). That’s a pretty scary looking name, but chances are you’ve seen these before, this is an example:

(function($) { $('h1').css('text-decoration', 'blink'); }(jQuery));

The function wrapped in parentheses is immediately invoked with jQuery as its argument. Within the function jQuery is accessed with the $ variable. Abstracting variables in IIFEs is not required though, consider this case:

(function(Drupal) { Drupal.behaviors.sayHi = { attach: function(name) { alert('Hi ' + name + '!'); } }; }(Drupal));

Minifying this code produces the following:

(function(a){a.behaviors.sayHi={attach:function(a){alert("Hi "+a+"!")}}})(Drupal);

Keeping the “Drupal” variable in your script makes sense because that’s the namespace you’re used to accessing it with and it does have meaning in the code, but by including it as an argument to the IIFE UglifyJS will replace any instances of “Drupal” with a shortened variable.

What about Drupal?

So, this is pretty cool, right? Unfortunately Drupal 7 doesn’t provide minification out of the box. Thankfully, there are contrib solutions to this problem! The Speedy module provides pre-minified scripts but unfortunately needs to be re-released every time core is updated or you need to re-minify the files yourself on core updates.

I wasn’t completely satisfied with this approach so I built uglify.me and a companion Drupal module, UglifyJS, to do script minification on the fly. uglify.me isn’t the only “minifier-as-a-service” out there, but I wanted to be able to throw something up quickly and be fairly confident that it wouldn’t upset some other poor developer out there hosting their own service.

The uglify.me service accepts POST requests of un-minified JavaScript and returns the minified version. Simple! The UglifyJS module provides an API to expose Drupal scripts that should be minified:

/** * Implements hook_uglifyjs_info(). */ function mymodule_uglifyjs_info() { return array( drupal_get_path('module', 'mymodule') . '/js/mymodule.js', ); }

The downside to this approach is that each script will create another request to the uglify.me service when the site cache is cold. If you expose a lot of scripts to the UglifyJS API this will be time consuming and could cause timeouts.

If you’re running Pressflow 7.20.1+ or apply this patch to core and you have JavaScript concatenation enabled (which you should, if you’re in production) the UglifyJS module will automatically minify the concatenated scripts. This greatly reduces the number of requests to the web service and overhead associated with minification.

Caveats

The biggest issue that I’ve encountered with this module is the requests made to the external web service. If there’s a problem connecting to the remote server the time spent waiting for the response is wasted and can cause timeouts on cold caches. This is mitigated if you’re using Pressflow 7.20.1+ since core will not request files to be rebuilt if the hash of the concatenated scripts did not change.

The uglify.me service also currently strips some header comments from scripts which would could remove any copyright or license information if they exist. This should be fixable from the uglify.me service, so if it’s bothering you and I haven’t had time to fix it before you need it, As of uglify.me v0.1.0 any comment containing the words “license” or “copyright” (case insensitive), or the common build tags “@preserve” and “@cc_on” will not be stripped from the source code. This is controlled by a regular expression so if you find a general case that’s not met by the current regular expression open a pull request to fix it!

Conclusion

Script minification is a great way to reduce your site’s download footprint and increase usability. If bandwidth and performance are concerns you should be minifying, regardless of your ultimate solution. Informal testing on the recently released Full Plate Living site showed reduction in the front page’s download weight by an average of 110KB*. Not monumental, but not too bad either.

Happy minifying!

* Note: The UglifyJS module is not currently in use on the production Full Plate Living site, but it likely will be soon!

Do you love FileMaker? Do you work with (or for!) someone who does? I’m now a Drupal Developer at Mediacurrent, but my last position (at Georgia Tech’s Office of International Education) involved a lot of FileMaker work, and this FileMaker integration would have been a lifesaver, so here goes!

This post is a quick addition to my previous tutorial: Loading Only One Field From An Entity or Node in Drupal 7. The tricky part there was what to do with node's field data and how to properly display it? Well there are lots of approaches there, but I see three which are of “Drupal Way” kind:

Read on about Working with Drupal Fields: Getting Single Field Values For Display and Manipulaton

Hey guys,
I'm going to be putting together a mini-series on Newsletters in Drupal 7. Just about every site can benefit from having a mailing list, so I figured I'd flesh out the options that are available, right now, for Drupal 7. I'm hoping to have someone on the show to talk about each of the following modules.

Tags:  newsletters, planet-drupal

In the 7 video of this 10 part Drupal video tutorial series on the Views module, we look at the Views API and how to integrate a custom module with Views 3 so that we can build views based on our custom content.

The Views API allows you to leverage the awesomeness that is the Views module when you are doing custom Drupal development and so I show you how to link up our database fields to view fields, filters, sorting, arguments and relationships.

Once this is done, I walk you through building another view based on our custom module and again, we take a quick look at using relationships and contextual filters.

Semantic panels is for Panels what Semantic Views is for Views - better control of the markup.

Todays screencast subject is Semantic Panels. If you are new to panels and Page manager, I recomend you to watch Johan Falks screencasts on the suject.

You could also find the screencast at archive.org.

After Drupal 8 feature freeze, I wanted to create some statistics of Drupal core code base evolution.
All the charts are here together in this infographic:

Drupal Code Base | Infographics

Adding the ability to comment on a blog is one way of allowing two-way communication with your readers. If your readers have an opinion or question, they'll simply leave a comment on your blog post. If you want to keep comments "clean" and without spam, you'll have to manually approve them. Of course, there are services like Mollom and Akismet that do a great job with filtering spam but some still get through.

Drupal's default comments administration page is very basic and if you want to review and approval comments you'll have to jump between two pages.

The Better comments administration module allows you to preview, approve and search comments on a single page.

Episode Number:  113 Post Topics:  Drupal Drupal 7 Module Development Drupal Planet Javascript

In the last two episodes, we covered building a basic Drupal 7 module that displayed a JavaScript confirmation before a user leaves a specific page. In this episode we continue where we left off and add the ability to display the JavaScript confirm form on specific content type node edit pages.

In this episode you will learn:

• How to add a checkbox field on the administration form that displays all the content types on your Drupal site
• How to verify you are on the node edit page of a specific content type

DDoD Video: 

read more

Way back at DrupalCon Chicago the local team created a new track called Core Conversations. The purpose of this track was to focus squarely on the interests of core developers and those interested in keeping up with the bleeding edge of Drupal development. Crazy ideas and wild rants were encouraged, as long as they were focused and discussion and finding solutions. Since then Core Conversations have been a part of every DrupalCon.

Within our company we use Drush and Drush alias files a lot. Recently I wrote a company blog post (in Dutch) about the workflow we’ve set-up and this post is its English translation. For those of you not familiar with Drush, I’ll start with a short introduction. If you are already familiar with Drush and Drush alias files, you can skip to the interesting part.

What is Drush?

A lot of Drupal developers use Drush (Drupal Shell) to speed-up their daily processes. After you’ve install Drush locally, you can run tasks on the command-line which you would normally run via the interface. Here are some often used commands:

• drush cc all: clear all Drupal caches
• drush fra: revert all features
• drush upwd Baris –password=”test”: change the password of user Baris to ‘test’
• drush sql-dump > dump.sql: export the current database to a file
• drush sqlc < dump.sql: import an exported database-dump

It is quite easy to create custom drush commands for task that you need often in your daily work. Many contrib modules come with their own drush implementation (for example drush search-api-index to index your site content).

What are Drush alias files?

In so-called alias files you describe the server information per website. They contain paths and usernames of all environments of a site (dev, test, staging, live). Here’s an example:

Filename: customer.aliases.drushrc.php. I’ve placed this file in my ‘aliases’ folder within my .drush folder. On Linux you can find it here: ~/.drush/aliases

limoengroen.aliases.drushrc.php $aliases['dev'] = array( 'root' => '/Users/BarisW/Sites/company.com', 'uri' => 'dev.company.com', 'path-aliases' => array( '%dump' => '/tmp/dump-company.sql', '%files' => 'files', ), ); $aliases['test'] = array( 'root' => '/var/www/company-test/htdocs', 'remote-host' => 'webserver1.company.com', 'remote-user' => 'username-test', 'uri' => 'test.company.com', 'path-aliases' => array( '%dump' => '/tmp/dump-company.sql', '%files' => 'files', ), ); $aliases['prod'] = array( 'root' => '/var/www/company-prod/htdocs', 'remote-host' => 'webserver2.company.com', 'remote-user' => 'username-prod', 'uri' => 'www.company.com', 'path-aliases' => array( '%dump' => '/tmp/dump-company.sql', '%files' => 'files', ), );

The main advantage of using alias files is that you can use them to run all the drush commands on external servers. To be able to do this you need SSH access to the external server and that Drush is installed on the external server as well. If you don’t want to enter your password each time you run an external Drush command, you can also add your SSH key to the external server.

Using these alias files I can now simple run a command like this to clear the caches on the production environment:

drush @company.prod cc all

Or, to copy the production database to my local machine:

drush sql-sync @company.prod @company.dev

Ideal! Optionally, Drush sql-sync can also sanitize the data (to obscure all e-mails and passwords). This prevents developers to store sensitive customer data on their laptops.

drush sql-sync @company.prod @company.dev --sanitize How to use Drush alias files in teams?

Extremely handy, but each developer had to enter all the settings from the various local environments in their alias files. The solution we found for this is simple and very effective: Dropbox / SparkleShare or similar.

We created a folder in Dropbox that contains all alias files. We symlinked the alias directory in ~/.drush/aliases to that folder. In this way, each team member always uses the correct data for all the project environments. You can also use these same alias files for your Continuous Integration environment (we re-use them also for our automated deployments using Jenkins).

To be able to do so we had to change one setting: instead of the ‘dev’ alias we use the names of our employees (because each employee runs his local environment somewhere else). So in my case it is now:

drush sql-sync @company.prod @company.baris Bonus tip: alias files inheritance

The real fun starts when you start using inheritance within your alias files. For example; we use a ‘localdev’ alias for all local environments:

defaults.aliases.drushrc.php $aliases['localdev'] = array( 'target-command-specific' => array( 'sql-sync' => array( 'sanitize' => TRUE, 'confirm-sanitizations' => TRUE, 'no-ordered-dump' => TRUE, 'no-cache' => TRUE, 'enable' => array( 'devel', 'stage_file_proxy', 'ds_ui', 'fields_ui', 'views_ui', ), ), ), ); customer.aliases.drushrc.php $aliases['localdev'] = array( 'parent' => '@defaults.localdev', 'uri' => 'dev.company.com', 'path-aliases' => array( '%dump' => '/tmp/company-dump.sql', '%files' => 'files', ), ); $aliases['baris'] = array( 'parent' => '@company.localdev', 'root' => '/Users/BarisW/Sites/company.com', ); $aliases['eric'] = array( 'parent' => '@company.localdev', 'root' => '/Users/EricM/Sites/dev.company.com', );

This setup ensures that every sql-sync is automatically sanitized, and that a number of dev modules are enabled that are turned off on the live environment (like the devel module).

PS: to use the 'enable' command, you need to copy the sync_enable.drush.inc file from your drush installation folder to your ~/.drush folder.

How do you use Drush alias files in your team? Please share your tips in the comments!

Tags:  Drupal Deployment drush DTAP commands Planet Drupal

Drupal 7.20, a maintenance release which contains fixes for security vulnerabilities, is now available for download. See the Drupal 7.20 release notes for further information.

Download Drupal 7.20

Upgrading your existing Drupal 7 sites is strongly recommended. There are no new features or non-security-related bug fixes in this release. For more information about the Drupal 7.x release series, consult the Drupal 7.0 release announcement.

Security information

We have a security announcement mailing list and a history of all security advisories, as well as an RSS feed with the most recent security advisories. We strongly advise Drupal administrators to sign up for the list.

Drupal 7 includes the built-in Update Manager module, which informs you about important updates to your modules and themes.

Bug reports

Drupal 7.x is being maintained, so given enough bug fixes (not just bug reports), more maintenance releases will be made available, according to our monthly release cycle.

Changelog

Drupal 7.20 is a security release only. For more details, see the 7.20 release notes.

A complete list of all bug fixes in the stable 7.x branch can be found in the git commit log.

Security vulnerabilities

Drupal 7.20 was released in response to the discovery of security vulnerabilities. Details can be found in the official security advisory:

• SA-CORE-2013-002

To fix the security problems, please upgrade to Drupal 7.20.

Known issues

None.