Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Aug 23 2018
Aug 23
Drupal Europe Image by LuckyStep @shutterstock
  • to revolutionize publishing, with a new rewarding model in an environment which can build trust and allows community governance.
  • to reshape open source communities, with a better engagement and rewarding system.
  • to free digital identity, thus killing the need of middlemen at the protocol layer.

Blockchain is an universal tool and can be applied in many different areas.

Communities, like the Drupal Community, can find new ways to flourish. Even larger and risky projects can be financed in new ways, with ICO (Initial Coin Offer). Taco Potze (Co-Founder Open Social) has a 10 year Drupal background and is an expert on Communities. He is working on blockchain technology to build a better engagement and rewarding systems for communities. Wouldn’t that be really nice for us?

See also Taco’s session: ICOs, a revolutionary way to raise money for your company

Publishing and its classic monetization model is challenged. Intermediates are about to disrupt the relationship between authors and publishers and their readers. This is based on a troublesome business model, with massive tracking and profile building, to turn our engagement in advertisement money. At the same time poor content and fake news has become a threat to our society. Gagik Yeghiazarian (CEO, Co-Founder Publiq) is looking for new ways to address these problems, with a non profit, distributed media platform based on blockchain.

See also Gagik’s session: Blockchain Distributed Media — A Future for good publishing

The Internet is broken and blockchain can fix it. The biggest promise with blockchain is to make middlemen obsolete, by creating trusted identities in an open protocol. This is to break the monopoly of the middlemen and to retain a free web. We recognize aribnb, amazon, ebay, netflix, itunes as middlemen. We understand, when we by or book, they get their share. With Google, Facebook and YouTube there are some other huge monopoly middlemen, they get their share based on our attention and personal data. They know how to transfer our attention into dollars, by selling it to advertisers. Ingo Rübe (CEO Bot Lab) is working on a protocol, which will allow people to gain control of their digital identity. It will be called KILT Protocol. (Ingo is well known in the Drupal Community and a Member of Drupal’s Advisory Board. As a former CTO of Burda he was the Initiator of the Drupal Thunder Distribution)

Our Panel will be moderated by Audra Martin Merrick, a board member of Drupal Association.

Drupal Europe
Your Track Chairs

Aug 14 2018
Aug 14

Drupal Europe: Publishing + Media Special Focus

Drupal Europe

What industries come to mind when you hear blockchain? Banking? Trading? Healthcare? How about publishing? At Drupal Europe publishers will gain insights into the potential blockchain technology offers and learn how they can benefit. Meet Gagik Yeghiazarian, founder of the nonprofit foundation Publiq, and learn how he wants to fight fake news and build a censorship-resistant platform — using blockchain.

The publishing world is changing. Publishers no longer solely control media distribution. Big players like Facebook and Google are middlemen between the publishers and their readers, and technology built to entice publishers — Google’s AMP (Accelerated Mobile Pages) and Facebook Instant Articles — has strengthened social platforms as distribution channels. Additionally, publishers have lost money making classifieds business as employment and real estate markets create their own platforms and portals to reach the audience.

Photo by Ian Schneider on Unsplash

As a result of these developments, publishers are losing direct relationships with their readers as well as critical advertising which traditionally supported the editorial and operational costs. The platforms act as middlemen, using the content of the publishers for collecting data and selling them to advertisers. The publishers are left out in the cold.

Critically, publishers are also facing a crisis of confidence. As social platforms are used to spread fake news and poor content, mistrust in journalism grows.

The nonprofit foundation Publiq wants to face these challenges with a blockchain-powered infrastructure. It aims at removing unnecessary intermediaries from the equation and helping to create an independent, censorship-free environment. Gagik Yeghiazarian, CEO and Co-Founder of Publiq, is convinced: “Blockchain infrastructure allows content creators, readers and other participants to build a trusted relationship.”

You can learn more about Publiq and its blockchain infrastructure at Drupal Europe in Darmstadt: Gagik Yeghiazarian’s session “Blockchain Distributed Media — A Future for good publishing” will give you a glimpse into this new technology and a real-world application of it.

While you’re at Drupal Europe, be sure to check out the exciting blockchain panel discussion where Gagik, Ingo Rübe of Botlabs, and Taco Potze of Open Social, will share insights and use cases for blockchain technology. Don’t miss this!

Drupal Europe
Publishing & Media — Track Chairs

Jun 08 2018
Jun 08


I am the sysadmin and developer for Art & Object, a Drupal 8 website built with the Drupal Composer project. The version pin in composer for Drupal was 8, which in hindsight was too broad for our usage. Meaning Drupal point releases (8.3 to 8.4) require study to ensure you understand all the implications, which wasn't something I did. I just blindly did a composer update, thinking everything would be handled automatically.

This really bit me when 8.4 came out because my server was running Debian Jessie, which runs PHP 5.6 and my composer didn't have a platform PHP configuration, so a lot of the underlying Symfony code updated to PHP 7. So I ended up doing a backgrade until I figured it out.

Then there were the critical security Drupal updates (SA-CORE-2018-002 and SA-CORE-2018-004) earlier this year that would not be released for 8.3, so I had to upgrade (or at least, at the time, I felt I had to, though I see now they have a patch for older 8.x releases). By that time, 8.5 was released, so I updated the composer to 8.5 and ran update and after some basic testing, moved on.

Then a few months later, I noticed the status error messages about running the contrib media module alongside the core and I knew I missed something and there was a problem.

I then started down a wicked rabbit hole of getting a local copy running and following the upgrade instructions, running into problem and going back to getting a local copy running fresh again and trying again. Lots of trail and error (mostly errors) and head-banging-on-the-desk. I looked for help on the #media IRC channel, but the best advice came from posting on Stack Overflow, where @sonfd pointed out that the media module needs to be uninstalled first. I thought I had tried that and ran into an error message that mentioned you can't uninstall the media module with media items already created.

The Fix

