Redesigning a site as a long-term project

One of the earliest sites developed by Urban Insight is planetizen.com. It still remains one of biggest sites that we actively develop and maintain. When the site was upgraded from Drupal 5 to 7 a few years back we had to plan and implement a full content migration. That is, we built a brand new Drupal 7 site from scratch and migrated all data and settings from the Drupal 5 site.

Our most recent update involved a full redesign of the site. Even though Drupal 8 was released in December 2015, we did not feel it was ready for planetizen.com yet because many of contrib modules used in the site have not been ported over to Drupal 8. So we decided to redesign planetizen.com still in Drupal 7 since it was going to be just a facelift. Since most of the contents and internal structures are about the same, we felt full data migration that we did for Drupal 5/7 upgrade was overkill. We took a different approach this time. In simple terms, it was basically switching to a new theme, as Drupal makes switching themes very easy.

As we iterated on design and built the new theme it became important to track all the configuration changes we made since the project involved multiple developers and spanned many months.

Here are the strategies we've employed.

It would have been much more difficult to track the configuration changes in the redesigned site without Features module. It helped export most of the configurations and settings into the code. Since I needed to sync live data back to the redesigned site in development, all the changes in the database would be wiped out.

In order to have custom blocks survive the data sync, we've build numerous custom blocks in code to be used as panes in the paneled pages. This reduced the flexibility of easy change of block settings and contents by site admins because blocks were all exported into the code, but made it much easier to maintain blocks during data sync from the live site. We planned to turn a few blocks back to custom blocks that support editable contents after launch of new site, which seemed like a feasible compromise.

In order to handle a few things left that are not exportable to Features, I've written a sync script to take care of the final manual setting adjustments triggering drush commands. Tasks handled by the script include:

- Switch to new theme
- Disable unused views and modules
- Enable all new Features
- Set various Drupal variables
- Arrange blocks into regions
- Update menus
- Update url aliases
- Support old aliases as redirects
- etc

The script helped save a lot time of manually reconfiguring site settings reducing several hours of work into half an hour task.