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

[Ian Bezanson]

I've only been loosely following this thread, so my apologies if I'm repeating what anyone else has suggested already.  Although I will do anything and everything possible to avoid hacking core, there is one project I've been involved in where it simply was impossible to avoid.  This setup was running on 5.7 (IIRC) for over a year with no patching done, and was a growing concern.

Here's what I did:

1. Setup a mirrored test environment of your live site somewhere that you can 
   mess it up without taking your site down.
2. Open a text editor of choice and mark detailed examples of everything else 
   you find, so that your move to production is as smooth as possible.
3. Grab the base install of your version of Drupal 
   (e.g. http://ftp.drupal.org/files/projects/drupal-6.2.tar.gz) and untar it 
   in another directory.
4. Get a good diff program.  If using *nix, try running something like:
     $ diff -q your_dev_site drupal-5.2 | grep -v sites
   This should present you with a list of files that aren't the same, excluding
   anything under sites (which will - without a doubt - differ).
5. One-by-one note the differences between each core file and your own.  
   Provided you have downloaded the proper core version in Step 3, this should
   give you a comprehensive list of what you have changed.
6. Download the newest version of Drupal you wish to use (if you're doing a 
   major version upgrade, the rest of this is likely going to be a massive pain
   in the butt) and apply the hacks to the new code (if they are still necessary).
   This step isn't going to be 100% straightforward, as line 123 in file a, won't
   necessarily be the same line in the newest version of the same file (hey, new
   releases come for a reason).  If you hacked the code in the first place, you'll
   have to use some common sense when folding code back together.
7. Once the new code has been re-hacked, follow the Drupal upgrade path with said
   code.

If you've hacked contrib modules, rinse and repeat the general procedure for each of those.  The last time that I'd done a major upgrade of the site in question, I looked for any area possible where each hack could be removed in lieu of a better "Drupal" approach.  I was not able to remove all, but some at least.  Obviously, it is less than ideal to be running other than core, but I understand that sometimes it just needs to happen.  In my case, I was able to safely upgrade a site that sees 30k-60k unique visits/day in less than a day's effort.  It takes time, but if you do it right it won't be as complicated as you may expect.

I hope this helps,
 
--
Ian Bezanson
irb at ianbezanson.ca



On 2010-04-04, at 2:14 PM, FGM wrote:

> Dipen,
> 
> I'm working on very much the same predicament these days, except it's a slightly more recent version than 5.2 but with much the same problem (upgrade to 5.22 then 6). Maybe we could both save some time by working together on our respective problems with similar scripts/methods, and possibly come back to the community once we're done on how we did it. ? Feel free to contact me directly if this is of interest to you.
> 
> 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, since D5 was the first version which saw significant for-hire developments, most of them likely to have much the same kind of issues. And going out of support when D7 is released, real soon now :-)
> 
> Frederic G. MARAND
> OSInet
> 
> ----- Original Message ----- From: "nan wich" <nan_wich at bellsouth.net>
> To: <development at drupal.org>
> Sent: Sunday, April 04, 2010 7:04 PM
> Subject: Re: [development] Getting rid of core hacks for drupal upgrade tohappen. Need tips on the process.
> 
> 
> Indeed, I have to echo this sentiment. Many years ago, in a previous life, I was a systems programmer on large IBM mainframes. It was quite common practice then to hack the operating system. There were a few "hooks" but many times those were simply inadequate to do what some people thought were good ideas.
> 
> As time went on, it became a major challenge (as in hassle) to update the operating system. Some companies had armies of systems programmers just to maintain these hacks. I don't know if any ever actually sat down and figured out if they were really worth what they were spending to keep those hacks in place.
> 
> But I did when I went to a new job where the system hadn't been updated in four years and new computers that were on order (it could take 2 years then) made it mandatory to do so. As I began working on the hacks that were in place - and poorly documented, if at all - I realized that some were really not worth keeping and others could be reworked in such a way that they used real hooks.
> 
> All through this process I kept hearing "we've always done it that way." On the day we cut over to the new operating system (it was a big deal then), I had a tee-shirt made that said "We aren't going to do it that way any more."
> 
> Words to live by: "NO core hacks!"
> More words to live by: "No PHP pages!"
> It's not just words to live by - it's religion.
> 
> 
> Nancy E. Wichmann, PMP
> 
> Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
> 
> 
> ________________________________
> From: Yuval Hager yhager at yhager.com<mailto:yhager at yhager.com>
> 
> So before you dive in, if you are in position to, consider to make this a make
> D6 or break decision to the customer.
> 
>