[development] Getting rid of core hacks for drupal upgrade tohappen. Need tips on the process.
dipench at gmail.com
Mon Apr 5 14:48:21 UTC 2010
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 :(.
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.
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
> mess it up without taking your site down.
> 2. Open a text editor of choice and mark detailed examples of everything
> 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
> 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,
> 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
> 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
> in the butt) and apply the hacks to the new code (if they are still
> This step isn't going to be 100% straightforward, as line 123 in file a,
> necessarily be the same line in the newest version of the same file (hey,
> releases come for a reason). If you hacked the code in the first place,
> 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
> 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
> > 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
> > 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
> > D6 or break decision to the customer.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the development