open source

DrupalCon Seattle 2019 is a wrap! It's all about the people

I'm on the flight home from this year's North American DrupalCon. Couldn't sleep, so thought I'd jot down a few words after a great experience in Seattle.

Last year, some remember seeing me walking the halls in Nashville akin to a zombie. But not the hungry, flesh-eating kind... more like the thin, scraggly, zoned-out kind. Last year my health was very poor. I went to DrupalCon mostly because it was the first DrupalCon within driving distance of St. Louis since DrupalCon Chicago several years ago. In hindsight it might not have been the best idea, and I had to skip a number of events due to my health.

Since that time, I experienced a grueling surgery and recovery, and learned to live with my new friend, the stoma. (Warning: scatalogical humor ahead—hey, it's my coping mechanism!).

Drupal VM 5 ('Flynn Lives') brings updates to all the things!

It's been five years since Drupal VM's first release, and to celebrate, it's time to release Drupal VM 5.0 "Flynn Lives"! This update is not a major architectural shift, but instead, a new major version that updates many defaults to use the latest versions of the base VM OS and application software. Some of the new default versions include:

  • Ubuntu 18.04 'Bionic' LTS (was Ubuntu 16.04)
  • PHP 7.2 (was PHP 7.1)
  • Node.js 10.x (was Node.js 6.x)

See the full release notes here: Drupal VM 5.0.0 "Flynn Lives"

There are also a number of other small improvements (as always), and ever-increasing test coverage for all the Ansible roles that power Drupal VM. And in the Drupal VM 4.x release lifecycle, a new official pre-baked Drupal VM base box was added, the geerlingguy/drupal-vm Vagrant base box. Using that base box can speed up new VM builds by 50% or more!

Drupal 8 successes and failures

Thoughts about Drupal 8, Drupal 7, Backdrop, the Drupal Community, DrupalCon's meteoric price increases, DrupalCamps, and the future of the framework/CMS/enterprise experience engine that is Drupal have been bubbling up in the back of my mind for, well, years now.

I am almost always an optimist about the future, and Drupal 8 promised (and usually delivered) on many things:

  • Vastly improved content administration
  • Views in core, and even better than ever
  • Media in core
  • Layouts in core
  • Modern programming paradigms (fewer #DrupalWTFs)
  • 'Getting off the island' and becoming more of a normal PHP application (kinda the opposite of something like Wordpress)

But one thing that has always been annoying, and now is probably to the state of alarming, for some, is the fact that Drupal 8 adoption has still not hit a level of growth which will put it ahead of Drupal 7 adoption any time soon.

Hosted Apache Solr now supports Drupal Search API 8.x-2.x, Solr 7.x

Earlier this year, I completely revamped Hosted Apache Solr's architecture, making it more resilient, more scalable, and better able to support having different Solr versions and configurations per customer.

Today I'm happy to officially announce support for Solr 7.x (in addition to 4.x). This means that no matter what version of Drupal you're on (6, 7, or 8), and no matter what Solr module/version you use (Apache Solr Search or Search API Solr 1.x or 2.x branches), Hosted Apache Solr is optimized for your Drupal search!

Hosted Apache Solr - version selection

Drupal Camp St. Louis is taking a break for 2018

The St. Louis Drupal Users Group has hosted a Drupal Camp in the 'Gateway to the West' for four years (since 2014), but this year, the organizers have decided to take a year off, for various reasons. Our camp has grown a little every year, and last year we even increased the scope and usefulness of the camp even more by adding a well-attended training day—but life and work have taken precedence this year, and nobody is able to take on the role of 'chief organizer'.

Meet me in Des Moines St. Louis Drupal Camp goes to DrupalCorn in Iowa

All is not lost, however! There are other great camps around the Midwest, and this year we're directing everyone to our northern neighbors, in Iowa: DrupalCorn Camp is going to be held in Des Moines, Iowa, from September 27-30, 2018!

How can I get my PR merged into your open source project?

Recently I received an email from an IT student asking the following: I recently submitted a pull request to one of your open source projects on GitHub. What can I do to get this pull request merged? The answer below may sound somewhat like a cop-out, or harsh (especially considering it was to a starry-eyed student trying to dip his or her toes into the waters of open source software contribution)... but I've found that honesty is the best policy, and the best way I can maintain good OSS software is to guard my (limited) time for OSS work vigilantly, and try to not allow sentiment force the merge of any kind of code, no matter how simple/small the change. Here is my reply:

Thanks for the email! I maintain over 100 different open source projects on GitHub, all in my spare time (which can be hard to come by with 3 kids, a full time job at Acquia, and a few other hobbies!). I spend a few hours per quarter on any given project. Some of the more popular projects have dozens of issues, PRs, and new comments that need to be read through to figure out what I need to these few hours on.

Patching or using a forked version of an Ansible Galaxy role

I maintain a lot of Ansible Galaxy roles. I probably have a problem, but I won't admit it, so I'll probably keep adding more roles :)

One thing I see quite often is someone submitting a simple Pull Request for one of my roles on GitHub, then checking in here and there asking if I have had a chance to merge it yet. I'm guessing people who end up doing this might not know about one of the best features of Ansible Galaxy (and more generally, open source!): you can fork the role and maintain your changes in the fork, and it's pretty easy to do.

I just had to do it for one project I'm working on. I am using the rvm_io.ruby role to install specific versions of Ruby on some servers. But there seems to have been a breaking change to the upstream packages RVM uses, summarized in this GitHub issue. I found a pretty simple fix (removing one array item from a variable), and submitted this PR.

Get started using Ansible AWX (Open Source Tower version) in one minute

Since yesterday's announcement that Ansible had released the code behind Ansible Tower, AWX, under an open source license, I've been working on an AWX Ansible role, a demo AWX Vagrant VM, and an AWX Ansible Container project.

As part of that last project, I have published two public Docker Hub images, awx_web and awx_task, which can be used with a docker-compose.yml file to build AWX locally in about as much time as it takes to download the Docker images:

Apache, fastcgi, proxy_fcgi, and empty POST bodies with chunked transfer

I've been working on building a reproducible configuration for Drupal Photo Gallery, a project born out of this year's Acquia Build Hackathon.

We originally built the site on an Acquia Cloud CD environment, and this environment uses a pretty traditional LAMP stack. We didn't encounter any difficulty using AWS Lambda to post image data back to the Drupal site via Drupal's RESTful Web Services API.

The POST request is built in Node.js using:

Composer and Drupal are still strange bedfellows

More and more sites are being built in Drupal 8 (over 160,000 as of DrupalCon Baltimore 2017!). As developers determine best practices for Drupal 8 site builds and deployment, they need to come to terms with Composer. In one of the most visible signs that Drupal is 'off the island', many modules are now requiring developers to have at least a fundamental grasp of Composer and dependency management.

But even more than that, many developers now use Composer in place of manual dependency management or a simpler tools like Drush Make files.

With these major changes comes some growing pains. Seeing these pains on a daily basis, I wrote Tips for Managing Drupal 8 projects with Composer to highlight some best practices and tricks for making Composer more powerful and helpful.

But many developers still wrestle with Composer, and mourn the fact that deployments aren't as simple as dragging zip files and tarballs around between servers, or checking everything into a Git repository and doing a git push. For example:

  • If I manage my codebase with Composer and follow Composer's own recommendation—don't commit dependencies in my vendor directory, what's the best way to actually deploy my codebase? Should I run composer install on my production web server? What about shared hosting where I might not have command line access at all?
  • Many modules (like Webform) require dependencies to be installed in a libraries folder in the docroot. How can I add front end dependencies via Composer in custom locations outside of the vendor directory?

And on and on.

DrupalCon Baltimore 2017 - participants sitting and waiting to see the opening Keynote
Over 3,000 community members attended DrupalCon Baltimore 2017.
(Photo by Michael Cannon)

During a BoF I led at DrupalCon Baltimore 2017 (Managing Drupal sites with Composer), we identified over 20 common pain points people are having with Composer, and for many of them, we discussed ways to overcome the problems. However, there are still a few open questions, or problems which could be solved in a number of different ways (some better than others).

I've taken all my notes from the BoF, and organized them into a series of problems (questions) and answers below. Please leave follow-up comments below this post if you have any other thoughts or ideas, or if something is not clear yet!

Pages

Subscribe to RSS - open source