Peter Wolanin

Senior Application Architect

Peter Wolanin, Principal Cloud Security Engineer, had a previous life as a Senior Scientist before making the leap into working with Drupal, and eventually at Acquia. A Drupal code contributor since May 2006, and a listed Drupal core subsystem maintainer since November 2008, Peter has worked on helping many of Acquia's products and services throughout his tenure at Acquia, while continuing to contribute to Drupal and helping promote it by organizing meetups and DrupalCamp New Jersey, and by speaking at many other events. Most significant D8 contribution I was not working heavily on Drupal 8 until DrupalCon Portland. At the extended sprints in the Acquia office after the conference I worked on getting up to speed on the new plugin system and routing systems. That led to envisioning and working on executing the conversion of menu local tasks, actions, and contextual links to plugins. I also helped push the conversions from page callbacks to routes and controllers. However, I think my most significant single contribution came out of Drupal Developer Days in Szeged, Hungary. Towards the end of the event (after a week straight sprinting on Drupal 8 beta-blocking bugs) I developed a new idea as to how we could solve all the outstanding problems with the menu link system. Daniel Wehner and I spent about half a year executing on that vision with help from lots of other people <a href="https://www.drupal.org/node/2256497">https://www.drupal.org/node/2256497</a>. At one point the main patch grew to 617 kB (17,920 lines) before it was broken to make it more reviewable! Biggest challenge with D8 It was pretty hard to find enough time to get it done, and at times there was a lot of effort that went into just keeping communication open and complex, multi-part plans moving forward. Looking forward to most about D8 I'm eager for the release so I can start building fun modules and find time to port some of of my existing modules. I am really happy about the conversion of code to use a mostly OO approach. While the number of files increased, it actually makes the code a lot more fun to work with and write.

Moving Your Drupal 8 Configuration from Local to Server and Back

February 26, 2014
3 minute read

Update: a textual representation of the first half of this video has been posted.

Two weeks ago I had a great opportunity to spend a few days working with Moshe Weitzman (moshe weitzman), Justin Randell (beejeebus), Alex Bronstein (effulgentsia), and Stéphane Corlosquet (scor) to look at the challenges and best practices for using the new Drupal 8 configuration system (a.k.a. CMI) to move changes between a local development environment and one or more server environments. We developed ideas, considered new modules for Drupal 8, and tried to figure out if there were any changes to Drupal 8 core that would be needed to make the system better for developers.

One outcome of this was two new modules Configuration log and Configuration Read-only mode. These were written to help demonstrate the capabilities of the new configuration system and enabled us to implement key elements of possible new configuration staging and management workflows. An additional outcome was a number of enhancements by Moshe to the latest version of Drush to facilitate the import and export of configuration.

The screencast video below walks through the process of moving configuration from a local development version of a site, up to a development environment on a server and then to a "live" environment using Acquia Cloud Free. The "live" environment was detected in settings.php and that logic triggered the Configuration Read-only mode module to prevent any configuration changes in the administrative forms. We also used a Cloud Hook to automatically import new configuration when a new git tag was deployed to the "live" environment.

The video also shows the reverse process of bringing a configuration change back to a local codebase. For that we used the Configuration log module and committed each configuration change into a "recorder" branch in a git repository that was a clone of the site codebase. By creating the "recorder" branch from the same git commit as the deployed site is running, it's possible to use native git operations to merge the configuration changes back into the local clone of the codebase, as shown.

While we were happy with what we are able to demo, the experience convinced everyone involved that keeping the active configuration in files was more difficult in terms of development workflow, and led us to push for the proposed Drupal core change to keep the active configuration in the database.

We also discovered a core bug that mean a small subset of configuration imports did not work - so we had to patch around it for the demo and file an issue. The good news is that the bug has already been fixed thanks to Tim Plunkett.