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

Yuval Hager yhager at yhager.com
Sun Apr 4 22:54:38 UTC 2010

> I'm answering on the dev. list because others might indeed be currently in
> the same predicament and we could probably all benefit from pooling our
> ideas on such problems, which are likely to become more frequent overall,

I am afraid that the nature of these hacks is different every time, which 
makes each of us fight his own dragon. However, I might be wrong. feel free to 
contact me off list to try and share insights and patches that might be 
helpful to you guys.

> since D5 was the first version which saw significant for-hire developments,
> most of them likely to have much the same kind of issues.

Yes, that is probably very true. D5 was a Gold release at the time, and a lot 
of folks who did not really understand opensource jumped on the wagon. D5 
looked like it is enterprise ready, but it had a lot of problems with scaling, 
which created the need for hacks. Some hacks were made to save time, some were 
rightful patches that entered later versions of Drupal (user_load caching, 
blocks caching, locking API...).

> And going out of
> support when D7 is released, real soon now :-)

Yes, that is a really good argument with clients. Wave the EOL at them and 
they will do anything you say :)


More information about the development mailing list