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

[Dipen]

Thanks a lot for replying :)

Got to know of some great tools and approaches, I finally studied core hacks
in my code base and was somewhat relieved that around 30-40% of them are
quick theme hacks, which I think usually happens early in drupal learning
curve as I know the previous team was nascent to drupal during 5.2 days and
I believe they learned the best practices for theme overrides over the time
and started doing it the right way, but left the core changes as they were.


@Laura, @Matt @Yuval and others who proposed a re-do in 6.

 The major block of redoing it in 6 is the usual; time allocated for upgrade
to happen is rather short. Also like yuval said they are pretty attached to
their development efforts for last 2 and half years and any proposal to redo
the site in 6 (which took 2 years of atleast 1 person involvement)  is seen
from "Are you crazy, who have we hired" view point. So it would be hard to
pitch in. I have 15-20 days for doing upgrade and general clean up from
dirty tpl files.

Thanks for your suggestions, I really can feel that it would be easier and
far better in quality if I get the chance to redo and I am gonna push it for
last time tomorrow :) As I still feel uncomfortable with timeline and
following this process of taking it 5.22 and then porting 25-30 custom
modules (though they are small modules) to 6 :(.

@Marcel

Kdiff3 is cool

@Anyone trying to do diff's to find out core hacks and studying them I
suggest the following:

1> Do folder diff's using kdiff3, find out which files have been modified
(Usually all files will be show modified due to $Id; comment for SCM)
2> Open the "Real" changed core file in Tortoise Merge Tool (I am forced to
use windows :() to study the changes as it comes with a nice magnifying
perspective to show the lines which have changed, invaluable for effective
scrolling and locating in long files.
3> Document the reason of hack in a comment using a special tag like TODO,
so searching for them is easier.

Thanks a lot for your time.

Cheers
Dipen


On Mon, Apr 5, 2010 at 4:46 PM, Ian Bezanson <irb at ianbezanson.ca> wrote:

> 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/20100405/4792751a/attachment-0001.html