Thanks a lot for replying :) <div><br></div><div>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. </div>
<div><br></div><div><br></div><div>@Laura, @Matt @Yuval and others who proposed a re-do in 6. </div><div><br></div><div> 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. </div>
<div><br></div><div>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 :(.</div>
<div><br></div><div>@Marcel</div><div><br></div><div>Kdiff3 is cool </div><div><br></div><div>@Anyone trying to do diff's to find out core hacks and studying them I suggest the following:</div><div><br></div><div>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) </div>
<div>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.</div>
<div>3> Document the reason of hack in a comment using a special tag like TODO, so searching for them is easier. </div><div><br></div><div>Thanks a lot for your time.</div><div><br></div><div>Cheers</div><div>Dipen </div>
<div><br><br><div class="gmail_quote">On Mon, Apr 5, 2010 at 4:46 PM, Ian Bezanson <span dir="ltr"><<a href="mailto:irb@ianbezanson.ca">irb@ianbezanson.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<br>
<br>
Here's what I did:<br>
<br>
1. Setup a mirrored test environment of your live site somewhere that you can<br>
mess it up without taking your site down.<br>
2. Open a text editor of choice and mark detailed examples of everything else<br>
you find, so that your move to production is as smooth as possible.<br>
3. Grab the base install of your version of Drupal<br>
(e.g. <a href="http://ftp.drupal.org/files/projects/drupal-6.2.tar.gz" target="_blank">http://ftp.drupal.org/files/projects/drupal-6.2.tar.gz</a>) and untar it<br>
in another directory.<br>
4. Get a good diff program. If using *nix, try running something like:<br>
$ diff -q your_dev_site drupal-5.2 | grep -v sites<br>
This should present you with a list of files that aren't the same, excluding<br>
anything under sites (which will - without a doubt - differ).<br>
5. One-by-one note the differences between each core file and your own.<br>
Provided you have downloaded the proper core version in Step 3, this should<br>
give you a comprehensive list of what you have changed.<br>
6. Download the newest version of Drupal you wish to use (if you're doing a<br>
major version upgrade, the rest of this is likely going to be a massive pain<br>
in the butt) and apply the hacks to the new code (if they are still necessary).<br>
This step isn't going to be 100% straightforward, as line 123 in file a, won't<br>
necessarily be the same line in the newest version of the same file (hey, new<br>
releases come for a reason). If you hacked the code in the first place, you'll<br>
have to use some common sense when folding code back together.<br>
7. Once the new code has been re-hacked, follow the Drupal upgrade path with said<br>
code.<br>
<br>
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.<br>
<br>
I hope this helps,<br>
<font color="#888888"><br>
--<br>
Ian Bezanson<br>
<a href="mailto:irb@ianbezanson.ca">irb@ianbezanson.ca</a><br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
On 2010-04-04, at 2:14 PM, FGM wrote:<br>
<br>
> Dipen,<br>
><br>
> 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.<br>
><br>
> 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 :-)<br>
><br>
> Frederic G. MARAND<br>
> OSInet<br>
><br>
> ----- Original Message ----- From: "nan wich" <<a href="mailto:nan_wich@bellsouth.net">nan_wich@bellsouth.net</a>><br>
> To: <<a href="mailto:development@drupal.org">development@drupal.org</a>><br>
> Sent: Sunday, April 04, 2010 7:04 PM<br>
> Subject: Re: [development] Getting rid of core hacks for drupal upgrade tohappen. Need tips on the process.<br>
><br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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."<br>
><br>
> Words to live by: "NO core hacks!"<br>
> More words to live by: "No PHP pages!"<br>
> It's not just words to live by - it's religion.<br>
><br>
><br>
> Nancy E. Wichmann, PMP<br>
><br>
> Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.<br>
><br>
><br>
> ________________________________<br>
> From: Yuval Hager <a href="mailto:yhager@yhager.com">yhager@yhager.com</a><mailto:<a href="mailto:yhager@yhager.com">yhager@yhager.com</a>><br>
><br>
> So before you dive in, if you are in position to, consider to make this a make<br>
> D6 or break decision to the customer.<br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>