So after lots and lots (and lots) of local refreshes and trials and errors, here's the list I finally followed when it came time to upgrade production:
  1. First, put the site in maintenance mode. Then take a database backup and make a tarball of your project directory. Don't skip over this.
  2. drush pmu media crop_media_entity: pmu = pm-uninstall. Remove the media module (and crop_media_entity, if you have that, too). This was the tip from @sonfd that opened the rest of this process for me.
  3. composer remove drupal/media: Remove the contrib media module from the filesystem. I should add that I prefixed all my composer commands with /usr/bin/php -d memory_limit=-1 /usr/local/bin/ because I often ran into memory limits when running composer.
  4. composer require drupal/inline_entity_form drupal/crop:1.x-dev drupal/media_entity_instagram:2.x-dev drupal/media_entity:2.x-dev drupal/media_entity_slideshow:2.x-dev drupal/media_entity_twitter:2.x-dev drupal/slick_media:2.x-dev drupal/media_entity_actions: These modules are temporary to help upgrade the database records.
  5. composer remove drupal/video_embed_field: For some reason, I couldn't require video_embed_field:2.x-dev, so I removed it and then...
  6. composer update: When I ran this, it updated video_embed_field to 2.x-dev.
  7. composer require drupal/media_entity_image drupal/media_entity_document drupal/image_widget_crop: More temporary modules to help the upgrade process.
  8. drush cr: Clear cache to make sure Drupal picks up new modules and paths.
  9. drush updb: Run the database updates.
  10. drush pmu entity media_entity: Uninstall these modules (these were the old contrib modules)
  11. composer remove drupal/media_entity drupal/media_entity_image drupal/media_entity_document drupal/crop drupal/image_widget_crop
    /usr/bin/php -d memory_limit=-1 /usr/local/bin/composer require drupal/crop:2.x-dev drupal/image_widget_crop drupal/empty_page:2
    : Clean out the temporary modules from the filesystem.
  12. drush cr: Clear caches
  13. drush updb: Run database updates
  14. drush cex: Export the configuration (so you can commit it later).
  15. The blazy module had an error with the core media and hasn't been updated (as of this writing), but there is a patch to fix that. So I learned how to add patches to a composer file - turned out pretty simple. Add this to composer.json in the extra section:
            "patches": {
                "drupal/blazy": {
                    "Gets Blazy to work with Drupal Core Media": "https://www.drupal.org/files/issues/2881849-8.patch"
  16. composer update: This was odd, but I had to do an update, which picked up the patch, but didn't really install it. I can't remember exactly now, but I believe this actually deleted the blazy folder.
  17. composer remove drupal/blazy: So removing this actually installed it. Who knew? Whatever ... it's still in my composer.json and now the filesystem has the module and the patch.
  18. drush cr: Clear caches!
  19. For some reason, this upgrade created a new field called field_media_image_1 and assigned that as the source for the image media type, which broke some of the images on the site. So I edited media.type.image.yml file to revert source_field back to my original field_image.
  20. drush cim: Import my hack to get my media image type to work.
  21. I had a custom field formatter that I had to edit to change the namespace from media_entity to media.
  22. drush cr: Final cache clear!
  23. Test and make sure all is well. If so, take the site out of maintenance mode and commit your repo changes.

Advice / Conclusion

A lot of this pain could be negated by studying the release notes better. I own that and this counts as one of my many scars of lessons learned. I hope others can learn from my lesson, too. Someone may end up writing a meta post about this post to point out the high cost of maintaining a Drupal site and I don't think they'd be wrong about that, but that's the price you pay for running servers that are publicly accessible.
May 14 2018
May 14
Photo by janeb13 on pixabay

As you’ve probably read in one of our previous blogposts, industry verticals will be a new concept at Drupal Europe. Verticals replace the summits, which typically took place on Monday, before the conference. Sometimes these were in a separate location from the main conference venue, and often the conference ticket did not cover access to the summits. At Drupal Europe summits have become industry verticals and are integrated with the rest of the conference — same location, same ticket. Following is a summary of what to expect in the new verticals at Drupal Europe.

Verticals bring together people from an industry to:

  • learn about outstanding projects being developed in their field
  • share their interests and ideas
  • listen and learn together in sessions
  • discuss challenges and develop solutions for their market

With all the topics under one roof, every session you are interested in is within easy reach. There will be a guide to specific sessions and people that are involved in your industry: Media and Publishing.

However, nothing will stop you from getting off the beaten track to mix & match your interests! One Drupal Europe ticket gives you access to everything we have on offer: sessions, workshops, panels, contribution opportunities, and BoFs. In this example you might start with a great session about a new top-notch publishing site, get dragged into details of the site’s complex workflow rules and later jump into a technical session, to understand a specific decoupled approach the site was built with.

Photo by Rachael Crowe on Unsplash

All attendees will enjoy a amazing program providing insights into industry-specific challenges and solutions. The Media and Publishing industry itself faces many challenges. It has had to almost reinvent itself to adapt to the digital age in order to be successful in the 21st century with our society’s media consumption shifting from paper to digital.

We want to provide the best possible lineup of speakers, panels and sessions for the publishing/media vertical. Drupal Europe will be open to allow you to submit your great session idea very soon. As a choice of different verticals will be available on the website, please tag your session as publishing/media to indicate that it is related to this industry. We welcome proposals for all topics related to publishing/media!

If you have something interesting to share (questions, thoughts, advice), that might help us before we officially open our call for papers, please reach out to [email protected].

Photo by rawpixel on Unsplash

We can’t wait to see you at Drupal Europe, 10th — 14th September in Darmstadt Germany!

Dec 11 2015
Dec 11

Wind Turbine
Looking for a new, promising career? How do you feel about climbing a 212-foot (64.6m) tower next to a cable carrying 34.5kV of electricity? Perhaps you enjoy a workplace where arc flashes and fault currents are hazards to be dodged every day? If so, you're in luck because the occupation forecasted to grow the fastest in the next 10 years is that of a wind turbine service technician.

If you like the idea of getting into a truly growing field, but would rather do something a little more (ahem) down to earth, then perhaps web development (we recommend Drupal!) is the way to go. The United States Department of Labor (USDOL) recently released a short video showcasing the occupations projected to be the fastest growing for the next 10 years, and web developer is near the top of the list.

[embedded content]

The USDOL is forecasting that the number of web developer positions will grow 26.6% (over 39,000 jobs) between 2014 and 2024. They put web developer positions in the "some post-secondary education required" category, alongside occupations like wind turbine service technicians, commercial divers, and occupational therapy assistants.

Unlike some of the other jobs on the USDOL's list, web developers earn pretty decent wages – an average of $63,490. Compare that with personal care aides, an occupation expected to grow by 450,000 new positions that pay an average of $20,440 (the federal poverty level for a 3-person household is $20,090).

The Drupal Career Online 12-week, part-time training course provides the necessary education for aspiring Drupalists to learn how to build Drupal sites using best practices and workflows common to modern Drupal development. Our curriculum teaches a blend of Drupal 7 and Drupal 8 skills, along with a healthy dose of command-line tools like Git, Drush, and Drupal Console. Our next session begins in March of 2016. If you’d like to learn more Drupal careers and our training, you can sign up for our free Taste of Drupal information session on February 17.

Trackback URL for this post:


Nov 23 2015
Nov 23

DCO Fall 2015 students
A few days ago, we graduated yet another class of students from our 12-week Drupal Career Online training program. This was the seventh session of our unique Drupal training program (not to mention the two most recent Acquia U classes) and - like Drupal - we're constantly evolving. This session brought the most significant changes to the curriculum since we've started - integrating some Drupal 8 content as well as a re-structuring of the schedule to put more of an emphasis on development workflows and tools.

This session's class was comprised of five students - four of whom are existing full-time employees of organizations using Drupal. The students had a wide range of experience, but all had a desire to learn best practices and the skills necessary to extend and maintain modern Drupal sites. We met in a virtual classroom three times a week for the duration of the 12-week program to learn new skills, work on in-class exercises, review homework, and discuss issues that the students experienced with both class exercises and real-world Drupal projects.

This session's graduating class includes:

As part of their training, they've been given a healthy dose of community involvement, including the importance of using IRC, attending Drupal events, and participating in the community. As you see these folks around, please give them a nice welcome!

From the very beginning of the Drupal Career Online program in 2011 (then called the "Drupal Career Starter Program") our goal has been to provide professional long-form Drupal training focusing on best practices, community involvement, and sustainable site building. To this end, we're constantly improving and expanding the curriculum. Currently, students are provided with PDF lessons, screencasts, online assessments, all in addition to the 7 hours of live, instructor-led training that are provided each week.

With the recent release of Drupal 8, it was time to re-think our curriculum and begin making some wide-ranging changes. In addition to adding Drupal 8 to a number of various site-building lessons and exercises, we made a rather large structural change to the overall curriculum to put more of an emphasis on comment development workflows. This change was based on feedback from both graduates and employers. For example, in the past we had separate lessons for Drush, Git, and working with remote servers. The curriculum now begins with basic Drush and Git commands and continuously expands on them throughout the 12 weeks.

The goal is to get students into the habit of using Drush and Git as they work on the various parts of a site. As the course progresses, we introduce the concepts of remote repositories (utilizing the GitHub, WebEnabled, Pantheon, and Acquia platforms) as well as remote development, testing/staging, and production/live environments. The overall goal being preparing graduates to be able to be revenue-generating members of their organization from day 1.

We're extremely proud of all our graduates and know that we couldn't do it without the help of our volunteer community mentors and Work Experience Drupal partners. Our next session begins in early March, 2016.

Trackback URL for this post:


Jul 20 2015
Jul 20

Trust, authentication. The key factors of the internet in this age where hacking, privacy and security are the biggest threat to freedom on the Internet. Trust starts with authentication. Authentication starts with identification. For some good background, the decade old keynote of Dick Hardt with regards to identity, it is still a classic.

The old adagium is that good authentication can be done by using three factors, something you know, something you have and something you are. For example, a pincode (know), a key (have) and a photo (are).

Two factor authentication combines two of these three for identification, often a password and a one-time-usable code delivered via the phone that you have. Two factor authentication is standard in the offline world, a driver's license (have) with a photo (are) or a bank card (have) with a PIN code (know). And it is about time that we use this Two Factor Authentication (TFA) as the basis for our web presence as well, to log in to your mail, your bank account and to your Drupal website.

This will prevent ugly security incidents or frontpage defacements. People reuse passwords, write them down never change the passwords, have listed passwords or share them and if you have a website where editers and administrators can publically can log in, you will have a security incident waiting to happen.

On drupal.org we use TFA for higher roles. The module being used as d.o is https://www.drupal.org/project/tfa and I do think it should be on every Drupal site.

I always wanted to start a screencast series on Drupal modules for site builders. So it was only logical that the TFA module was the first module I used for this vlog. You can see the screencast called "The Orange Suit" episode 1, "Something you have" and hear why you need this module, how to configure the module and what the module does.

[embedded content]
Please leave a comment with your feedback on the youtube video, if you just liked it, thumbs up on youtube: and do follow "The Orange Suit" on facebook and twitter

Suggestions for the next episode are welcome as well via one of those channels.

May 27 2015
May 27

In just a few short weeks, the latest class of DrupalEasy career training students will complete their course work and will be ready for an opportunity to prove themselves through internships, entry- or junior-level Drupal development positions! If your organization is looking to build its talent pipeline, this is your opportunity to bring on a highly-trained individual with the passion and desire for building Drupal sites.

We’ve set up a program to match graduate skills with potential employer needs with our Work Experience (WE) Drupal program, and it is once again open for new host applicants. WE Drupal hosts are under no obligation by applying - we're just looking for some information on what type of person you're looking for (developer, site-builder, front-end, QA, PM, etc…) and an idea of the types of projects you have in mind for the graduate. We'll share all of the student profiles with you, and share your information with our students.

If you find someone, or several who seems like they might fit the bill, we’ll make the introduction so you can speak with them. You are not obligated to hire anyone, but if you find someone you'd like to work with, the details of the relationship (type of employment, pay rate, hours/week, length of trial period, etc...) are all between you and the graduate.

By the time they graduate in a few weeks, students will have been immersed in comprehensive Drupal training for 12 weeks. Not only are they learning Drupal site building skills, but they've each developed a solid foundation with the entire Drupal ecosystem. They've received training on Git, Drush, Features, module and theme development, community contributions (both code and documentation). Students have presented numerous demos of their work to the rest of the class. Every student is ready for the next step: real-world experience.

In addition to providing instruction on Drupal and its ecosystem, we've also provided instruction on "learning how to learn" - what do you do when you get stuck? What's the best way to leverage the Drupal community? They also will continue to have access to our teaching materials, including screencasts and reference documents so that if they need a refresher on a topic, they know exactly where to go.

This will be our sixth graduating class from the various DrupalEasy career training programs. Our graduates have gone on to full-time, part-time, and contracting Drupal positions all over the United States. Like the previous DrupalEasy graduates, this class shares the desire to become part of the Drupal community. The next step is for them to find an organization that is looking for someone with the desire and qualifications to contribute to the organization's goals from day one, and willing to willing to provide an opportunity for additional learning and mentoring.

We're excited about the outlook for these Spring session graduates, and are already looking forward to our Fall semester, so if you need to train up your Drupal bench, or know someone who is looking to become a Drupal developer, please send them our way!

Trackback URL for this post:


Mar 24 2015
Mar 24

Drush for Developers (Second Edition) book cover Calling this book a "second edition" is more than a little bit curious, since there is no Drush for Developers (First Edition). I can only assume that the publisher considers Juampy's excellent Drush User's Guide (reviewed here) as the "first edition" of Drush for Developers (Second Edition), but that really minimzes ths book, as it is so much more than an updated version of Drush User's Guide. It would be like saying The Godfather, Part 2 is an updated version of The Godfather - which is just crazy talk. Drush Developer's Guide is more of a sequel - and (like The Godfather, Part 2) a darn good one at that.

This is not a book about learning all the various super-cool Drush commands available and how awesome Drush is and how it can save you all sorts of time (see Drush User's Guide). This book is for people who already know what Drush does, already have it installed, and probably already use it every day. It doesn't lay the groundwork like a guide for newbies, it takes your average Drush user and "levels them up."

Granted, the first chapter has some necessary introductory material: what is Drush, how do you install it, how can you use it to save the world. Been there, done that. But, it is in the first few pages of the second chapter that Juampy tips his hand - this is really going to be a book about using Drush to create an efficient local-dev-stage-production workflow.

He introduces the topic of the "update path"; a sequence of drush commands that can be used when pushing code (with features) between environments to ensure that the "destination" environment is properly updated to take advantage of the updated code. Turns out this book is actually about creating an efficient workflow - it just happens that Drush is an excellent tool to accomplish the task. For the most part, he starts with a very basic "update path" and then spends the rest of the book iterating on it and improving it in virtually every section.

Along the way, Juampy does a great job of introducing us to a number of intermediate-to-advanced topics. He covers Drupal's registry for module and theme paths, the Features module, cron, Jenkins, Drush and Drupal bootstrapping, and Drupal's Batch API - to name a few. Each of these new topics never seem to be forced - there is always a compelling reason to spend a few pages with each one in order to improve the "update path".

Juampy also does a nice job of covering the basics of creating a custom Drush command, including an entire chapter devoted to error handling and debugging. I especially appreciated his examples of how to create a custom Drush command that calls a number of other Drush commands. This makes it possible to design a custom workflow that can be executed with a minimum of commands.

The book reaches its crescendo in the second-to-last chapter, "Managing Local and Remote Environments". Juampy deftly covers site aliases then quickly integrates them with the "update path" he started in chapter 2, to end up with a super-solid workflow that anyone can adapt for their own purposes.

He wraps things up with a chapter on setting up a development workflow, but by the time I got to this chapter, my mind was already racing with how I could improve my current workflow with the ideas already presented. The information in the last chapter seems incremental in comparison to the rest of the book, but there are great ideas nonetheless. Having a site's docroot at the second level in the Git repo and fine tuning database dumps from production was the icing on the cake.

Personally, I can't wait until I finish writing this review (I'm almost there!) so that I can implement some of Juampy's ideas in some of my client projects. If you feel like you're only using 10% of Drush and want to take it to the next level, buy this book.

I did exchange a few emails with Juampy while I was writing this review. (He did confirm that there is no "Drush for Developers (First Edition.)" I can only hope that the "Second Edition" in the title doesn't dissuade anyone from picking up this book - it is a worthy addition to any Drupal professional's library.

Trackback URL for this post:


Attachment Size drushfordevelopers_bookcover.jpg 21.42 KB
Mar 19 2015
Mar 19

Programming Guide to Drupal book cover image O'Reilly's Programmer's Guide to Drupal, written by Jennifer Hodgdon is a solid book for Drupal developers of all skill levels. I'd argue that it is one of the better books for PHP developers wanting to learn more about Drupal. It provides a wealth of solid information on a nice array of topics that professional Drupal developers should know. It's not a long read (less than 100 pages of actual content), but the structure and variety of topics covered makes it a great reference for best practices and intermediate to advanced "what's the best way to do this?" topics in Drupal development.

First I need to confess, this isn't a new book. It was published in late 2012. So why am I reviewing a book that was published over 2 years ago? Well, I don't really have a good excuse. I started reading it right around the time is was released, but it somehow got burried in my reading pile - which I managed to reach the bottom of just a few weeks ago. When I picked it back up again, I realized that I had found a bit of buried treasure.

Jennifer has been a long-time contributor to the Drupal community, specifically in the area of community documentation. She is a past member of the community's Documentation Working Group and is a core committer for documentation and coding standard patches. This background gives her more than enough street-cred to author a book that preaches best practices, common mistakes, and advanced coding examples.

For experienced Drupal developers, the first three chapters are an invaluable resource of best practices:

  • A not-too-deep overview of the lifecycle of a page request from a technical standpoint.
  • A high-level overview of Drupal's caching system.
  • A discussion of six Drupal programming "principles". Within each principle is a technical discussion of topics related to the principle. For example, the first principle is "Drupal is Alterable"; within this section Jennifer discusses hooks, render arrays, and template files. The other five principles read like a manifesto of the things that makes Drupal great (internationalization, accessibility, database independent, security, and testing/documentation). In my opinion, this section alone is worth the price of the book.
  • A discussion of four common Drupal programming mistakes - the first of these is a favorite teaching and consulting topic of mine: programming too much. Jennifer discusses some of the amazing Drupal contrib modules that often alleviate the need to write custom code, and the advantages of having as little custom code in a project as possible.

The fourth chapter is a really nice, concise resource for Drupal developers for some intermediate and advanced Drupal development topics. I found the "Programming with Entities and Fields" section especially valuable. Anyone who finds Drupal's Entity system a bit of a mystery will find a wealth of information about what is included in Drupal core as well as what the contrib Entity API module provides. It provides code examples for creating new fields, widgets, and formatters.

For Drupal developers looking to write their first custom field formatter, Jennifer provides the perfect amount of introductory information and code samples without getting too far in the weeds. Other topics covered in this section includes Drupal paths and well as Views and [Rules](https://drupal.org/project/rules] module add-ons.

The final (short) chapter covers Drupal development tools and resources. It's a nice overview, and a great way to wrap things up.

The Programmer’s Guide to Drupal is a solid addition to anyone's Drupal library. It is one of the few Drupal books that has earned a permanent spot on my within-reach-of-my-desk bookshelf, (no more bottom of the stack for this one) and I have no doubt that Drupal developers of all skill and experience levels will learn something from within its pages.

Trackback URL for this post:


Mar 19 2015
Mar 19

Programming Guide to Drupal book cover image O'Reilly's Programmer's Guide to Drupal, written by Jennifer Hodgdon is a solid book for Drupal developers of all skill levels. I'd argue that it is one of the better books for PHP developers wanting to learn more about Drupal. It provides a wealth of solid information on a nice array of topics that professional Drupal developers should know. It's not a long read (less than 100 pages of actual content), but the structure and variety of topics covered makes it a great reference for best practices and intermediate to advanced "what's the best way to do this?" topics in Drupal development.

First I need to confess, this isn't a new book. It was published in late 2012. So why am I reviewing a book that was published over 2 years ago? Well, I don't really have a good excuse. I started reading it right around the time is was released, but it somehow got burried in my reading pile - which I managed to reach the bottom of just a few weeks ago. When I picked it back up again, I realized that I had found a bit of buried treasure.

Jennifer has been a long-time contributor to the Drupal community, specifically in the area of community documentation. She is a past member of the community's Documentation Working Group and is a core committer for documentation and coding standard patches. This background gives her more than enough street-cred to author a book that preaches best practices, common mistakes, and advanced coding examples.

For experienced Drupal developers, the first three chapters are an invaluable resource of best practices:

  • A not-too-deep overview of the lifecycle of a page request from a technical standpoint.
  • A high-level overview of Drupal's caching system.
  • A discussion of six Drupal programming "principles". Within each principle is a technical discussion of topics related to the principle. For example, the first principle is "Drupal is Alterable"; within this section Jennifer discusses hooks, render arrays, and template files. The other five principles read like a manifesto of the things that makes Drupal great (internationalization, accessibility, database independent, security, and testing/documentation). In my opinion, this section alone is worth the price of the book.
  • A discussion of four common Drupal programming mistakes - the first of these is a favorite teaching and consulting topic of mine: programming too much. Jennifer discusses some of the amazing Drupal contrib modules that often alleviate the need to write custom code, and the advantages of having as little custom code in a project as possible.

The fourth chapter is a really nice, concise resource for Drupal developers for some intermediate and advanced Drupal development topics. I found the "Programming with Entities and Fields" section especially valuable. Anyone who finds Drupal's Entity system a bit of a mystery will find a wealth of information about what is included in Drupal core as well as what the contrib Entity API module provides. It provides code examples for creating new fields, widgets, and formatters.

For Drupal developers looking to write their first custom field formatter, Jennifer provides the perfect amount of introductory information and code samples without getting too far in the weeds. Other topics covered in this section includes Drupal paths and well as Views and [Rules](https://drupal.org/project/rules] module add-ons.

The final (short) chapter covers Drupal development tools and resources. It's a nice overview, and a great way to wrap things up.

The Programmer’s Guide to Drupal is a solid addition to anyone's Drupal library. It is one of the few Drupal books that has earned a permanent spot on my within-reach-of-my-desk bookshelf, (no more bottom of the stack for this one) and I have no doubt that Drupal developers of all skill and experience levels will learn something from within its pages.

The second edition of this book - for Drupal 8 - is now available as a early release.

Trackback URL for this post:


Mar 16 2015
Mar 16

light bulb brain

There are a lot of ways to train people to become Drupal site-builders, developers, and themers: books, blog posts, screencasts, 1-day trainings, and mentors - just to name a few. Drupal Career Online is different; we provide more than just one learning vector into our students brains. Our live, online, Drupal training program provides an expert instructor, professional tried-and-true curriculum, a full library of screencasts supporting the curriculum, and access to dedicated community mentors. Furthermore, this isn't bootcamp-style training; Drupal Career Online is a sanely-paced 12-week program that meets just 3 times per week. The goal of the Drupal Career Online program is simple: to create talented, well-rounded, community-minded Drupal site-builders, developers, and themers with a real-world knowledge of Drupal and the various satellite technologies that Drupal professionals use every day. Our next session starts on March 24.

The spring semester of Drupal Career Online will be our sixth time presenting the class since 2011. More than 80 people have graduated, and many are now following their dreams of Drupal consulting, contracting, and full-time employment. Our curriculum was also used for the most recent class of AcquiaU, and portions of it are used for other private and public trainings offered by DrupalEasy.

Drupal Career Online is taught via GoToMeeting, enabling the instructors and students to interact via audio, screensharing, and (surprisingly important) live video. There are 2 classroom meetings per week (Tuesday and Thursdays from 5:30pm-9:00pm EDT for this session) and a "lab hours" meeting (time and date will be determined by the class). By using GoToMeeting, students are able to interact directly with the instructor, view the instructor's screen, and - more importantly - the instructor can quickly share students' screens. This leads to a surprisingly more dynamic learning environment than traditional classroom-based trainings. The use of webcams to see each other during class, helps to very quickly provide a sense of community and bonding that is always extremely important for long-form trainings.

Our curriculum is proven, and always evolving. Upon acceptance into Drupal Career Online, students are provided access to the DrupalEasy Academy web site where all the class materials are available. This includes lesson handouts, reference documents, screencasts, and online assessment quizzes. Our curriculum is always being reviewed, refined, and expanding. We've recently added new (optional) lessons on "JavaScript/jQuery integration with Drupal" and "Introduction to the Features module" based on student requests. Students retain access to the class materials for an indefinite period of time after the completion of the Drupal Career Online semester, so that they can come back at anytime for a refresher.

During the course, each student is also provided with a "community mentor" who provides yet another source of information and learning opportunities, as well as expansion of their personal Drupal network. Community mentors are sometimes Drupal Career Online alumni who understand the challenges facing students, and who are always willing to provide advice, support, and guidance.

As the lead instructor of Drupal Career Online, I I take great pride in the fact that I'm not just a trainer, but also a professional Drupal developer and community member. I'm a firm believer that Drupal trainers need to have ongoing real-world experience in building and maintaining Drupal sites. When I'm not training students, I'm usually working for our development clients. Part of the reason I teach the importance of community is because I know the benefits of being an active member, both at the local level (I'm one of the main organizers of Florida DrupalCamp and in the worldwide Drupal community (I'm one of the maintainers of the Drupal 8 migration system, and a member of the Drupal Association Community Cultivation Grants committee). Getting involved with, and leveraging the Drupal community is something that we talk about and teach from week 1 of Drupal Career Online.

We're passionate about Drupal training, and are convinced that Drupal Career Online provides the best path for individuals looking to build long-term careers in the Drupal community. Registration for Drupal Career Online ends March 18, so don't delay in submitting your application. If you know of someone who might benefit from Drupal Career Online, you can earn a referral bonus if they mention you in their application.

Trackback URL for this post:


Mar 12 2015
Mar 12

For the sixth year in a row, Central Florida will host the Sunshine State's largest gathering of Drupalists for two full days of learning, networking, and sharing at Florida DrupalCamp 2015. To be held Saturday and Sunday, April 11-12, 2015 at Florida Technical College in Orlando, approximately 300 people will gather for a full day of sessions and a full day of community contributions. Attendees will be provided with knowledge, food, and clothing - and maybe a surprise or two as well! Registration ($25) and session proposals are now open.


Following up on last year's featured sessions-instead-of-a-single-keynote idea, we're doing away with a traditional one-size-fits-all keynote, and instead featuring four featured speakers from around the country. Erik Baldwin (Drupal 8 theming), Tess Flynn (Drupal 8 Flag module), and Adam Globus-Hoenich (Drupal module upgrader), and one other "mystery speaker" (hint: he loves bacon and pop-culture references) will be sharing their knowledge about several important areas of Drupal 8.

Submit your sessions

Florida DrupalCamp is now open for session proposals! Tracks include Design & Front-end Development, Development & Performance, Site-building, Project Management & Consulting, and sessions “Off the Drupal Island.” Submit your session today.


We take great pride in outfitting our local community with great swag. From expertly designed t-shirts and stickers to high-quality pins, the Florida Drupal Community loves to keep our users looking their best. This year will be no exception - in addition to a newly designed t-shirt, your registration fee will also get you a reusable Florida Drupal Diver grocery bag and swag from many of our sponsors - there might even be something special in there for everybody as well!


We have the best sponsors. Granted, many of our sponsors also sponsor other Drupal event around the world, but their generosity really shines at Florida DrupalCamp. This year's 17 cash sponsors (and counting) are providing a record amount for our event. Attendees should be sure to take a few minutes and talk with a few of them to say "thanks"! This year's sponsors include: Acquia, OSTraining, Trellon, Mediacurrent, Blink Reaction, Pantheon, Digital Frontiers Media, Big Couch Media, True North Custom, Drupalize.Me, Hot Sauce Design, Code Journeymen, CloudNYNE, WebEnabled, Chapter Three, New Valley Media, and Jay Epstein, LLC. We also have a mystery top-level Platinum sponsor that will be making a big announcement at Florida DrupalCamp. In addition, Florida Technical College and the Central Florida Computer Society continue to be the best venue and fiscal sponsors in all the land!

Trackback URL for this post:


Jan 08 2015
Jan 08

Nimble Monkey

Since we have ramped up our training business over the past months, I've been teaching a lot of Drupal to a lot of different types of people with various backgrounds, goals and motivations. As diverse as they may be, from private client training engagements for some of the largest Drupal shops to our own 12-week Drupal Career Online to now providing the technical curriculum for Acquia U, one training element that spans audiences and is continually driven home is the importance of being nimble.

With every training that I do, I always start by learning as much about the students as possible, with a special focus on their current level of knowledge as well as their expectations of the training. I've found that most people new to Drupal have one thing in common: they usually vastly underestimate how deep and wide Drupal really is. Especially for shorter-term beginner training events where students hope to learn all there is to know, this is sobering when they realize that Drupal is a much bigger universe than they originally thought.

Managing expectations for training events of this type is tricky. Often students go into technical trainings thinking that in a week they'll know everything there is to know about the subject, while in reality the situation is almost always much different. Readjusting these expectations as early and as gently as possible is often the key to a successful training.

Also critical is being able to adjust the curriculum based on differing expectations. Training a group of people coming from another content management system or framework is very different than training a class that is completely new to content management systems. Training a group comprised of both is even trickier. Adjusting curriculum on the fly is key, which is why our curriculum has depth and breadth, so it can accommodate the element of adjustability.

The current Acquia U program is a perfect example. With 10 students of varying degrees of experience, how do you present classroom lessons on topics that some students already have practical experience with? Of the 10 students, about half of the students have experience using Drupal regularly in a content administrator role, and several have experience building Drupal sites. We also have students for whom Drupal is brand-new. The difficulty is clearly presenting lessons that challenge some students while also providing the basics to those that require it.

I often use two different strategies to mitigate the issue: challenge exercises and student teaching. Challenging students who are ahead of the curve is a great way to keep them engaged in the class while at the same time satisfying their thirst for knowledge. Having curriculum that can support these types of challenge exercises without overwhelming the rest of the class is difficult, at best, to achieve.

Tasking ahead-of-the-curve students with teaching and/or demoing a portion of the lesson is also another effective technique. Many people believe that the best way to gauge your understanding of a topic is to explain it to someone else. By moving students from the "learner" to the "teacher" role, it keeps everyone engaged, and can often spot gaps in knowledge for some students.

Our DrupalEasy curriculum was written from the ground up with exactly this type of nimbleness in mind. We know that providing textbook, robotic training is usually not what any of our clients are looking for. The ability to read the situation and adjust on the fly to give our clients the biggest bang for their buck is something that we're betting will continue to help us grow our training business in the future.

Trackback URL for this post:


Sep 21 2014
Sep 21

Wildebeest Migration

Migrating from major version to major version of Drupal core has always been a significantly large task for all but the simplest sites. The upgrade path that has traditionally been part of Drupal core has always been limited in what it can do, so most sites were forced to use alternative methods to migrate configuration and content. Sometimes these migrations were manual, sometimes automated, and most often a combination of the two.

Drupal 8 aims to greatly reduce the friction of migrating sites from Drupal 6 and Drupal 7 by adopting a proven and extensible approach to site migrations. The Migrate module has been the go-to tool for migrating a large number of sites to Drupal 7 from earlier versions of Drupal as well as from other content management systems (including custom ones.)

This blog post aims to provide an overview of how the migration system in Drupal 8 works, our current progress, and how new contributors can get involved. The Migrate in Core initiative began in earnest about a year ago at DrupalCon Prague, when it was decided to use some code and concepts from the Migrate and Drupal-to-Drupal Data Migration modules as a starting point for a new and improved upgrade path.

At the current time, the Drupal 6 to Drupal 8 migration is almost complete, while the Drupal 7 to Drupal 8 migration is just getting started. There are a few blocking issues that we're trying to get past in the next couple of weeks (including files migration and link field migration). We feel that we'll be able to leverage much of the work we've done on the Drupal 6 to Drupal 8 migration for the Drupal 7 to Drupal 8 migration. In fact, we have a great issue for a new contributor to help us kick of the Drupal 7 work just waiting for someone to tackle.

The Drupal 7 Migrate and Drupal-to-Drupal Data Migration modules have inspired the Drupal 8 "Migrate" and "Migrate Drupal" core modules. Before we get into some of the details of how things work, it is important to note that these two modules differ from their Drupal 7 counterparts in many ways, but perhaps none more importantly than the fact that they are designed to migrate both content and configuration. This significantly increased the complexity of these modules, but was a requirement to provide functionality above and beyond previous major Drupal version upgrade paths.

Similar to previous upgrade paths, the Drupal 8 "Migrate Drupal" core module is designed to migrate only core content and configuration to Drupal 8. Contributed module maintainers are responsible for providing migration classes for data that they manage. For example, if you have Panels on your Drupal 7 site, these won't be migrated by the Migrate Drupal module, rather the Panels maintainers will have to add migration classes that include the logic for migrating Panels-related data to Drupal 8.

Of course, there are caveats for this "core only" migration approach - in the Drupal 6 to Drupal 8 migration, we've also included migrations for "core CCK" and the Link modules. Furthermore, there's a rumor that work is ongoing on migration classes for Views data.

If you're familiar with the Drupal 7 version of the Migrate module, many of the concepts of the Drupal 8 core Migrate and Migrate Drupal will be familiar, but most of them have been implemented in vastly different ways. This is most evident in the use of Drupal 8 configuration (.yml) files. These per-migration configuration files specify the various plugins that are used for each aspect of the migration, including defining the source data, the "process pipeline", and the destination.

For example, here's the configuration for the a taxonomy vocabulary migration (core/modules/migrate_drupal/config/install/migrate.migration.d6_taxonomy_vocabulary.yml):

id: d6_taxonomy_vocabulary
label: Drupal 6 taxonomy vocabularies
  - Drupal 6
  plugin: d6_taxonomy_vocabulary
      plugin: machine_name
      source: name
      plugin: dedupe_entity
      entity_type: taxonomy_vocabulary
      field: vid
      length: 32
  label: name
  name: name
  description: description
  hierarchy: hierarchy
  weight: weight
  plugin: entity:taxonomy_vocabulary

Parsing this configuration section-by-section:

id: d6_taxonomy_vocabulary
label: Drupal 6 taxonomy vocabularies

The "id" is the unique identifier for the migration. This is used in an annotation on the source plugin as well as an identifier in dependent migrations. The "label" is simply a friendly name for the migration.

  - Drupal 6

Similar to the Drupal 7 Migrate module, migrations can be placed into groups for organization and querying. For example, “run all the ‘Drupal 6’ migrations.”.

  plugin: d6_taxonomy_vocabulary

The "source" identifies the Drupal 8 migration plugin that is responsible for gathering the data from the source database. In this case, it is referring to the "Vocabulary" migration class (core/modules/migrate_drupal/src/Plugin/migrate/source/d6/Vocabulary.php), with the @MigrateSource annotation in that file linking the configuration file with the class. Like the Drupal 7 Migrate module, the source plugin passes data one row at a time to the process pipeline.

      plugin: machine_name
      source: name
      plugin: dedupe_entity
      entity_type: taxonomy_vocabulary
      field: vid
      length: 32
  label: name
  name: name
  description: description
  hierarchy: hierarchy
  weight: weight

The "process" section is where much of the real work happens. In this section, fields are mapped from the source to the destination, and various "process plugins" can modify the data as it moves from source to destination. There are various process plugins available for use, and custom plugins can also be added as necessary. Similar to field mapping classes in the Drupal 7 version of the Migrate module, the format of this section is {destination field name}: {source field name}. The "get" process plugin is used by default to get the field data from the source class, so in the case of "label: name" in the example above, this is actually using the "get" plugin to grab the "name" field from the source and assigning it to the "label" field on the destination.

As data needs to be manipulated between source and destination, additional process plugins can be utilized. In this example, "vid" field is set by first using the implicit "get" plug to grab the value of the "name" field from the source, then is it processed by the machine_name plugin (which ensures it is suitable to be a machine name), followed by the dedupe entity plugin which ensures it isn't a duplicate of another vid.

  plugin: entity:taxonomy_vocabulary

Finally, the destination plugin is specified; all processed data from the source is passed to the destination plugin that ultimately saves it to the Drupal 8 database.

If that much makes sense, then you're well on your way to understanding how Migrate in Core works. There are currently 85 different migrations defined for Drupal 6, each one works in a similar manner to the example above.

In future blog posts, we'll dive down a bit further into the actual mechanics of how a migration is run, the relationship between the Drupal 8 Migrate and Migrate Drupal modules, and how to create your own migration classes (pay attention module maintainers!)

If you can't wait, there's already some helpful documentation available for how the Drupal 8 migrate system works, we'll be updating it as the initiative progresses. If you have any questions, pop into the #drupal-migrate IRC channel and ask away.

Finally, if you're interested in helping out with the Migrate in Core initiative, we're always looking for help testing, documenting, organizing the issue queue, helping out in #drupal-migrate, and (of course) coding.

Trackback URL for this post:


Sep 17 2014
Sep 17

DrupalCon code sprint photo

Have you always wanted to get involved with Drupal core development but don’t know where to begin? Have a Drupal 6 site that you’re looking to upgrade to Drupal 8? The Drupal 8 Migrate in Core initiative aims to provide a robust and extensible migration path from Drupal 6 and Drupal 7 to Drupal 8. A lot of work has already been done, but we’re looking to increase our throughput by training up some testers and developers to contribute to the cause.

To that end, we’ve planned two in-person events and an ongoing virtual event where you can get some facetime with other contributors to get you up-to-speed on the current progress and how you can help. Development experience isn’t required! It takes all types of contributors to complete a project of this scope. We have opportunities for manual testing, documentation writing, UX, theming, patch testing, and patch creating. If you need more of a challenge, I’m sure that chx, benjy, and mikeryan can find something for you to sink your teeth into!

If you can’t wait to get started, please check out how you can properly configure your system in order to contribute. Even if you just want to do some manual testing, you’ll want to check this out. Once your system is ready to go, then find me in IRC (#drupal-migrate) or find us at an upcoming event.

DrupalCon Amsterdam

Ryan Weal will be the team leader on the ground at DrupalCon Amsterdam. He’ll be camped out at the official sprint locations on the extended sprint days as well as the day prior and after the ‘con (September 27, 28, 29 and October 3, 4, 5). Friday, October 3 is traditionally the largest sprint day of them all, so if you have any experience with contributing to Drupal core, let Ryan know and he’ll likely put you to work helping out new contributors.

Christian López Espínola (penyaskito) will also be attending the Amsterdam sprints in-person, focusing on Migrate in Core multilingual issues. If you’ve got a Drupal 6 or 7 multilingual site that you’re thinking about migrating to Drupal 8, now is a great time to get ahead-of-the-curve.

If you’re planning on attending and participating in the sprints, please be sure to sign up on the Sprint Attendance doc (find the “Migration testing” section). A number of the main contributors will be participating virtually, so we hope to make some good progress during this sprint.

DrupalCamp Atlanta

On Saturday, October 4, at DrupalCamp Atlanta, I’ll be leading another sprint that aims to kickstart new contributors into on-going roles in the Migrate in Core project. I’m planning on working with volunteers to get them up-to-speed with the overall migration system, and matching their skills up with current tasks including manual testing as well as testing and creating patches. I’ll also be presenting a session at the camp on the current status of Migrate in Core in Drupal 8 that should provide a good primer for those thinking about helping out.

Virtual Drupal 8 Migrate in Core Office Hours

I’m living proof that best intentions often go awry. Over the past several years, I’ve flirted with core contributions, but it wasn’t until I found a few nice folks to show me the ropes for the first few weeks that I was hooked. My goal is to repeat the process I went through for as many people as possible (hopefully with much fewer pain-points though!)

With that in mind, I’m happy to announce that starting Wednesday, September 24, I’ll be hosting virtual office hours for new Migrate in Core contributors. If you’re interested, please use the contact form or hit me up @ultimike to let me know and I’ll get you all the details. I’m planning on running it from 7-9pm EDT. Immediately following, at 9pm EDT on Wednesday evenings is the weekly Migrate in Core Google+ Hangout where we do a quick overview of the current state of the project.

Let’s Get This Done!

I’m planning on writing a series of blog posts to help new contributors compress the amount of time it takes them to have a good understanding of how the migration system works under-the-hood. Look for the first post next week.

The Migrate in Core project is destined to radically increase the adoption rate of Drupal 8, especially for Drupal 6 sites that are getting a bit long in the tooth. By getting some experience with it early, you’ll be in a great position to help existing and future clients in making the move to Drupal 8.

Photo by Mike Gifford

Trackback URL for this post:


Sep 16 2014
Sep 16

Pros and Cons

Since we started our long-form Drupal Career Starter Program in 2011, we've always struggled a bit trying to find a single local Apache-MySql-PHP stack that is powerful enough for day-to-day Drupal development, easy to set up, and that works for a wide range of people new to local web development.

We're always on the lookout for a local Drupal development stack that will help to reinforce the lessons and best practices that we strive to instill in all of our students. It's pointless to teach students methods and processes that aren't typically found in the community, so being able to bring students up-to-speed as quickly as possible with things like Drush, Git, and commonly-used workflows is of the utmost importance.

Generally, we've stuck with a combination of Acquia Dev Desktop (version 1), Uniform Server, and DrupalPro, depending on each student's skill level and previous experience.

Until recently, we've always had more Windows users than Mac or Linux users (combined!), and usually didn't run into any problems until we introduced Drush, Git, and other Linux-y command line tools, at which point Mac and Linux users spent a lot of time attempting to help Windows users get Drush installed.

When Acquia Dev Desktop 2 was made available, the list of features definitely piqued our interest. Integration with Acquia Cloud is nice (similar to what Kalabox does for Pantheon), but what we were really excited about was the Drush integration.

Since we are using Acquia Dev Desktop 2 for the first time with our 2014 Fall Drupal Career Online program, we thought it would make sense to run through the pros and cons from a training perspective.

The following list of pros/cons is based on Acquia Dev Desktop 2 Beta (Aug 15, 2014).


Drush integration

Holy cow, this is a game-changer for us. Acquia Dev Desktop 2 includes Drush 7.x integration for both Mac and Windows pre-installed. Integration on the Mac is independent of any other Drush installation that already exists on the machine. Integration on Windows isn't perfect (it uses the DOS command window rather than a Linux-style shell), but it is more than adequate for people new to Drupal. In both cases, a Drush prompt can be brought up from the site you're working with in the Acquia Dev Desktop interface.

Acquia Dev Desktop Drush integration

Easy setup for new site builders

Being able to point someone to a single download link and say "install this" and having a local Drupal site up-and-running in a matter of minutes is a huge advantage when working with students new to Drupal. The ability to jump right in to adding content, exploring Drupal's "big five" fundamentals, and installing new modules before having to describe the parts of an *AMP stack is a huge advantage for instructors. We've experimented with giving all students a Drupal install on a remote server somewhere, but nothing beats a local site (especially where fast, reliable WiFi is a variable).

Easy site importing

The ability to point Acquia Dev Desktop to a local codebase and SQL dump file and have everything "sucked in" and a virtual host record created is also a big advantage when dealing with students new to Drupal. It is vitally important to keep students' confidence levels high, and having to dive deep into the weeds of httpd.conf files in order to import a site can bring a classroom's "flow" to a grinding halt.

No more multi-site

One of my big complaints about the first version of Acquia Dev Desktop was that it used Drupal's multisite capabilities by default for all sites created using the "New site" functionality. While technically fine, I found it to be counter-intuitive for students and not really in-sync with the way that Drupal professionals generally work. Thankfully, this is no longer the case in Acquia Dev Desktop 2.

Acquia Cloud integration

Acquia Dev Desktop 2 (smartly) integrates with Acquia Cloud hosting, allowing site builders the ability to push and pull databases, files, and code between a local site managed by Acquia Dev Desktop 2 and dev/stage/production sites hosted on Acquia Cloud. While this feature requires Git (which doesn't come with Acquia Dev Desktop - it must be installed separately), it does make it quite easy to sync a local site with a dev/stage/production site. From a developer standpoint, this is all good.

Acquia Dev Desktop Cloud integration


Acquia Cloud integration

See what I did there? I actually only have one "con" for Acquia Dev Desktop 2's Acquia Cloud integration from a functionality standpoint - and that is that there are no warnings when a user attempts to push data and/or files from their local up to the dev/stage/production Acquia Cloud sites. Most Drupal developers I know work with a "code flows up, data flows down" mentality, and pushing a local database up is generally not a good practice. It would be nice if Acquia Dev Desktop provided a little "are you sure?" nudge in these situations.

The other issue I have for Acquia Cloud integration is that, from a teaching standpoint, it is too easy to use (stay with me here for a minute). I find that when I teach students the manual way of doing something before the automated way, the students are a lot less likely to get into trouble with the automated way. For example, I always have students download, uncompress, move, and enable contrib modules and themes manually for a couple of weeks before showing them "drush dl" and "drush en". Similarly, when teaching how to move sites around from their local to a server, we'll talk about doing it via FTP (which tends to be the lowest common denominator that everyone understands), but then teach it using basic Git commands with a single branch. So, is this actually a knock on Acquia Dev Desktop 2? Probably not, but as a Drupal trainer, I'll need to be extra-sure that our students learn what is going on under the hood before clicking the "Local workflow" options.


So far, there's a lot to like from a training standpoint in Acquia Dev Desktop 2. I don't use it for my day-to-day consulting work, but for introductory training, I'm not sure there are any other options that are as easy to get set up for such a wide range of users.

Trackback URL for this post:


Jan 27 2014
Jan 27

Average: 5 (1 vote)

FLDC home page

For the sixth consecutive year, Florida DrupalCamp will be one of the largest gathering of Drupal users in the southeast United States. Taking place on Saturday, March 8 (sessions) and Sunday, March 9 (community day), there’s no better way to level-up your skills, network with the Drupal community, and to remind you how awesome it is to be involved with this amazing project. Along with numerous other organizations, DrupalEasy is once again proud to help to sponsor and organize Florida DrupalCamp. Our amazing team of organizers from around the state (as from outside of Florida as well!) has decided to rethink a couple of the standard DrupalCamp “things” in an effort to make the event more productive for attendees and sponsors.

First off, say “goodbye” to a single keynote speaker - say “hello” to four amazing “featured speaker” sessions on four different Drupal 8 topics. Rather than trying to find a single keynote speaker and topic that would appeal to everybody, we decided to focus on getting our community up-to-speed with Drupal 8 by creating a day-long track with some of the main contributors of Drupal 8. We’ve already announced that Jen Lampton and Larry Garfield will be providing double-length sessions on twig and Drupal 8 development, respectively. Over the next two weeks we’ll be announcing two more awesome “mystery” speakers that will complete our Drupal 8 track.

Anyone who has attended a DrupalCamp knows that the sessions go a long way toward deciding if a camp is worth the time, travel, and expense. While we’ve always allowed community members to submit session proposals for sessions they’d like to give, this year we’re adding a new option - the ability for attendees to propose sessions that they’d like to see. If you’re looking to attend our camp, and there’s something you’d like to see presented, request a session, and we’ll do our best to find a community member to present on the most popular requests.

Registration and session proposals are now open, the early-bird price to register is $25 - don’t delay, because we’ll be raising it soon (but we’re not going to tell you when). Your ticket gets you a camp t-shirt, entrance into all the sessions, and food and drinks throughout the day (and possibly unlimited bacon). Head on over to the coolest DrupalCamp web site you’ve ever seen to reserve your spot.

On Sunday, March 9, we’ll be having our annual “community day”, where we’ll be working with select local non-profit organizations in our Coding for a Cause effort to help build (or re-build) their web sites on Drupal. We’ll also have multiple code sprints and opportunities for you to learn how to increase your streed-cred by contributing your knowledge back to the Drupal community.

Florida DrupalCamp 2014 will be our second year in a row at the Florida Technical College (FTC). Conveniently located in east Orlando, FTC provides loads of free parking, easy access to major highways, and a staff that couldn’t be happier to help us welcome Drupalers from near and far.

Once again, Drupal-related organizations from all over the country have shown their support for Florida DrupalCamp by providing generous sponsorships. Mediacurrent is once again a Platinum sponsor, while Mandrill, Digital Frontiers Media, Lingotek, and Big Couch Media Group are our Gold sponsors. Sponsorship opportunities are still available - we’d love to have your organization participate and benefit from Florida DrupalCamp 2014.

Trackback URL for this post:


Nov 24 2013
Nov 24

Average: 5 (2 votes)

I teach Drupal to a lot of people. One thing I have learned, is that whether I'm teaching people who are so new that they're still learning how to pronounce "Drupal" or I'm teaching current users the intricacies of the Migrate module, there's one common thread: without a solid understanding of Drupal's "Big Five", students will have trouble gaining the confidence that all Drupal developers, themers, site-builders, and anyone else who interacts with Drupal on a daily basis need.

The "Big Five" came about while I prepared materials for the Drupal Career Starter Program's (DCSP) second go-around (we're now accepting applications for our fourth session). I realized that I needed to name the milestone that I felt all of our students needed to attain before moving on to more advanced material. It didn't make any sense to introduce modules like Views or Panels, let alone introductions to module or theme development if students weren't solid on fundamental concepts.

The "Big Five" gives a name to the goal that students learning Drupal need to strive for, along with a mental checklist and milestones that give them a sense of accomplishment and confidence as they progressed. Providing a mechanism for students to gain confidence as the course progresses is something that I continue to focus on in both our long-form courses as well as our full- and half-day workshops.

If you're reading this, then you're probably not going to be surprised by the "Big Five" (in no particular order):

  • Content types
  • Users/roles/permissions
  • Taxonomy
  • Blocks/regions
  • Menus

So, how is the DCSP designed to teach these concepts in a way that makes them second nature to our students? The curriculum starts off with simple concepts and examples, each one designed to encounter a hurdle that can be solved with something from the "Big Five". For example, in one of the first lessons we create a new "basic page". Once complete, like clockwork, at least one student will ask, "but how do I link to this page from the main menu". Boom. We have a question with a solution that allows us to (semi-)naturally introduce Drupal menus and menu items. By cleverly designing exercises that lead to moments like this, the "Big Five" are almost always introduced as a solution to students' queries.

Of course, repetition plays a key part in hammering home the importance of these fundamentals. With the DCSP, we have the luxury of having five weeks that focus on topics that I feel everyone involved in Drupal site-building should know backwards and forwards. We are constantly revisiting/reusing concepts involving the "Big Five" over these five weeks, adding a small bit of complexity (usually in the form of a contribued module) at most opportunities.

The final piece in the puzzle is encouragement and confidence-building. By referring to the "Big Five" and their importance at every opportunity, we try to create a situation where students can gauge their own progress along the path by mentally checking off which of the "Big Five" they have confidence with and which ones they need to focus more time on. I encourage students to teach each other - if one student isn't understanding how to link a vocabulary to a content type, rather than explaining it myself, I'll ask one of their fellow students to explain it. This usually kills two birds with one stone - one student learns, the other gains confidence. Often, the student doing the explaining does a better job than I do since their knowledge is new, and they've just had the experience of learning the particular concept.

Teaching Drupal's "Big Five" in a full- or half-day workshop is challenging. There's barely enough time to give each topic it's due, and providing opportunities for repetition can be challenging. For our full-day workshops, we normally limit the course material to just Drupal core and some indespensible modules. There's no doubt in my mind Drupal 8 will make this easier for both instructors and students.

DrupalEasy provides public and private, online and in-person web-development career training and professional development workshops on topics from the basics of HTML and CSS, Responsive web design, fundamentals of Drupal site-building, the Views module, data migration into Drupal, as well as module and theme development. Contact us for more information, or check out our list of available workshops.

Trackback URL for this post:


Nov 01 2013
Nov 01

Average: 5 (2 votes)

FLDC2014 Coasters

The Florida Drupal Users' Group is pleased to announced that the sixth annual Florida DrupalCamp (FLDC) will take place on Saturday, March 8, 2014 on the campus of beautiful Rollins College in Winter Park, Florida. Be sure to save this date in your calendar and make plans to join us for Florida's largest annual gathering of Drupal professionals, hobbyists, and newbies. Be sure to join our mailing list at fldrupalcamp.org or follow us at @fldruaplcamp for registration and session proposal information as it becomes available.

For the past two years, FLDC has attracted over 300 people for a full day of learning, networking, and plenty of surprises. For this year's camp, we're planning 5-7 simultaneous tracks, more giveaways, higher quality speakers, and the best DrupalCamp swag on the planet.

We got a jump on promoting FLDC2014 at the recent DrupalCamp Atlanta, where we handed out exclusive save-the-date drink coasters at the afterparty.

Winter Park is a suburb of Orlando, and Rollins College is situated in its quaint downtown area. We've been lucky enough to have two previous FLDCs at this venue, and we're exciting about returning this time around. Working with Rollins' Philanthropy and Non-profit Leadership Center, we're excited to be planning a track that specifically caters to the needs of non-profit organizations using Drupal.

Interested in helping out in the planning and organizing of FLDC2014? Contact us and we'll add you to the team!

Trackback URL for this post:


Sep 24 2013
Sep 24

Average: 4.3 (3 votes)

Most Drupal shops always seem to have a few pet projects on the to-do list that are perpetually 2-3 months off - those pesky bill-paying client projects always seem to get in the way. If only there was some way to throw some person-hours at them as a way of gaining some momentum and making some progress. It's actually not that difficult to find the right developer (if you know where to look), the payoff could be great (especially if it can be an additional revenue stream for your organization), and it could help max out your karma score.

tl;dr: We're getting ready to graduate 18 such developers - contact me if you'd like to see if one of them is a good fit for your organization.

Bringing on a new Drupal developer who is hungry for experience could be the perfect solution since many of the posted job openings for Drupal talent are for (seemingly) everything but junior developers.

A quick, wildly unscientific review of the 30 most recent jobs postings on groups.drupal.org/jobs shows that 23 of the 30 listed positions specified an experience level of at least a "mid-level" Drupal developer. 5 of the positions didn't specify exactly what experience level was necessary, and 2 of the positions were posted in languages that I don't speak.

This all begs the question: where does a new Drupal site builder get 2-3 years of experience so that they can be eligible for many of the posted positions? It's a classic chicken-and-egg problem. There is a good number of developers willing to put in the work to become experienced Drupal developers, but a willing infrastructure needs to exist to make it happen.

Luckily, helping to grow trained Drupal talent isn't nearly as difficult as it seems. All it usually takes is a few hours per week of guidance to help keep new developers on-track and gaining confidence. What if you could hire a new Drupal developer to start chipping away at your organization's pet projects under the guidance of more seasoned developers? It's a classic win-win situation.

As someone who has some experience in working with new Drupal developers, I can attest to the fact that we've had more than a few success stories where our graduates worked these types of pet projects. By far the most successful were those that had regular interactions with experienced developers. Examples of some of these projects include:

  • Demonstration sites for potential clients.
  • The host organization's own web site migration/rebuilding.
  • Low- or zero-income bartered sites.
  • DrupalCamp sites.
  • Proof-of-concept sites.
  • Low-priority data migrations.

Intrigued yet? The Space Coast Drupal Career Starter Program Class of 2013 will be graduating in a few weeks. Why not help develop some new Drupal talent while getting something in return. Contact us if you'd like to review the credentials of our graduates to see if one of them might be a good fit for one of your organization's pet project.

Trackback URL for this post:


May 09 2013
May 09

Average: 5 (3 votes)

I rencently spent a few quality hours with the Views interface trying to figure out how to add an Organic Groups Group ID contextual filter to a Views display and have the display's title overridden based on the value of the contextual filter. Actually, it's easy to do if you don't mind having the actual Group ID integer in the title. But, like most people, I actually wanted the Group name in the title of my display.

It took me more time that I'd care to admit, as well as some guidance from the most excellent maintainer of the Organic Groups module, Amitai Burstein, but eventually, I discovered a simple solution that didn't involve additional relationships, contextual filters, fields, or trickery. Well - maybe not the "trickery" part. The solution involved what I consider to be a previously undocumented feature (at least to me!) of the Views module.

original contextual filter settings

When I first set up the view, I knew that the incoming values of the contextual filter (Group ID) were going to be integers (they are IDs, and this is Drupal after all). I needed to figure out how to override the title so that the Group ID wasn't used in the title, but rather the Group name was displayed. After all, I didn't want the resulting title to be "12341 Happenings" (where "12341" is the Group ID), rather I wanted the title to be "Miami Happenings" (where "Miami" is the Group name whose Group ID is "12341"). I was hoping that this would happen automatically, but it did not.

I spent several hours toying with various potential solutions - everything from using the display's Format|Grouping functionality to adding an additional relationship and using the "Content: title" field as the contexual filter instead of the Group ID (while the second option basically worked, it could have led to issues if there were multiple groups with the same name or funky characters in group names). Nothing I tried worked as well, or was bullet-proof enough to my liking.

It wasn't until Amitai told me that if I use Group ID as the contextual filter, I can override the title in the contextual filter's settings and Views will automatically substitute the Group ID with the Group title as long as the contextual filter is validated! That is, if I select the "Specify validation criteria" option in the contextual filter's settings and validate it using the (in my case) "OG group" validator, and Views will magically make the substitution. Seriously!

original contextual filter settings

When I was first informed of this, I was both overjoyed (that my issue had been solved) and aghast (at the incredibly non-obviousness of the solution). I've been around Drupal for quite some time, and this was one "feature" that had snuck past me. There isn't a clue in the Views interface about this functionality (in the maintainers' defense I can't think of a good way to add this to the description of the "Override title" setting without adding at least three paragraphs), nor could I find any indication of it using Advanced Help (low-hanging fruit for a patch!) Ultimately, I went to the relevant Views documentation page and didn't see anything about it there as well. It's there now, I just added it a few minutes ago (I love open-source).

Views is a seriously complex module with lots of moving parts, written by volunteers that are much smarter than I am. I'm sure there's more "sneaky" functionality that I'll discover in the future, and I'm looking forward to it.

Trackback URL for this post:


Apr 29 2013
Apr 29

Average: 4.8 (8 votes)


At Florida DrupalCamp 2013, I presented a session that demonstrated how to utilize the Feeds, Feeds Tamper, Address field, Geofield, and other modules to create a fully-functional website for searching for Farmers Markets anywhere in the United States. While the session's intent was to inspire people as to what Drupal can do in a very short amount of time, this blog post will focus on the details of the process.

A few years ago, I built a similar presentation using world-wide earthquake data, importing into a Drupal 6 site using Table Wizard and displaying the data using the Mapstraction module. I must have given that presentation about half-a-dozen times over the course of a year or so at various meetups and camps, so I thought now was a good time to bring it up-to-date with modern (relatively-speaking) Drupal tools.

StopwatchBefore we get started, let me point out that the title is a lie. It's actually going to be more than 7,000 records, but I like the way the "5,000" and "45" play off each other. The first time I did this demonstration in front of an audience, it actually took me only 25 minutes, 26 seconds - the rest of the presentation time was taken up with some initial slides and furious betting on how long it would actually take me (the winner got a copy of Mapping with Drupal).

The Farmers Markets Source Data

Data.gov logoThe first step in a project like this is to find some good clean source data. I'm a big fan of the seemingly infinite supply of publically available data found on Data.gov, the United States' public repository of federal government data. After poking around for a bit of time (I'm embarassed to say exactly how much!), I stumbled upon the Farmers Markets Geographic Data - a Microsoft Excel-formatted dataset containing data on over 7,000 Farmers Markets all over the United States. The dataset contains names, descriptions, addresses, websites, and other details - most importantly, it contains the latitude and longitude for each location. While not mandatory, having the latitude and longitude data sure does make the process easier.

Farmers Markets spreadsheetInspecting the data in a spreadsheet, things looked pretty clean. Since I knew I needed to save the file in comma-separted-values (.csv) format, I did some very minor cleanup on it by doing the following:

  • Removed the top 3 descriptive header rows. For the import, all we actually need is a column/field name header row and the data. Any anciliary header rows need to be removed.
  • Removed the bottom 2 descriptive footer rows. For this dataset, there was a row at the bottom of the dataset that contained information about when the dataset was last updated. This wasn't needed for the import, so I manually deleted it.

Additionally, I took note of the following things:

  • The FMID field (I'm assuming this is an acronym for "farmers market identifier") appears to be a unique integer for each record in the dataset. This will come in handy during import.
  • There was no "country" field. This isn't unexpected since this was data for United States' farmers markets, but I did take note of it because the Address Field module will be looking for country data. I could have simply added a new "country" field (with all values set to "United States") to the dataset prior to exporting it as a .csv file, but I prefer to keep the dataset as "pure" as possible, so I decided to leave it alone for now and deal with the country stuff as part of the import process (see below).
  • The data in the "State" column included full state names, not the standard 2-letter abbreviations. I knew that this would need some tampering (via the Feeds Tamper) module to convert it so that it would import cleanly.
  • The "Schedule" field for some records is longer than 255 characters. This means that we'll have to use a "Long text" field type in the content type to handle the data in this field.
  • The data also included 20 "category"-type fields indicating the types of goods available at each farmer's market (eggs, cheese, soap, trees, etc...) Ideally, each of these 20 fields should be mapped to a single Drupal vocabulary. This would require a custom Feeds Tamper plugin.
  • The "lastUpdated" field mostly contains well-formatted dates, but because there are some records where the data is not well-formatted ("2009" instead of "mm/dd/yyyy") and it is just informational, its probably best just to use a text field in the content type for this data.

Once I was satisfied that the data was clean and I had a good understanding of it, I saved it as a .csv file and moved onto getting Drupal ready to import it.

Setting Up the Basic Site

As with most of the sites DrupalEasy builds, we started out with our own custom Drush make file that automatically downloads a bunch of standardish modules we use on every site as well as our own custom installation profile that does some initial site configuration (turning off the Overlay, enabling the Administration Menu module, etc...) This enables us to get a basic site up-and-running in just a few mintues.

Next, we need to download and enable the modules that we're going to need:

  • Geofield - be sure to use a version of the 7.x-2.x branch dated later than 2013-Apr-07

Depending on whether or not you start with our custom make file, there may be other modules that are dependencies of the ones listed above that will also need to be downloaded and enabled.

If you use Drush, the following command will enable all the necessary modules:

drush en addressfield feeds_ui feeds_tamper_ui geofield 
geofield_map job_scheduler feeds geophp rules_admin openlayers_ui

Creating the Farmers Market Content Type

Once the site is up-and-running, the first step is to set up something for all of the data to be imported into. In this case, hopefully it is obvious that we need to create a new content type with fields that roughly match the fields in our source file. By creating a node for each Farmers Market, once imported we can leverage all of the tools in the Drupal universe to interact with them as we build out the site.

Create a new content type (admin/structure/types/add) with the following properties (throughout this post, any properties/attributes/settings not specifically mentioned can be left at their default values):

  • Name: Farmers Market
  • Disable "Promoted to front page"
  • Disable "Main menu" from "Available menus"

Moving on to the fields (admin/structure/types/manage/farmers-market/fields):

  • Delete the "Body" field
  • Add "Address" field: type=Postal Address, Available countries=United States, enable "Hide the country when only one is available"
  • Add "Lat/Long" field: type=Geofield, Widget=Latitude/Longitude
  • Add "URL" field: type=Link, Link Title=No Title
  • Add "Location details" field: type=Text
  • Add "Schedule" field: type=Long text
  • Add "Last updated" field: type=Text

Farmers Markets content type

One thing to note is that once the import is complete, we're going to go ahead and enable the Geocoder module so that any Drupal-side address updates to any Farmers Market nodes will be automatically updated with the proper latitude/longitude coordinates. We don't want to enable this functionality prior to import otherwise the module will attempt to geocode each address from the source file during import. This is completely unecessary since the source file already includes latitude/longitude data. Plus, Google Geocoder limits non-paid users to 2,500 requests per day - unless you pay for more.

Creating the Importer

At this point, we have the source data (the .csv file) and the destination (the "Farmers Market" content type). The next step is to create the mechanism that will actually transfer the data from the source to the destination. We'll use the Feeds module to do this. The Feeds module is designed to take data from a variety of sources (most commonly RSS feeds and .csv files) and map it to Drupal entities (usually nodes, but not always).

Add a new importer (admin/structure/feeds) named "Farmers Markets Importer". The "Edit" page for importers has 4 major sections. Let's look at each one in detail.

Basic settings

This section consists of the general configuration of the importer. For this project, use the following settings:

  • Attach to content type = Use standalone form. Note that this isn't referring to were the content is going to go, it is referring to the importer itself. In our case, since we only have a single data source, a standalone form is fine. If were were planning on importing data from multiple sources, a custom importer content type might be necessary.
  • Periodic import = Off. This setting is primarily used for automatically checking a feed for new data. For a one-time .csv import, it is not necessary.
  • Import on submission = Enabled. This triggers the import to start whenever a new .csv file is uploaded on the main import (/import) page.


This section sets the mechanism that actually interacts with the source data. We need to change the Fetcher from "HTTP Fetcher" (commonly used for RSS feeds) to "File upload". Looking at the settings for the "File upload" fetcher, all the default values are fine, so no changes are necessary.


This section sets the process that will be used to parse the source data into a format that the "Processor" (next step) can understand. In our case, we need to change the Parser from "Common Syndication parser" to "CSV parser". Again, the default settings for the "CSV parser" are fine as-is. It is interesting to note that the Feeds module is easily extensible. Custom Fetchers, Parsers, and Processors can be written to handle virtually any type of incoming data.


This final section is were the parsed source data is mapped to the proper place in Drupal. In our case, the default "Node processor" is what we want (since we're mapping the data into our new "Farmers Market" content type). The settings for the Node processor are as follows:

  • Update existing nodes = Update existing nodes (slower than replacing them). This is a big win for us, and is only possible because of the FMID field in the source data. This means that when an updated source dataset is available, (assuming the field structure hasn't changed) we can simply re-run our importer on the new file and upload only the records that have changed. In other words, we won't have to delete (including any user comments and Drupal-side updates) and re-import Farmers Market nodes. This will allow us to keep the site up-to-date with a minimum of work.
  • Content type = Farmers Market. This is where we tell the importer that we're going to be generating nodes of the Farmers Market content type with the imported records. This is the first link between the source and destination.
  • Author = admin (or any user on your site). It's fine to leave it as "anonymous", but I'd rather have my nodes "owned" by an actual user.

The final (and most tedious) step is to set up the mapping of fields between the source and destination. In other words: data from each source fields needs to know which destination field it will go into. It is important to note here that the source field names must be entered exactly as they appear in the source data file. The mappings for this importer are (Source = Target):

  • MarketName = Title
  • FMID = GUID - set this field to "Unique" then be sure to click to "Save" the mapping.
  • Street = Address: Thoroughfare
  • City = Address: Locality
  • State = Address: Administrative area
  • Zip = Address: Postal code
  • x = Lat/Long Longitude
  • y = Lat/Long Latitude
  • Website = URL: URL
  • Location = Location details
  • Schedule = Schedule
  • updateTime = Last updated

Be sure to double-check that the "FMID" field is set to unique!

Farmers Markets content type

Massaging the Data

As I indicated in the "Farmers Markets Source Data" section above, there are a couple of things we need to do in order to get the dataset to import cleanly: set the default country ("United States") and translate the full state name to the 2-letter abbreviation ("New York" to "NY", for example).

Setting the Default Country

Setting the default country field for every record on import is actually a fairly simple operation to set up - assuming you're aware that the Feeds module exposes a "Before saving an item imported via [importer name]" event for each Feeds importer. This allows us to step in the middle of the import process and set a data value as we wish.

From the main Rules configuration page (admin/configure/workflow/rules), add a new rule named "Add default country for imported markets" that reacts on the "Before saving an item imported via Farmers Markets Importer" event.

Next, add an "Entity has field" condition with the Data selector=node and Field=field_address. This ensures that the country field exists (it is part of field_address) and (more importantly) is available for us to set its value in the next step.

Finally, add an "Set a data value" action with a Data selector=node:field-address:country and a Value=United States. Click to save everything it's done!

Add default country for imported markets rule

Translating the State Names

The second data issue that we need address during data import is that of the "State" field. We need a mechanism were we can automatically translate full state names into their 2-letter abbreviation. I turned to the Feeds Tamper module for this, as it is relatively straight-forward for a developer to create a custom plugin that can be assigned to any field via the Feeds Tamper interface. The source data is then run through the plugin code to make any necessary changes. Unfortunately, a plugin had to be written for this application - I have contributed it back to the community, but the module author has not acted on it as of April, 2013.

If you're not familiar with applying patches, feel free to download the state_to_abbrev_inc.zip file, uncompress it, and place it in your feeds_tamper/plugins directory.

Once the plugin is installed, it needs to be assiged to the "State" field. This is done by clicking "Tamper" link for our importer from the main "Feed importers" page (admin/structure/feeds). Then, add the "Full U.S. state name to abbrev" plugin to the "
State -> Address: Administrative area" field.

Tamper with the State field


At this point, everything is ready to proceed with the import. Navigate to the main "Import" page (/import) via the Navigation menu and click the "Farmers Markets Importer". Select the file to upload and click to "Import".

I like to test things with a small version of the main source file - one with only a handful of records. This is helpful in making sure everything is being imported correctly without having to wait for all 7,000+ records to be processed. I check things by inspecting a few of the newly created Farmers Market nodes, ensuring fields are populated as expected. If I'm satisfied, then I go ahead and run the import with the full data set.

On my particular local machine, importing all 7,000+ records took about 6 minutes.

Setting Up the Proximity Search

One of the features that really makes location-based content useful is proximity searches: being able to allow the user to "show me all the things near a particular location". For this example, we're going to use the built-in proximity functionality of the 7.x-2.x version of the Geofield module. We'll create a view that exposes a proximity filter that incorporates geocoding by allowing the user to enter any valid location data into the "origin" textfield. That is, the user can query for farmers markets within 10 miles of "Sacramento, CA", "06103", or "1600 Pennsylvania Ave, Washington, DC" - any text that the active Geocoder (usually Google Geocoder) can parse.

Exposed Views proximity filter

Once the import is complete, enable the Geocoder module. Then, create a new view named "Proximity search". On the initial views wizard page, "Show Content of type Farmers Market" (sorting doesn't matter yet). Create a page with a Display format" of "Geofield Map". Set the "Items to display" to 100 (just to make sure we never overwhelm the map with points), and disable the pager. On the main views interface:

  • Click to add the "Content: Lat/Long" field - exclude from display, Formatter=Latitude/Longitude
  • Click to add the "Content: Lat/Long - proximity" field - exclude from display, Source of Origin Point=Exposed Geofield Proximity Filter, Unit of Measure=Miles
  • Click to add the "Content: Lat/Long - proximity" filter - Expose this filter to visitors, enable "Remember the last selection", Operator=Is less than or equal to, Source of Origin Point=Geocoded Location. Be sure to add a default value for the exposed filter ("10 miles from New York, NY") or you may see a nasty little bug (http://drupal.org/node/1871510)
  • Remove the "Content: Post date" sort criteria
  • Edit the settings of the Geofield Map format: Data source=Lat/Long, Popup Text=title

Once complete, save the view, then navigate to the /proximity-search (or whatever URL you set for the page display of the view) and give it a whirl!

Proximity search

Pimping the Display (and Functionality) of Farmers Market Nodes

At this point, if you click on a Farmers Market pin, then click through to a particular Farmers Market node, the display of the node is less-than-impressive.

Initial Farmers Market node display

With just a little bit of effort, this can be greatly improved. We'll rearrange the order of fields, tweak the display a little bit, add a map, and incorporate Geocoder functionality for address updates.

OpenLayers Map

To keep things interesting, we're going to use the OpenLayers module for the map display on the individual Farmers Market nodes. First, we'll need to edit the OpenLayers map that we're going to utilize. Go to the main OpenLayers "Maps" page (admin/structure/openlayers/maps), and click to edit the geofield_formatter_map (the description of the map should explain why we're using this one - it is designed to handle the display of Geofield output). There's lots of available settings for each map, we'll only make a few small configuration changes:

  • Basics section: Width=auto, Height=250px
  • Layers and Styles section: only the "OMS Mapnik" layer should be enabled and set to default, set the styles for "Placeholder for Geofield Formatter" to "Marker Black Small"
  • Behaviors section: Point Zoom Level=14

Once the map is configured, we can utilize it on the Lat/Long field of our Farmers Market content type. Go to the "Manage Display" page (admin/structure/types/manage/farmers_market/display) and change the format of the "Lat/Long" field to OpenLayers. Click to save and test.

Reordering the Display Fields

While we're on the "Manage Display" page of the Farmers Market content type, rearrange the fields as follows:

  1. Lat/Long: Label=Hidden
  2. Location details: Label=Hidden
  3. Address: Label=Hidden
  4. URL: Label=Hidden
  5. Schedule: Label=Inline
  6. Last updated: Label=Inline

With these changes, things improve quite a bit.

Pimped Farmers Market node display

Enabling the Geocoder for Address Updates

Finally, now that all the data is imported, we can go back and modify the Lat/Long field to automatically be updated by the Geocoder module whenever the node is updated (in case the address changes). From the "Manage Fields" page for our content type (admin/structure/types/manage/farmers_market/fields), click the "Latitude/Longitude" widget for the "Lat/Long" field, change the widget to be "Geocode from another field", then continue to click to edit the field configuration and ensure the "Geocode from field" option is set to "Address". Click to save.

Are We Done?

At this point, we have a fully functional site where users can search for farmers markets near them, then click to view the details on ones that interest them. Since the farmers markets are nodes, we can leverage all the great modules available from Drupal.org to futher extend and enhance the site.

With just a few additional modules, a contribued (responsive) theme with just a few extra lines of CSS, and some publically available imagery, it's quite simple to produce a usable site - just like FarmersMarketsNow.com!

Extra Credit - Utilizing the Source Dataset's Category Fields

Still reading? Congrats - you're in it for the long haul. Wondering how we can leverage the category data from the source file? Here are the steps:

  1. Before creating the Farmers Market content type, create a new "Categories" vocabulary.
  2. Add a "Categories" term reference field to the Farmers Market content type and set the "Number of values" to "Unlimited".
  3. Install the taxonomy_inc.zip Feeds Tamper plugin in the feeds_tamper/plugins directory. This is a custom pluging that is specific to this particular source file. It takes data from all the category-type fields in the source file and imports them to the new "Categories" vocabulary.
  4. Add a new mapping field to the importer. The way the Feeds Tamper plugin was created, only one needs to be added. Use "Bakedgoods = Categories".
  5. Utilize the custom "Taxonomy Y/N" Feeds Tamper plugin on the "Bakedgoods -> Categories" field.

Rerun the import and see the magic! Note that the extra processing for the categories really slows down the import quite a bit. I'm sure that there are other ways of importing the category-type fields to a single vocabulary, let me know in the comments if you know of an easier method.

Trackback URL for this post:


AttachmentSize 1.21 KB 1.34 KB 763 bytes
Apr 24 2013
Apr 24

Average: 5 (1 vote)

Opening sessionFlorida DrupalCamp 2013 took place on April 20 and 21, 2013 at the Florida Technical College in Orlando, Florida. Attended by almost 300 people, the camp featured 42 sessions, a fantastic keynote by Ryan Szrama (rszrama), 30+ volunteers, great food by 4Rivers, and four lucky organizations who benefitted from the all-day Coding for a Cause event. This was central Florida's fifth consecutive annual camp, and by all indications was well-received by everybody who attended. As is our custom, this blog post will serve to wrap up all aspects of the camp, including things that we could (should?) have done better.

As with most Drupal events, our camp would not have happened without all the hard work from our all-volunteer staff. While the Florida Drupal Community is spread out over a state that takes 14 hours to drive from Pensacola to Key West, when it comes to organizing a camp, we act as one group with a common goal: to put on the best camp anywhere. With weekly conference calls starting months before the event to our constantly active Open Atrium group, our volunteers take ownership of their tasks and have always delivered.

Happy camperThis year's group of volunteers added a new wrinkle to our camp - a good number of the organizers hadn't participated in previous year's camps. With the guidance and encouragment of the other organizers, this "fresh blood" added welcome energy and ideas to our groups. One of these new members is Tom Nguyen (tom_nguyen), who found, secured, and managed communication with the venue for this year's camp. When our previous host informed us that they were unable to host the 2013 edition of the camp due to building renovations, we spent several long weeks talking about potential venues, but it wasn't until Tom stepped up and visited some potential locations that we gained real momentum.


We could not have been happier with Florida Technical College and their staff's willingness to work with us to make this event a success. While the venue wasn't perfect (the auditorium wasn't large enought to hold everyone), virtually everything else about it was ideal. A large, conveniently-placed student lounge, a virtually unlimited supply of classrooms equipped with projectors and screens, more-than-adequate WiFi (always a big concern), ample free parking, all while being compact enough to encourage networking and discussion. Did I mention that it was free? Amazing, we know. The staff couldn't have treated us nicer, and we look forward to working with them again in the future.


Pramod JainI'm really going to try to be unbiased about this next topic, but it's going to be difficult. I've been to many DrupalCamps up-and-down the East Coast of the United States (and one in Europe) and I really believe that this was the highest quality lineup of sessions that I've ever seen at a camp. Our keynote was given by Ryan Szrama, lead developer of Drupal Commerce and Commerce Guys' VP of Community Development. Our all-day beginner track was presented by OSTraining, in addition we had 35 other sessions on topics ranging from running a Drupal shop to CSS/SASS/Compass to module development to Drupal 8. Don Vandemark (caelon) worked tirelessly to reach out to high-quality speakers around (and outside) the state. In addition, Shaun Heath (heaths1 - another newbie) arranged for a (large) portion of the sessions to be recorded by Utzu Logigan (durasro) of Davram Tech and will be made available online (soon!)


Our largest headache with the camp was the registration system. We messed up big-time in launching the site too quickly without fully testing the registration system configuration. While it worked great for individuals registering themselves, it failed more than it worked with attempting to register more than one person at a time. While we did determine the issue a couple of weeks into ticket sales, we were nervous about making any changes and risking the possibility of making things worse. Therefore, it fell on one of our volunteers to patiently answer emails from people having issues with registration and walking them through the process. In addition to this, Mike Herchel (mherchel) was also in charge of the marketing for the camp, spending countless hours sending emails, reaching out to other tech groups, and getting the word out through all possible means. Mike also stepped in to help with numerous other tasks - every camp needs someone like him who just gets stuff done (no, you can't have him).


Doug Hercules - the giveaway refereeAs if our attendees weren't getting enough for their registration fee, we had an amazing group of in-kind sponsors that provided books, DVDs, and other merchandise that was used in giveaways during the camp. Our official Florida DrupalCamp giveaway referee, Doug Hercules (dhercjr - another newbie), ran around blowing his whistle and making people participate in silly games all while handing out almost $1,000 worth of merchandise, including over 50 Drupal-related books.

Web site

The Drupal 7, COD-based (Conference Organizing Distribution) web site was a hand-me-down from DrupalCamp Atlanta with new content and a new theme. The theme was designed by Mike Herchel (yeah, the same guy) and implemented by himself, Adam Varn (hotsaucedesign), Erik Baldwin (BLadwin), and Jason Taber (companyguy). The site featured some amazing CSS3 animations and a fantastic responsive design that made the online session schedule super-easy to use. Linda Cook (lscook) and Dennis Solis (densolis - another camp organizer newbie) wrote virtually all of the content for the site while Andrew Riley (Andrew M Riley) and John Learned (JCL324) configured the site for our camp. The big takeaway from this year's camp is to build and test the full functionality of the web site early. Really early. And test the pants off it.


When it comes to designing our camp, we take a holistic approach and have a separate design committee that oversees all printed and electronic material to ensure consistency and professionalism. Erik Baldwin led this committee, working with numerous other volunteers including Cielo Johnson (C13L0 - another newbie), Roland Riddell (rols), Sandy Milligan (sandym), Phil Smith (SiliconValet), David Cruz (dimmech), Dorothy Cleary (dbdot), and Dustin Cooper (dustinjcooper). The groups designed badges, printed schedules, signs, t-shirts, and swag bags - all branded with the Florida Drupal Diver.


t-shirtRoland Riddell also worked with the rest of the design committee to come up with a fantastic t-shirt design that tied all of our branding together. With the first-ever (someone check me on this) giant octopus gracing the front of our t-shirts, and a school of fish (sponsors) on the back, this year's t-shirt design is our best yet (so long, camper!) One of the original Florida Drupal Group members, Joe Moraca (joemoraca) found a suitable vendor and ensured we had the t-shirts on-time (thanks to Mike Herchel, again).


As with most Drupal events around the world, there's no way we could have provided all of this for $25 without the crazy-generous support of our sponsors. Topping them off is Mediacurrent - within 8 minutes of my sending a sponsorship request message to Dave Terry, he had claimed the Platinum sponsorship: an amazing way for us to start our fund-raising drive. Mediacurrent's close relationship with Florida (about 10 of their employees are Florida-based) is one that we value greatly. In addition, we had four Florida-based Gold sponsors: Educational Data Resources, Big Couch Media Group, Digital Frontiers Media, and Purple Rock Scissors. A full list of all sponsors can be found at http://fldrupalcamp.org/sponsors. All told, our sponsors provided over $10,000, and we can't thank them enough.

Fiscal Partner

For the fourth year in a row, the Central Florida Computer Society acted as our fiscal partner. Bringing us in under their 501(c)(3) umbrella, providing accounting support, and providing the most friendly day-of volunteers we could ask for. It's a continuing partnership that we value greatly.


The overall budget for Florida DrupalCamp 2013 was a bit more than $16,000. Income came from sponsors (approximately 70%) and ticket sales. Once again, we managed to keep ticket prices at a minumum, offering an earlybird price ($20) to about half of the registrants, and including food, t-shirt, and a recyclable swag bag in the cost of a registration. Our largest expense was food (~$8,000), followed by session recordings (~$3,000), and t-shirts (~$2,500). The remainder of the expenses were for printing, marketing, and miscelleanous expenses. Overall, it looks like we'll have a small surplus that we'll use as seed money for future Florida Drupal events.


4Rivers cateringAs with other aspects of our local community, we are so lucky to have someone who volunteers to take on a task of this magnitude, then follows it through to the end, year-after-year. Angela Cacciola (PrincessAng417) once again took on the catering task, provided us with numerous options, put up with our ridiculous questions (seriously, why can't we have a milkshake bar?), and made it all look easy. This year's camp was catered by 4Rivers, a local BBQ resturant that was amazing. They provided a breakfast buffet (sorry we ran out of coffee!), a great lunch, snacks in the afternoon, and drinks all day. It was seemless, easy, and we had leftovers. Sweet.

Code Sprint

Albert Volkman (Albert Volkman) and Kevin Basarab (kbasarab) organized a full-day code sprint the day after the camp that mainly focused on Twig in Drupal 8 issues. A number of potential new contributors were on-ramped to reviewing issues, creating and reviewing patches, and the core contribution mentoring process.

Coding for a Cause

Ben Hosmer talking about Coding for a CauseOnce again, the Florida Drupal community was clear in their desire to give back to the community. This year, four non-profit organizations were selected to take part in our Coding for a Cause event, where volunteers get together for a full day of site building for each organization. Over 40 people participated in the event - check out this post for details on each organization's project. Ben Hosmer (bhosmer) led a team of volunteers in making it all happen, including project managers Maggie Ardito (marguerite), Ryan Price (liberatr), Robert Laszlo (laszlocore), and Dawn Borglund (dborglund).


The Florida Drupal Community continues to lead the way in organizing a completely volunteer planned and run event whose mission it is to spread knowledge and confidence in using Drupal. We recently sent out a survey to all attendees, I look foward to sharing the results of that survey in a future blog post, although I'm confident in what the results will show. Compared with our 2012 effort, we definitely improved in several areas:

  1. Caroline Achee (cachee), Karan Garske (karang) and Natalie Roberts (anzi31 - first time volunteer) ensured that our day-of registration lines flowed smoothly and quickly. Last year's was much less-than-ideal, and the changes we implemented this year (multiple lines, including two people dedicated to registration issues) were exactly what we needed.
  2. Don Vandemark found us a great location for our afterparty. It was more than large enough to hold all of us, provided reasonably-priced food and drink, as well as promoted networking that continued for hours after the sessions ended. This is something we'd lacked at previous camps, and the difference was amazing.
  3. We worked with the catering company to ensure there were multiple lines for everything to keep the traffic flow moving. Less waiting in lines meant more time for people to talk about Drupal!

Overall, it was a weekend that the Florida Drupal Community can be proud of!

Photos by Kevin Basarab, Hewie Poplock, Bryan Buxton, and myself (Michael Anello). Thanks to Doug Hercules for helping out with this post!

Trackback URL for this post:


Apr 21 2013
Apr 21

Average: 5 (2 votes)

Caught doing good braceletsFlorida DrupalCamp 2013 invited four local non-profit organizations to take part in our annual Coding for a Cause event. Held the day after the camp sessions, over 30 volunteers help with site-building, theming, and content management tasks for the lucky organizations.

This year's event focused on four local 501(c)(3) non-profits that were selected from the application process. Each selected organization was required to agree to:

  • work with a project manager prior to the event
  • attend a full day of beginner training sessions on Saturday
  • participate in the site-build on Sunday

The four organizations are:


An Orlando-based organization focusing on supporting recreation, education, and volunteer activities for elderly, disabled, and homeless persons. In addition to individual volunteer projects, Helpertunity's goal for 2013 is to advocate for technology access and mobile resources for care facilities (nursing homes, care shelters, and adult day programs) in Florida. Volunteers are creating a web site to allow donors to connect, learn, and build trust with the organziation so that on-going projects can continue and grow. http://www.helpertunity.org

East Coast Greenway (Florida Chapter)

A Florida-based chapter of the national East Coast Greenway organization focused on advocacy, support, and development of the 3,000 mile multi-use greenway route between Maine and Key West. The project involves creating a pilot web site whose goal is to futher engage and expand volunteer activity in trail-building and advocacy. The pilot web site will be focused on building community support for the Florida portion of the trail. http://www.helpertunity.org

Orlando Music Club

A Central Florida-based foundation that provides scholarships to students interested in studying music. They also provide music resources for teachers as well as a matching service putting students, teachers, and music resources together. Volunteers will be rebuilding their existing web site with a new design, updated content, and improved functionality. http://orlandomusicclub.org

Urban Rethink

Urban Rethink is an Orlando-based creative hub that focuses on co-working and community events as part of the Urban Think Foundation. The project consists of expanding their informational website to include user-generated content and social media-style pages for their co-working members. Specifically, an infrastructure for creating online photo albums will be built, and non-technical volunteers will be migrating photos from the past several years' worth of Urban Rethink events. In addition, the design of the site is being upgraded to be mobile- and tablet-friendly. http://urbanrethink.com/

Stay tuned to the @fldrupalcamp twitter feed for site launch announcements when available.

Trackback URL for this post:


Apr 05 2013
Apr 05

No votes yet

Florida Drupal DiverWe're trying something new this year at Florida DrupalCamp 2013 (Saturday, April 20 - tickets on sale now for just $25) and we're looking for some (financial) help to get it done.

We'd like to be able to record all sessions and post them online for the entire Drupal community. In order to do so effectively, we've decided to hire Davram Tech (contact me if you'd like to be put in touch with them) to take care of it for us. Utzu from Davram Tech has agreed to travel to our camp, record all the sessions, and upload them to a video hosting site of our choice. The interesting thing about it is that it is going to provide a valuable new sponsorship opportunity for our camp. The sponsorship of a session video will allow the sponsor to add branding to the start and finish of the video - as long as it remains online. This type of ongoing branding is surely worth much more than we're charging for it (more on that later).

Of course, hiring an organization to do all the work of recording sessions isn't free. In our case, it works out to about $150 per session. We raised a good deal of money from our amazing sponsors, but not quite enough to have full coverage of all sessions. So, we decided that, at a minimum, we're going to record 20 sessions. These 20 sessions will be sponsored by our existing Platinum, Gold, Silver, and Bronze sponsors. The remaining 16 (or so) session are officially up-for-grabs. We're looking for some additional sponsors to pony up $150 for each session video they'd like to sponsor. Interested? Let me know.

Here's the way it works: we're letting our current sponsors pick the sessions they'd like to sponsor. After that, it's first-come, first-serve. Want to get your organizations name permanently attached to a #fldc13 session video? Let me know.

Trackback URL for this post:


AttachmentSize 28.83 KB
Mar 15 2013
Mar 15

Average: 3 (2 votes)

I've been on the road a lot lately, touting the opportunities that Drupal offers to workforce and economic development efforts of regions and states. Thing is, before we can get to all the advantages for regions to develop a Drupal-talented workforce, we have to educate a lot of government leaders, commissions and committees on what Drupal is and does.  In short, they need to "get it." This means understanding not just what Drupal is used for, but why it is growing as quickly as it is.  Decision makers in many of our forums do not know what a content management system is, nor what open source means. That's a lot of ground to cover before we can even get to the whole training component!

So, in our usual DrupalEasy approach to making things more efficient, we created an under-three minute video that seems to meet our needs.  No audio as yet, but we are open to suggestions as to a voice over, or some open source diddy that might make it a bit more engaging.  Give it a look, and let us know what you think, what we can do to improve it, and how you might be able to use it.  Also, if you need to explain Drupal to anyone, feel free to pass it along.  DrupalEasy proudly presents... V1 of: What is Drupal?

Trackback URL for this post:


Mar 14 2013
Mar 14

Average: 3.5 (2 votes)

Florida Drupal DiverThe fifth annual Florida DrupalCamp is now open for registration! DrupalEasy is proud to be a sponsor for this year’s FLDC as well as being involved in the planning and execution of the camp through not only myself, but also through our network of contractors and graduates from our two local DrupalEasy Career Starter Program sessions. A full day of sessions on Saturday, April 20 as well as Coding for a Cause and a code sprint on Sunday, April 21 will provide ample learning, sharing, networking, and socializing opportunities for technologists interested in expanding their Drupal knowledge and network.

Over the past five years we’ve grown from a small (less than 100 people) event held in a sponsor’s office to one of the largest DrupalCamps in the southeast. This year we’re expecting well over 300 attendees at the Florida Technical College campus. For only $20 (early-bird price), attendees will be fed all day (by an amazing local caterer), be outfitted in one of the coolest DrupalCamp t-shirts I’ve seen (IMHO), be able to choose from six simulatenous tracks of sessions, and enjoy a keynote presentation by one of the nicest people in the Drupal community: Ryan Szrama of Commerce Guys.

Obviously, an event of this magnitude wouldn’t be affordable for many people without the participation of our extremely generous sponsors. Our Platinum sponsor, Mediacurrent - while based in Atlanta - employes a significant number of telecommuters who live in Florida. Within minutes of my contacting them about being a sponsor for FLDC, they had committed to being our top-level sponsor.

For the past few years, we’ve worked with the Central Florida Computer Society as our fiscal sponsor. In addition to acting as our sponsor 501(c)(3) organization, they generously provide us with accounting support and a small army of volunteers the day of the camp.

With our usual venue currently undergoing renovations, the Florida Technical College (FTC) stepped up and offered us the use of their entire building (over 20 classrooms!) for the entire weekend of the event. As part of our agreement, we hope to introduce a significant number of FTC students to Drupal.

Florida Drupal DiverIn addition to registration being open, we’re also accepting session proposals for the camp. We’ve added an “Off the Drupal Island” track to encourage our community to learn about complementary technologies, and have arranged for the trainers from OS Training to provide a full-day beginner track as part of the camp.

We’re expanding our normal Sunday events this year to include a code sprint. If you’re interested in learning how to contribute back to the Drupal community, this is a great opportunity to learn how to work on community based tasks - including code, documentation, and cat-herding. Coding for a Cause is back for its third consecutive year - during this event volunteers will build an entire web site for multiple local non-profit organizations. We’re currently accepting applications, so if you know of a Florida-based non-profit looking for a new web site, please send them to the application.

Getting back to our sponsors for a moment, Digital Frontiers Media (a Sarasota-based Drupal shop), Big Couch Media Group (a Palm Beach-based Drupal shop), Purple Rock Scissors (an Orlando-based digital creative agency), and Educational Data Resources (a Winter Park-based educational technology company) are on-board as Gold sponsors. These organizations, as well as the rest of our sponsors deserve all the credit for providing the financial support necessary to bring our community together. Thank you!

There’s a lot more to this event that I haven’t covered: a discount hotel rate, an after-party that we’re still in the midst of planning, plenty of giveaways, and the opportunity to purchase limited-edition polo shirts with our beloved Drupal Diver logo!

The hosts and organizers, the Florida Drupal Users’ Group is a diverse groups of community leaders from all of Florida. While we have various meetups in all parts of the state, we take pride in the fact that we utilize http://groups.drupal.org/florida as our “home base” and do our best to act as a single community.

Trackback URL for this post:


Jan 31 2013
Jan 31

No votes yet

Doug Hercules (dhercjr on drupal.org) is a graduate of the 2012 class of the DrupalEasy Career Starter Program and currently working as an intern with DrupalEasy.

This week I was tasked with learning how to automatically close comments on a node two weeks after the node is created. We initially looked into a couple modules that did this well, Comment closer and Comment commander, but since neither is quite ready for Drupal 7, we decided this would be a good opportunity for me to learn more about the Rules module. Maintained by Wolfgang Ziegler (fago) and Klaus Purer (klausi), this module allows you to define actions that are triggered automatically on various Drupal events as they occur. This blog post will walk you through how I accomplished this task.

Drupalize.me has a great video in their “Learning the Rules Framework Series” called Introducing Rules Scheduler (currently free!)that provided the basic framework for this task. This video was invaluable in getting me up to speed with basic rules functionality.

The first thing I needed to do was download and install Rules. I enabled the Rules, Rules UI and Rules Scheduler module, which required me to also download and enable the Entity tokens and Entity API modules.

Rules Scheduler works with Rules components only, and allows us to schedule an evaluation of rules components; not executing them instantly, but later at a predetermined time. So I began by creating a rules component, which is an individual set of Rules configuration that can be implemented by a Rule, as well as other modules on your site. To get started, on the main Rules Component page (admin/config/workflow/rules/components), I clicked to “+ Add new component”. I wanted my component to actually remove the comment ability to the node (an “action”), so in the “Component plugin” box I chose “Action set” and Clicked “Continue”. In the next screen, in the “Name” box, I typed “Close comments on a node”. The Variables section at the bottom of the page then looked like this,


I entered the following; DATA TYPE: Node, LABEL: Node, MACHINE NAME: node, USAGE: Parameter, and clicked “Continue”. I wanted this component to perform on a certain node, so I chose Parameter. A parameter is a variable that is given a specific value when the Rule is performed, it receives the specific node parameters as input and then sets the variables as an output to the component.

Next, I needed to create an action that would close comments. I did this by clicking “+ Add action”, and then in the “Select the action to add” box, I chose “set a data value”. Then in the DATA section “Data selector”’ box, I selected “node:comment” because that’s what I wanted my action to impact and clicked “Continue”. To enter a VALUE, I typed “1” in the Value box (This is just a integer; 0 meaning hidden, 1 meaning it’s closed and 2 it’s open), and clicked “Save” to save my new component. On its own, the component does nothing. It is only once I create a rule that utilizes the component will anything actually happen.

The next step is to create a react on eventrule to wait 2 weeks after my node is created, and then run the component. To do this I went to - admin/config/workflow/rules and Clicked “+ Add new rule”. In the “Name” box, I typed “actions when new articles are posted” and in the ‘React on event’ box I chose “After saving new content” and Clicked “Save”. There are many options that look similar so be sure to select this one.

I then realized I wanted this to occur not only to new stuff, but whenever I modify existing stuff as well, so I Clicked “+ Add event”, and in the “React on event” box I chose “After updating existing content” and Clicked “Add”. The key is, that in either case (new or existing content), I only want the component to be scheduled if the article is published. I’ll set this up in a later step.

In the Conditions section I Clicked “+ Add condition” and in the “Select the condition to add” box, I chose “content is of type”. Then in the CONTENT section “Data selector” box, I selected “node”. In the CONTENT TYPES section you can select all of the types that you want the comments to close after 2 weeks, in the “Value” box and I Clicked “Save”. For this exercise, I just selected “article”.

To ensure the article is published before the 2 week countdown starts, in the Conditions section, again I Clicked “+ Add condition” and in the “Select the condition to add” box, I chose “content is published”. Then in the CONTENT section “Data selector” box, I selected “node” and Clicked “Save”.

Now to schedule the component to run. In the Actions section, I Clicked “+ Add action” and in the “Select the action to add” box, I chose “schedule component evaluation”. In the COMPONENT section I chose “Close comments on a node” in the “Value” box and Clicked “Continue”. In the SCHEDULED EVALUATION DATE section, I typed “+2 weeks” in the “Value” box (For a good test to make sure you’ve done everything right, you can type “+2 minutes” to make sure it works).

The identifier is what differentiates one task from the other, so in the IDENTIFIER section, I typed “ close comments for node [node:nid] “ in the “Value” box so we only have one comment closing for each mode, and lastly, in the NODE section Data selector box, I chose “node” to send the node variable of the node being saved to the rules component and Clicked “Save”. Therefore, the Rule takes this node and passes it into the component as the node parameter, these nodes and parameters gets saved, and are then loaded when the component is executed. 

Now if you did the “+2 minutes” test, you can add an article to your site, and verify the comment capability on the new node. Wait for 2 minutes, refresh your screen and see that the comment capability is gone. Once confirmed, don’t forget to go back in and edit your rule to “+2 weeks” or you won’t be getting too many comments on your site!

I’ve gone ahead and exported both the rule component and the rule for you to check out. First to import the component, go to admin/config/workflow/rules/components and paste the following rule component export into your import page.

{ "rules_close_comments_on_a_node" : {
"LABEL" : "Close comments on a node",
"PLUGIN" : "action set",
"REQUIRES" : [ "rules" ],
"USES VARIABLES" : { "node" : { "label" : "Node", "type" : "node" } },
"ACTION SET" : [ { "data_set" : { "data" : [ "node:comment" ],
"value" : "1" } } ]

Similarly for the rule, from admin/config/workflow/rules, import the following:

{ "rules_actions_when_new_articles_are_posted1" : {
"LABEL" : "actions when new articles are posted",
"PLUGIN" : "reaction rule",
"REQUIRES" : [ "rules", "rules_scheduler" ],
"ON" : [ "node_insert" ],
"IF" : [
{ "node_is_of_type" : { "node" : [ "node" ],
"type" : { "value" : { "article" : "article" } } } },
{ "node_is_published" : { "node" : [ "node" ] } }
"DO" : [
{ "schedule" : {
"component" : "rules_close_comments_on_a_node",
"date" : "+2 weeks",
"identifier" : "close comments for node {node:nid}",
"param_node" : [ "node" ]

and there ya go, a new component and rule in under a minute! I hope that at least sparks your curiosity into Rules.

Trackback URL for this post:


Jan 29 2013
Jan 29

Working with Lightbox2 and Colorbox

In this series, Lightboxes and Drupal 7, Kyle Hofmeyer walks you through working with two popular lightbox modules in Drupal 7: Ligthbox2 and Colorbox. The first video in the series is free, and explains what a lightbox is, and some things to consider when selecting which module to use.

Jan 29 2013
Jan 29

Working with Lightbox2 and Colorbox

In this series, Lightboxes and Drupal 7, Kyle Hofmeyer walks you through working with two popular lightbox modules in Drupal 7: Lightbox2 and Colorbox. The first video in the series is free, and explains what a lightbox is, and some things to consider when selecting which module to use.

Jan 15 2013
Jan 15

Average: 5 (2 votes)

Doug Hercules (dhercjr on drupal.org) is a graduate of the 2012 class of the DrupalEasy Career Starter Program (http://drupaleasy.com/dcsp) and currently working as an intern with DrupalEasy.

VirtualBox interfaceThis week I had the opportunity to clone a website from a git repository using Quickstart. Quickstart is a really quick, pre-made PHP Drupal development environment in a VirtualBox, which allows you to install a virtual machine to run Linux on your Windows PC. I've only gone through the process of cloning a site into Quickstart once before, and this time I thought I’d document it in my blog for myself and anyone else who might want to do this in the future. The general idea is this - there’s a site that I need to work on that is stored in a remote git repository. I want to get a copy of the site up-and-running inside Quickstart. To get started, I downloaded Quickstart, installed VirtualBox, then imported the Quickstart file into it.

Once I got Quickstart fired up on my Windows laptop, I set off to work. I used Drush (which comes built-in to Quickstart) to configure my virtual host and create an empty database and directory for the site. The Getting started with Quickstart page is a great resource for all the Quickstart specific Drush commands that it includes. At my command prompt I typed

drush qc apache dns database --domain=localsitename.dev

Important to note, this created an empty “localsitename_dev” database. Remember that underscore when you’re setting the name of your database later during Drupal's installation process.

Next, I wanted to clone (Quickstart also comes with Git pre-installed!) the site into the directory I just made, so I changed the directory to the new localsitename directory and I used the git clone command to copy the site from the remote repository. I added a “ .” ("space-period") at the end of the clone command so it cloned the repository into the current directory.

Next, I went to my browser and installed the site by going to http://localsitename.dev/install.php (remember, the Drush command I used automatically also set up this virtual host), this is where I needed to remember that underscore when I named the database. If you run into any files directory and/or settings.php issues, here’s some commands that might come in handy:

$ cp //to copy my settings.php file
$ mkdir //to make a new files directory
$ ls -al //to show me the permissions to each file
$ chmod //to change file permissions

Cheesy Poofs!

At this point, the site was installed with a fresh database. The final step was to get copy the database from the shared development server. I first enabled the Backup and Migrate module on my new local site, then I went to dev site and performed a quick backup (/admin/config/system/backup_migrate); saving it to my local “downloads” directory. 

Finally, I went back to my new local site and restored  (/admin/config/system/backup_migrate/restore) by uploading the file I just downloaded.

Poof! I have a cloned website!

Trackback URL for this post:


Jan 08 2013
Jan 08

Average: 5 (1 vote)

The beginning of the New Year seems like a good milestone to provide a progress update on the DrupalEasy Career Starter Program Work Experience (WE) Drupal. Eleven DCSP grads are interning with Drupal organizations all over the country, engaging their new-found Drupal knowledge and abilities in a variety of tasks, and gaining critical experience every day. Most of the interns are between one-third and one-half complete with their Work Experience, and reviews are super encouraging.

Some amazing organizations from far and wide stepped up to serve as WE Drupal Hosts, and help the eager 11 jumpstart their careeers, including the Drupal Association, Lullabot, WebEnabled, Radiant Blue Technologies, Cloud Nyne, Urban Rethink, Orange County Library System, Proctors, and DrupalEasy. Overall, the feedback from the hosts has been extremely positive, while the general reaction from the interns has been...overwhelming.

WE Drupal give host and intern a best of both worlds scenario, since it provides incentive and real-world, paid work experience for the participants while WE Drupal Hosts get no-cost, career-minded interns with solid Drupal training.  We Drupal is made possible thanks to grant money from Brevard Workforce, which is also the organization that has supported the growth and development of the DCSP. As an added bonus, we were originally told the funds would cover 346 hours for each intern (about 8.5 weeks of full-time work), but Brevard Workforce has extended the grant to cover 520 hours (13 weeks!) Needless to say, the vast majority of our WE Drupal hosts and interns accepted this generous offer.

Our internship host companies are saying some really positive things about our students, their preparedness, and skill level. Once the initial transition from a traditional to a virtual work environment is complete, things tend to really start progressing quickly for both the student and the host. One vitally important thing we’ve learned over the past two years is that planned, daily contact - if only for a few minutes - between the intern and the host goes an incredibly long way in answering quick questions and making sure the intern stays on-track.  I asked all of our current hosts if their interns met their initial reactions. Some responses:

"[Our intern] has a great attitude and as diving into the work head on. His base knowledge in Drupal is very solid, and probably most importantly, he asks great questions. You can tell that he understands the bigger picture and is going for clarification, or even questioning how we approach things, which is the best that anyone could ask for in an employee."

"Overall, I'm really impressed. [our intern] is basically kicking butt with everything we give him, and I can tell that as his experience grows he'll be a very rock solid Drupal guy."

"[Our intern] was well prepared. The student had enough knowledge of the ecosystem and various development tools to work with minimal instruction."

"They’re awesome!"

The reactions from the students varied from excitement to fear. Many are happy to be back to work and contributing to whatever projects they were working on, while also enjoying the ability to experience Drupal development in a real-world setting. A good number of the interns expressed feelings of being a bit overwhelmed by all of the various technologies and aspects of Drupal development, but all are rising to meet the challenge. The improved intern/host matching process appears to have been a success, as several of the interns indicated that they’re really thankful that they had a chance to talk with potential hosts prior to accepting the internship. 

Some of the interns have started blogging about their experiences in the internships, I encourage you to check them out below:

What happened to the other 9 students?

If you’ve been following the DrupalEasy Career Starter Program (DCSP), you’ll know that we had 20 students in the classroom portion of the program. With 11 students currently participating in WE Drupal, I’m sure some of you are wondering what happened to the other 9? If you recall, this year’s class was comprised of recently laid-off workers living in Brevard County, Florida. 5 of the students found employment during the classroom portion of the DCSP, 1 student had to drop out of the internship for personal reasons, and 3 students did not initially meet the class requirements to be placed in an internship.

Trackback URL for this post:


Dec 20 2012
Dec 20

No votes yet

This weekend I participated in the Brevard Code Sprint for the MediaFront Module. I must admit, being new to Drupal, it did cross my mind that I’d be more of a hinderance than a help. I couldn’t have been more mistaken! The dozen folks from the Drupal community were great to work with. To start us off, Travis Tidwell (travist), the MediaFront module maintainer, walked us through a demonstration of the module and Mike Anello (ultimike), of the code sprint sponsor DrupalEasy, facilitated the group in choosing assignments to work on. As he asked for volunteers to work on some novice code issues, I figured “No better time to learn, than when surrounded with help!” so I dove right in. With the help of some great new friends, at the end of the day I had created my first patch and was well on my way to my first commit!

We discussed some problems that the module was having and created the issue to Hide the full-screen button when they have controller only mode enabled. Since a picture is worth a thousand words, I’ll just show ya... it looked like this:

controller bar with fullscreen

In working on fixing the problem we came up with a fix, but then realized the fix corrected the problem but left the look of the item needing reformatted because it just made a big space where the button was ... another chance to learn! I got some new GIT experience creating the patch, which fixed the problem and made the item look good. Making that contribution, encouraged me to look for other coding issues that I would never had even thought about attempting before going to this code sprint. I know you’re wondering so I’ll show you the fix:

If you are new to Drupal and trying to learn it on your own, I can’t encourage you enough to seek out these code sprints, DrupalCamps or DrupalCon community events no matter what your experience level. Everyone was so willing to answer any question I had or point me in the right direction to get over my hurdle. At times there were two of us side-by side working on one screen figuring out the best way to tackle an issue and there were times they let me do it on my own to learn at my own pace. In that one day I feel so much more confident in my Drupal understanding and much more comfortable asking for help. I’ve started some new relationships and strengthened some other ones.

Trackback URL for this post:


Dec 18 2012
Dec 18

No votes yet

The first-ever Brevard County Drupal Code Sprint took place on Sunday, December 16, 2012 at the Cocoa Village Civic Center. A total of 12 sprinters attended in-person, along with 2 virtual attendees who joined in via IRC and a Google+ Hangout. The sprint was in support of the MediaFront module, a front-end media solution that provides HTML5-based media players for supported browsers and falls back to a Flash-based player when necessary. The MediaFront module maintainer, Travis Tidwell (travist), could not have been more accomodating and helpful, as he participated in the sprint for 10 straight hours.

The sprint was a success; we were able to improve the MediaFront’s documentation, fix some bugs, perform some structured testing of the module in various operating systems and browsers, and make some progress on several other issues. DrupalEasy was proud to sponsor the sprint, providing the facilities, drinks, and snacks for the participants.

As many of the sprinters were new to the MediaFront module, we started off the day with an overview of the module’s functionality. Travis led a walkthrough that included simple use cases involving uploaded and hosted videos, numerous examples of setting up playlists, as well as some of the advanced features of the module including player-to-player communication.

Once everyone understood the basics of the module and set up a local development/testing environment (consisting of a fresh copy of Drupal 7 and the latest -dev version of the MediaFront module), the sprint participants were split into roughly three groups: documentation, issue queue triage, and testing. As our group of sprinters didn’t include too many hardcore developers, we decided to focus on these three areas.

The documentation group was involved in reviewing the existing documentation, making sure it was up-to-date with the latest version of the module. Many additions and fixes were made to the documentation, including:

Additionally, documentation for two other use cases was started (but not yet published):

  • Using Mediafront with Media, Colorbox, and Media Colorbox modules to allow multiple videos (personal, youtube, and vimeo) to be played in Colorbox popup on the node details page 
  • Adding YouTube videos automatically to a MediaFront playlist using Feeds module.

The issue queue triage group was tasked with going through as many of the 7.x-2.x issues as possible, with the goal of either responding to support requests, trying to duplicated reported bugs, or closing out obsolete issues. A total of 28 issues were closed, with activity on an additional 21 issues.

The last group focused on rigorous testing of the module to ensure that the proper player (HTML5 or Flash) was being used depending on the operating system, browser, and media file to be displayed. Numerous bugs were found and fixed during this process. One of the more important bugs that was squashed was for the case when multiple media files of different formats are uploaded to a multi-valued file field. The MediaFront module now selects the best file format for the browser. For example, when both an .ogv and .mp4 file are available to Firefox, the .ogv file is used to display the video in a HTML5 player. Once all the tests are complete, this compatibility chart will be added to the MediaFront documentation on Drupal.org.

Work was also done on various miscelleanous tasks:

  • Squashed bug with jQuery UI version discrepancies
  • Outlined future enhancements for better interoperability with Media module’s file entities

Overall, both the participants and the maintainer were happy with the results. The participants were able to dive deep into the module’s functionality (with Travis available all day to answer any and all questions), contribute back to the community, and sharpen their skills, Travis was able to take advantage of a significant number of people helping to improve one of his modules. We’ve already started talking about the next Brevard County Drupal Sprint (although we’re thinking about changing the name to the Drupal Mosquito Control, Florida Bug Squad, Florida Bug Zappers, or something similar) for as early as next month - everyone is excited to continue their work with the MediaFront module and to give back to the Drupal community! 

List of sprinters:

Trackback URL for this post:


Dec 10 2012
Dec 10

Average: 5 (3 votes)

Doug Hercules with shuttle3.. 2.. 1.. and lift-off of a new career!!! Here I go off to explore a new world that just 6 months ago I’d never even heard of! The strange blue teardrop world of Drupal!

For the past 20 years, I have been blessed to work my dream job as an engineer in the Space Shuttle Program, what a ride! The retirement of the shuttles meant a new direction in my life, and since there’s not a huge demand for rocket scientists these days, it meant seeking some new doors to open up and see what’s out there.

I happened upon a chance to enroll in a 10-week web development course called DrupalEasy Career Starter Program, so I dove right in not having any computer background, but realizing the web is the future! I successfully completed the class and am now starting an internship and an introduction into the community of Drupal. With all the helpful support in Drupal, it’s not a program you learn - it’s a universe of mutual relationships you join... so here’s my first step towards growing in the community.

Being a visual brained kinda guy, one of the most valuable things I’ve learned is it’s easier to learn a module if I just load it, enable it and see what it’ll do. So it became obvious that I wanted to make quick, disposable sites for testing and I didn’t want to spend a long time generating the site. I’m using the VirtualBox/Quickstart environment so from& Getting started with quickstart I found that from a command line prompt, I could create a site using a Drush make file with one simple command line:

[email protected]:~/websites$ drush quickstart-create all 
--domain=newsitename.dev --makefile=makefilename.make

My make file includes about a dozen modules that I commonly use in most start-up sites, including admin_menu, module_filter and devel to name a few. For more info on building a make file check out http://drupal.org/node/1476014 . These simple steps get me up and running with a clean site for testing in just a couple minutes. Without the time investment of setting up a site, trying out a new module becomes very easy and eliminates the risk of harming any other site.

On the DrupalEasy.com redesign to Drupal 7 site, I’m working with the social media module and the Widgets module, it helps you put follow and share buttons into your website with sites like Twitter, Facebook and Google+, I’ll cover that more in my next blog post.

Note from Mike: Doug Hercules is a graduate of the 2012 DrupalEasy Career Starter Program. He is interning with DrupalEasy for the next few months and is currently working on the redesign of DrupalEasy.com on Drupal 7. You can follow Doug on Twitter at dhercjr.

Trackback URL for this post:


Dec 05 2012
Dec 05

No votes yet

DrupalCon Sydney logoGit’s a ripper Version Control System, and considering its growing adoption, you can’t afford to be a drongo when it comes to leveraging it. No worries though, just head on over to Sydney the day before DrupalCon kicks off, take DrupalEasy’s action-packed Blue Collar Git training, and Bob’s yer uncle! 

The Yank (that’d be me) from DrupalEasy is putting on this fast-paced workshop that’ll help you master Git and get gobsmacked at how much more effective you get as a Drupal developer, themer or project manager. Git’s a dinky-di super speedy and efficient version control system. Unlike the others, Git’s got a distributed approach, which gives it an edge for collaborative development, and why its adoption is going flat chat.  What’s more, as it grows, being comfy with it becomes not just a valuable tool, but a handy talent to brag about as its becoming a popular preference on job posts. 

Blue Collar Git will start just after brekkie with the basics and a look around under the bonnet, then delve into remote repositories, resolving conflicts, and working with patches in the arvo. We’ve designed Blue Collar Git to be just the script you need to empower you to start leveraging it for your everyday workflow.

This unique workshop came about from a video of the 2010 Open Source Developers Conference session "Git for Ages 4 and Up" by Michael Schwern. His Tinker toy demo helped me soak up the Git knowledge, and motivated me to teach it using a similar method. Great feedback from various Git-related meetups and camp presentations and trainings inspired the full-blown training course.

The workshop runs the full day of February 6, the day before DrupalCon at the Crowne Plaza. The cost is only $440 for the full day (includes lunch!). This is our first time bringing a DrupalEasy workshop to Oz, so we’re hoping for a bonzer of a turnout! Get on the bush telegraph and grab a Drupal mate to spend the day soaking up insight and doing lots of hands-on learning. Head to the DrupalCon Sydney site to sign up for this corker of a training course!

Trackback URL for this post:


Nov 02 2012
Nov 02

Average: 5 (4 votes)

The DrupalEasy Career Starter Program (DCSP), a one-of-a-kind 10-week, multi-modal Drupal training program is proud to announce the graduation of all 20 of our students from the class of 2012. This is the second year of the DCSP in Brevard County, Florida and we’re excited to watch this year’s graduates become (even more!) active Drupal community members and developers.

DCSP Class of 2012 and instructors

Through a grant from Brevard Workforce, the DCSP’s goal was to retrain 20 unemployed IT professionals and turn them into Drupal professionals. With the retirement of the Space Shuttle fleet in 2011, approximately 8,000 skilled workers lost their jobs at Kennedy Space Center in Brevard County. Our available pool of talented IT professional was HUGE. This year’s DCSP effort received 202 applications for just 20 slots. The vast majority of the students selected had zero Drupal experience coming in. The rest of this post will give you an idea of how much Drupal knowledge and experience they have going out...

The class of 2012 is:

  1. Mike Anhalt (manhalt)
  2. Jack Ferguson (jpstrat)
  3. Shaun Heath (heaths1)
  4. Doug Hercules (dhercjr)
  5. Cielo Johnson (C13L0)
  6. Frederick Martin (FredMart)
  7. Paula Owen (owenpa)
  8. Gustav Postreich (Gustav)
  9. Tierra Renthrope (IvoryTierra)
  10. Natalie Roberts (anzi31)
  11. Dennis Solis (densolis)
  12. Patsy Spicer (spicerpa)
  13. Wes Stansbury (Oddjob)

Collectively, the class of 2012 contributed approximately 1,000 hours of volunteer time to the Drupal community. While much of that time was spent climbing the Drupal Ladder and learning the ins-and-outs of Drupal issue queues, we did have a moderate amount of success:

  • Participated in well over 100 Drupal.org issues
  • More than 20 Drupal.org documentation edits
  • Numerous patches awaiting review/commit by module maintainers

We were lucky enough to be within driving distance of two DrupalCamp events (South Florida and Atlanta) during the month of October, and the vast majority of the class was able to attend at least one of the two events (some attended both!) and two of our students presented sessions at DrupalCamp South Florida. In all cases, students that attended these events came back with a greater appreciation for the community and motivation to get even more involved. Additionally, a number of DCSP students (and teaching assistants) participated in the two code sprints at DrupalCamp Atlanta and were recognized during the camp’s opening remarks. 

DrupalCamp Atlanta code sprint slide

The DCSP’s unique approach to Drupal training includes a heavy dose of Drupal community involvement. During the 10-week training program, each student is required to:

  • Attend 70 hours of classroom training
  • Attend 40 hours of lab hours
  • Contribute 50 hours of time to the Drupal community
  • Complete the first 5 rungs of the Drupal Ladder http://drupalladder.org/
  • Complete numerous homework assignments and three mini-projects
  • Periodically check in with instructors via IRC

The students are provided with PDF lesson guides and reference documents for each lesson, and selected lessons also include related DrupalEasy-produced screencasts. 

The goal of the DCSP is not to teach students everything there is to know about Drupal, rather it is to provide knowledge and a strong foundation of Drupal core and selected modules while also exposing students to some of the various niches that they may want to focus on in the future (module development, theming, distributions). In addition, students spend time learning about all the various “satellite” technologies related to becoming a professional Drupal developer including IRC, SSH, Git, CSS, PHP, and Drush. 

Our approach to community involvement is simple - start by having the class interact with each other online via IRC and class forums, then slowly expand the circle to the local, state, national, and international community. 

In the coming months, we’ll be looking to expand the DCSP to areas outside of Brevard County, Florida. Interested in learning more? Check out more information about the DCSP at http://drupaleasy.com/dcsp.

Trackback URL for this post:


Oct 31 2012
Oct 31

Average: 4 (2 votes)

Using Git to move the code base of a Drupal site from a local development environment to a hosting provider (or vice-versa) is a necessary skill that most Drupal site builders should have. Configuring and utilizing a remote Git repository can be an especially daunting task for people who don't have a strong background with version control systems. 

Flow chart

While updating the DrupalEasy Career Starter Program (DCSP) Curriculum a few weeks ago, it became clear to me that effectively using Git is a skill that we need to teach our students. We had informally gone over basic Git commands earlier in the program, but feedback from students and potential employers made us realized that students need (and want!) the necessary instruction and materials to get them up-to-speed on using Git to move sites between servers.

If you're a listener or <shameless_plug>our podcast</shameless_plug>, you probably know that we've been working with the fine folks at WebEnabled.com for quite some time. They've been the exclusive sponsor of our podcast for years, and we use their development tools extensively with our clients and training programs. So, we are going to take this opportunity to give something back to both the Drupal community as well as our friends at WebEnabled by providing access to our print and video curriculum for moving Drupal sites to and from WebEnabled development servers using Git. 

A free-to-download 13-page PDF from the DCSP curriculum that details the various steps required to move a Drupal site from a local machine to a WebEnabled server and vice-versa is included at the end of this post. 

In addition, we've created two screencasts that demonstrate the process from start to finish; part of the DCSP’s "multi-modal" training approach. Students get maximum training and experience through classroom instruction on all topics (including this one), as well as written curriculum, dedicated time during lab hours where students can work cooperatively, and in some cases, companion screencasts (we're dedicated to having 100% coverage of all our technical lessons in screencast form soon). We feel presenting curriculum in multiple modes greatly increases the success of students to comprehend the subject matter and put it to practical use faster.

DCSP Screencast: moving a local Drupal site to WebEnabled using Git

DCSP Screencast: moving a WebEnabled Drupal site to a local environment using Git

If you're interested in learning more about the DrupalEasy Career Starter Program, be sure to check out DrupalEasy.com/dcsp or contact us.

Trackback URL for this post:


AttachmentSize 947.27 KB
Oct 26 2012
Oct 26

Listen online: 

Jeff Eaton and Erin Kissane discuss the past and future of web standards, new experiments in web publishing, and the challenge of predicting the future.

Mentioned in this episode:

Release Date: October 26, 2012 - 9:00am


Length: 35:20 minutes (19.78 MB)

Format: mono 44kHz 78Kbps (vbr)


About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web