I had the pleasure of attending DrupalCamp Atlanta 2016 in October. It was great to catch up with old friends, meet new people, and checkout some excellent presentations. I would like to thank the organizers and sponsors for making this event happen.

If you missed the event, I encourage you to checkout the session videos that were just posted. I also want to mention my presentation "The Story of an Insecure Module". I have included the abstract, video, and slide deck below. I am especially excited about the sandbox project Security Examples, which I hope will be something that the community can develop to show good and bad Drupal secure coding practices.

Abstract

There once was a Drupal module who wanted so badly to have a stable release, but they were insecure. As a useful and promising module to the Drupal community, they were so afraid that poor coding standards and lack of community reviews could lead to XSS, information disclosure, sql injection, and other vulnerabilities for their users.

The Drupal community is one of sharing and support. As a result, the module in this story takes the opportunity to learn and grow from the lessons of other modules and contributors to become much more secure and confident. The module becomes capable of being promoted to a full project and having a stable release. The community rejoices!

Come take a journey through this module's security audit and how their developer resolved each and every finding, following Drupal best practices for writing secure code.

Related drupal.org Security Examples sandbox https://www.drupal.org/sandbox/shrop/2821723

There is no doubt that Drush is a magical tool in the Drupal community. Two very useful tools in the Drush "Swiss Army Knife" include drush sql-sync and drush core-rsync. These tools allow copying databases and files between Drupal instances.

If you need to have access to run Drush commands on a production server or via a Drush alias for a production server, policy.drush.inc can help prevent some devastating mistakes. Accidentally overwriting production databases and files can impact you and your clients negatively. The Github gist below shows how the built-in Drush policy functionality can prevent sql-sync and core-rsync from running against any Drupal instance that has a destination with prod in the name. This works for Drush aliases too.

Last Saturday (February 21st, 2015), thirty-five Drupalers joined together at Classic Graphics for the sencond annual Charlotte Drupal Drive-in. The day was full of presentations, BOFs, and general chatting about Drupal and related web technologies.

The day-long, un-conference-style event was the brainchild of Thomas Lattimore. After CharDUG wasn't able to pull together the human resources to repeat the success of DrupalCamp Charlotte 2012, Thomas mentioned that he had an idea. Since he knew organizers had limited time to commit to planning and he wanted to host an un-conference-style event, allowing for simpler planning than a full-blown Drupal camp. You can learn more about his concept on the DruaplEasy Podcast.