What an honor it was to be selected to present at Drupal Camp Asheville again! This event just gets better and better each year. I want to thank the organizers, volunteers, attendees, and sponsors for making it so awesome!
Below you will find the video for my talk, slide deck, and related git repo for:
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.
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.
I use drush aliases between Drupal VM and Drupal hosting services quite a bit. It was great to learn that drush site-set allows me to set the alias to use for the current session, so I don't have to type the alias name over and over again. For instance, I can set an alias like this: $ drush site-set @drupalvm.drupal8.dev, allowing me to check the status of the site on the Drupal VM with $ drush status.
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.
As a long time maintainer of the brewStack project, I have been spending time evaluating better ways to develop Drupal projects locally. Using VM based tools is a huge win because if you mess up a system configuration or setup, you can just throw away the VM and and start over. brewStack has been a great toolset, but you are altering your local Macs setup. Using Vagrant makes that much easier since you don't have to maintain VM snapshots or backups.