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 <[email protected]> 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 > [email protected] > > > > 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" <[email protected]> > > To: <[email protected]> > > 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 [email protected]<mailto:[email protected]> > > > > So before you dive in, if you are in position to, consider to make this a > make > > D6 or break decision to the customer. > > > > > >
