On Tue, Apr 6, 2010 at 3:52 AM, nan wich <[email protected]> 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 <[email protected]> > *To:* [email protected] > *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 > [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. > > > > > >
