Development

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.

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.

We're digging into our first dry-run migrations from Drupal 6 to Drupal 8, and learning a lot about what's ready and what's not. And there's some surprises in there...

I'm sure many of you reading this may have heard that Drupal 8 has been released, may have even received some marketing emails.

For many years, we've organized our development around user stories. What exactly is each user trying to accomplish, and what does that look like when they try to accomplish those tasks?

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

"Hey, since the upgrade, I can't use the power edit feature anymore!" came the request. Ok. There have been several different upgrades over the past few months. The menu editor module has been updated. The server has been upgraded.

Clients love fixed-price projects, because they have transferred the risk of the unknowns to the vendor. Even so, if the vendor cannot fully handle those risks, the entire project might fail.

There's a few problems with setting up shop on the web. All of your competitors are right next door. You're in the worst neighborhood, with crooks inventing new tools to break in every day. That parking lot you just built now has to accommodate scooters and semi trucks.