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

[Dipen]

On Tue, Apr 6, 2010 at 3:52 AM, nan wich <nan_wich at bellsouth.net> wrote:

> I wouldn't leave the sites directory out entirely because one may also put
> hacks into settings.php.
>


 Indeed :) the team keeps 2 settings files here and include the other one
from settings.php which has lots of variable definition, web service end
point url's etc.

Thanks



>
>
> *Nancy E. Wichmann, PMP*
>
> Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L.
> King, Jr.
>
>
>  ------------------------------
> *From:* Ian Bezanson <irb at ianbezanson.ca>
> *To:* development at drupal.org
> *Sent:* Mon, April 5, 2010 7:16:33 AM
>
> *Subject:* Re: [development] Getting rid of core hacks for drupal upgrade
> tohappen. Need tips on the process.
>
> 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.
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20100406/80a0b7b0/attachment.html