Redesigning a site as a long-term project

Redesigning a site as a long-term project

Ki Kim's picture

One of the earliest sites developed by Urban Insight is 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 yet because many of contrib modules used in the site have not been ported over to Drupal 8. So we decided to redesign 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.


Would you care to show the script?

Ki Kim's picture

I hoped the screenshot of the script run gives a good idea of what it is doing.

Post new comment

About Urban Insight

We create elegant, mobile-friendly websites.

We solve complex problems using Drupal and open source software.

Learn More


These svn commands are not particularly version 1.7, but works well with upgrading Drupal modules.

After replacing module folders and when ready to commit the code change to svn repository:

# Remove dropped files

$ svn st | grep '^!' | awk '{print $2}' | xargs svn rm

# Add new files

$ svn st | grep '^?' | awk '{print $2}' | xargs svn add

# To add, this works too (Make sure you are at directory level that has no ignored files; otherwise --force will add ignored files as well)

$ svn add --force .

# Commit

$ svn ci -m "Upgraded a module."

If you are using svn 1.6, overwrite folders instead of replacing to keep hidden .svn folders. Then the command above should work too. There will be no files getting dropped when overwriting.