<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1114119085333160&amp;ev=PageView&amp;noscript=1">

Re-theming a legacy site can sometimes be a painful process - but it needn’t be!

There are almost always likely to be a few small hiccoughs along the way, particularly if multiple groups of developers, all taking different approaches, have worked on a site before you. However, here are some useful considerations to alleviate potential issues and ensure the project runs as smoothly as possible.


Assess the Existing Codebase

Before you attempt to plan time estimates or allocate resources, the first thing to consider when re-theming a legacy site is to perform a thorough code review. In the case of Drupal sites, some of the most important aspects to consider are:

Has core been hacked/edited by previous developers?

This makes sites extremely difficult to update without breaking what’s already there. It is also a sign that whoever worked on it before didn’t really know what they were doing! This can be a red flag for any other development they did on the site.

A useful module to ascertain if core has been tampered with is Hacked!. You could also do the same thing manually, by downloading the version of Drupal used and then using diff or a version control tool, like Git, to see if there’s any difference.

 

How up-to-date are the site’s core and contrib modules?

Are there any known issues with any of the contributed modules in use? It’s a good idea to check any modules you’re not sure about to see if they have a recent stable release or any notes on the project page that imply that there could be issues with updating, e.g. the module has been superseded by another.

In most cases, out of date core or contrib modules will just require updating and shouldn’t cause any major problems


Custom modules: Are there any? What are they used for? How well are they written?

If the new theme is going to require any custom modules to be tweaked or changed, you need to be sure these are written according to best practice,  following coding standards. Make sure they are easy to understand and therefore to edit.

Have they been written the “Drupal way”?

 

If there are any issues with custom modules, you may need to allocate some time for re-writing or re-factoring certain sections of code.


Existing theme functionality

If you are going to be discarding the existing theme in favour of a new one, you will need to take stock of how much functionality is in the theme itself.

  • A large template.php file or lots of pre-processing can sometimes be a sign that you will need to retain any extra functionality that was provided by this part of the theme when creating your new theme.
  • Lots of PHP or javascript written directly into template files is another red flag in terms of adding extra time to accommodate re-writing or refactoring of code. It is also an indication you might need to spend a while trawling through questionably written code, ascertaining what it does and then re-writing according to best practice to make it more maintainable.

 

Audit the Site Architecture

With Drupal sites, the elements that make up a site can differ greatly from project to project. For example, it could implement any combination of panels, views, custom modules or basic nodes to populate pages (to name just a few); or the site might utilise features to use code to control aspects that are usually database-driven. Blocks might be controlled on the blocks page, or, context might have been employed to control where they go. The list of possible iterations is almost endless.

It is important to document how each section or page of a site is created and what elements go into making it, in order to understand how you should go about theming it. In some cases you might want to re-work what a page consists of, so having a record of how it works on-hand will be a massive time-saver.

 

Segment for Selective Re-Theming

A full site re-theme can be a lot easier than just re-theming one section of a site. Thankfully in Drupal, you can still create a separate theme and use a tool like Themekey  to switch theme only for certain pages, based on URL, content type, user role or a myriad of other filters.

If you need to switch between different templates in a custom module based on which theme the site is using, globals such as $theme_key can come in handy to ascertain which theme template to serve, e.g:

<code>global $theme_key;
$theme_to_use = ($theme_key == 'new_custom_theme') ? 'new_theme' : 'old_theme';
return theme($theme_to_use, $vars);</code>

Consider Future Developers

There may come a time when a project you have worked on gets passed to someone else. You should always consider “future developers” when you produce any theme.

Try to follow the best practice for Drupal, maintain high and consistent coding standards and always be sure to comment any code you write. Avoid the pitfalls mentioned above and you might just make the next developer’s job that much easier!