[development] Getting rid of core hacks for drupal upgrade to happen. Need tips on the process.

Laura pinglaura at gmail.com
Thu Apr 1 14:35:52 UTC 2010


On Apr 1, 2010, at Thu 4/1/10 6:34am, Dipen wrote:

> 1> Apart from svn history, diffing files one by one, does any one have suggestions to find out changes between hacked and clean file? Maybe at a folder level? Like diff the whole include folder or diff the whole modules folder. (I know about beyond compare, anything else?)
> 
> 2> Any tips, experiences, suggestions on the process of removing core hacks and implementing them outside of core.
> 
> 3> Any suggestions on the whole approach? If it can be made more 

This may be an approach that will not appeal to you and your team....

Drupal 6 is in many ways profoundly different from Drupal 5, to the point that trying to reverse engineer D5 hacks to complement D6 may be a quite inefficient way to go. One thing to consider is that existing D6-based solutions may provide ready replacements for some of the D5 hacks. In some ways, you may end up "crossgrading" rather than "upgrading" much of your site.

So consider wiping the code base entirely (not the database, though) and re-implementing in Drupal 6. If your D5 hacks did not result in alterations to the database structure, you can simply perform a stock D6 upgrade process and then implement through contributed modules and a new or refactored theme the various end results those hacks were trying to achieve. This way you can embrace what D6 offers first before resorting to coding up custom module implementations.

In other words, start with the goals, the use cases, the desired results, and don't assume that the D5 hack logic will carry over into D6 modules. Your content lives in the database and uploaded files. Treat the rest of your site as disposable — to be used as notes but not necessarily as technical architecture.

Laura




More information about the development mailing list