Dev Corner

On one of our D8 sites, after upgrading to 8.3.0, we had a "too many redirects" loop going on on the dev server. For quite some time, we've had the site path repeated with "?q=".

[Update: It turns out the Drupal 7 site we tested had page caching disabled.

Panacea, or disaster? Drupal 8 Configuration Management was supposed to solve all our woes when it came to dealing with deploying configuration. In many ways it's a vast improvement, but in some ways it has almost made matters worse.

I learn best when I have a problem to solve, and with one of our D8 upgrade projects, we had a mess to clean up in the menu system.

So there are definite "gotchas" to migrating content from Drupal 6 to Drupal 8, when you take away the assumption that the ids throughout the system will remain the same.

Our branch strategy based on Git Flow did not survive. It was getting a bit old in the tooth, but the final blow was automation.

We have several Drupal 6 to Drupal 8 upgrade projects going on, which is particularly challenging given how quickly the Drupal Migration system is changing.

Its name is Watney. Watney lives in Matrix. Watney is a bot I created about 6 months ago to start helping us with various tasks we need to do in our business.

Watney patiently waits for requests in a bunch of chat rooms we use for internal communications about each website we manage, each project we work on. Watney does a bunch of helpful things already, even though it is still really basic -- it fetches login links for us, helps us assemble release notes for each release we do to a production site, reminds us when it's time to do a release, and kicks off various automation jobs.

Here are the slides from my 2015 Drupal Summit talk, Quality Drupal DevOps!

You can also click here to open in a new window, full screen.

Faster, more secure, more maintainable. Three nice benefits we get from our new standard Drupal server architecture.

More and more I keep running into assertions that Git is a version control tool, and that if you use it for deployment, you're doing it wrong.

Why?

At Freelock we find it to be a very effective deployment tool, and I'm not seeing a solution that meets our needs any better.

Two presentations in particular caught my attention recently mentioned this:

Just a quick note of how we resolved an issue related to an upgrade to Date.