[development] Getting rid of core hacks for drupal upgrade to happen. Need tips on the process.
yhager at yhager.com
Sat Apr 3 09:37:30 UTC 2010
On Thursday 01 April 2010 17:35:52 Laura wrote:
> 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.
This is really the only viable option. I have been "burned" on such a project
We quite quickly understood (and communicated to the client) that a complete
wipe and re-implementation would be around the same price for the client, but
will create a beyond compare higher quality product. However, the client have
invested a lot of money in the D5 hacks crapware, that they were having a hard
time deciding to wipe that completely. It was pure politics based decision,
but c'est la vie.
The approach we took was to diff the whole thing, as you suggested ('diff -
aurwp drupal-5.2 drupal-5.2-hacked' if you are on linux) and study carefully
all the differences. It is quite reasonable that core tables where hacked too
(they were in my case), some even beyond any chance of cleaning up.
That project went on for 7 months. The goals to stabilize the site (it crashed
every two hours), make response time reasonable, and clean up the code base.
The last task was the least important, and sometimes, I just had to keep the
hacks in there, for reasons of cost vs. gain.
At project end, the client received a bit less of what he should have had 7
months ago - a (mostly clean) Drupal 5.x install, with clean CCK, views,
panels and a few other central modules. With this, the client could work
further and start building features on top of that - but I am not involved any
So before you dive in, if you are in position to, consider to make this a make
D6 or break decision to the customer. Depending on the amount of hacking done,
but you'll probably spend hours on hours just to bring stuff to work as it
should have in the first place. If you can't make it a clean D6, then good
luck - you'll need all the luck you can get.
Don't forget the other parts of core that do not ship with it - views and CCK
were probably hacked too - as well as any other module in your project. From
looking at the code I found that hacking core is a bit like stealing. If you
don't get caught in the first time, you are tempted to continue on and on,
until you really can't stop.
More information about the development