Re: [development] Getting rid of core hacks for drupal upgrade to happen. Need tips on the process.
On Thursday 01 April 2010 17:35:52 Laura wrote:
So consider wiping the code base entirely (not the database, though) and re-implementing in Drupal 6. If your D5 hacks did not result in alterations to the database structure, you can simply perform a stock D6 upgrade process and then implement through contributed modules and a new or refactored theme the various end results those hacks were trying to achieve. This way you can embrace what D6 offers first before resorting to coding up custom module implementations.
This is really the only viable option. I have been "burned" on such a project just recently. We quite quickly understood (and communicated to the client) that a complete wipe and re-implementation would be around the same price for the client, but will create a beyond compare higher quality product. However, the client have invested a lot of money in the D5 hacks crapware, that they were having a hard time deciding to wipe that completely. It was pure politics based decision, but c'est la vie. The approach we took was to diff the whole thing, as you suggested ('diff - aurwp drupal-5.2 drupal-5.2-hacked' if you are on linux) and study carefully all the differences. It is quite reasonable that core tables where hacked too (they were in my case), some even beyond any chance of cleaning up. That project went on for 7 months. The goals to stabilize the site (it crashed every two hours), make response time reasonable, and clean up the code base. The last task was the least important, and sometimes, I just had to keep the hacks in there, for reasons of cost vs. gain. At project end, the client received a bit less of what he should have had 7 months ago - a (mostly clean) Drupal 5.x install, with clean CCK, views, panels and a few other central modules. With this, the client could work further and start building features on top of that - but I am not involved any more there. So before you dive in, if you are in position to, consider to make this a make D6 or break decision to the customer. Depending on the amount of hacking done, but you'll probably spend hours on hours just to bring stuff to work as it should have in the first place. If you can't make it a clean D6, then good luck - you'll need all the luck you can get. Don't forget the other parts of core that do not ship with it - views and CCK were probably hacked too - as well as any other module in your project. From looking at the code I found that hacking core is a bit like stealing. If you don't get caught in the first time, you are tempted to continue on and on, until you really can't stop. --yuval
Sorry, the last message should have been a reply to Laura's email on this thread. I had a problem with my mailer, and had to resend, which probably caused it to lose the thread context. --y
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@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.
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@bellsouth.net> To: <development@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@yhager.com<mailto:yhager@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.
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,
I am afraid that the nature of these hacks is different every time, which makes each of us fight his own dragon. However, I might be wrong. feel free to contact me off list to try and share insights and patches that might be helpful to you guys.
since D5 was the first version which saw significant for-hire developments, most of them likely to have much the same kind of issues.
Yes, that is probably very true. D5 was a Gold release at the time, and a lot of folks who did not really understand opensource jumped on the wagon. D5 looked like it is enterprise ready, but it had a lot of problems with scaling, which created the need for hacks. Some hacks were made to save time, some were rightful patches that entered later versions of Drupal (user_load caching, blocks caching, locking API...).
And going out of support when D7 is released, real soon now :-)
Yes, that is a really good argument with clients. Wave the EOL at them and they will do anything you say :) --y
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@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@bellsouth.net> To: <development@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@yhager.com<mailto:yhager@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.
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@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@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@bellsouth.net> To: <development@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@yhager.com<mailto:yhager@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.
I wouldn't leave the sites directory out entirely because one may also put hacks into settings.php. Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr. ________________________________ From: Ian Bezanson <irb@ianbezanson.ca> To: development@drupal.org 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 irb@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@bellsouth.net> To: <development@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@yhager.com<mailto:yhager@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.
On Tue, Apr 6, 2010 at 3:52 AM, nan wich <nan_wich@bellsouth.net> 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 <irb@ianbezanson.ca> *To:* development@drupal.org *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 irb@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@bellsouth.net> To: <development@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@yhager.com<mailto:yhager@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.
participants (5)
-
Dipen -
FGM -
Ian Bezanson -
nan wich -
Yuval Hager