[development] Getting rid of core hacks for drupal upgrade to happen. Need tips on the process.

[Matt Chapman]

I was just going to write the same thing as Laura. We are in the midst
of a very similar situation and that is exactly what we're doing. The
hacked D5 code base is essentially being ignored, and all work is
being done in D6, from scratch, based on the original requirements.

BTW, can I propose adding a checksum somewhere so Drupal can
self-detect if it's been modified, and then post the offender's
identity to the front page of Drupal.org to ensure they never get work
again? :-)

Unless they had a really good reason... ;-)

All the Best,

Matt Chapman
Ninjitsu Web Development

--
The contents of this message should be assumed to be Confidential, and
may not be disclosed without permission of the sender.



On Thu, Apr 1, 2010 at 7:48 AM, Randy Fay <randy at randyfay.com> wrote:
> +1
>
> You'll be happier in the long term if you just try to figure out the
> requirements and implement them with contrib and custom modules in D6. Or
> D7. D7 gives your project a couple more years of life.
>
> -Randy
>
> On Thu, Apr 1, 2010 at 8:35 AM, Laura <pinglaura at gmail.com> wrote:
>>
>> On Apr 1, 2010, at Thu 4/1/10 6:34am, Dipen wrote:
>>
>> > 1> Apart from svn history, diffing files one by one, does any one have
>> > suggestions to find out changes between hacked and clean file? Maybe at a
>> > folder level? Like diff the whole include folder or diff the whole modules
>> > folder. (I know about beyond compare, anything else?)
>> >
>> > 2> Any tips, experiences, suggestions on the process of removing core
>> > hacks and implementing them outside of core.
>> >
>> > 3> Any suggestions on the whole approach? If it can be made more
>>
>> This may be an approach that will not appeal to you and your team....
>>
>> Drupal 6 is in many ways profoundly different from Drupal 5, to the point
>> that trying to reverse engineer D5 hacks to complement D6 may be a quite
>> inefficient way to go. One thing to consider is that existing D6-based
>> solutions may provide ready replacements for some of the D5 hacks. In some
>> ways, you may end up "crossgrading" rather than "upgrading" much of your
>> site.
>>
>> 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.
>>
>> In other words, start with the goals, the use cases, the desired results,
>> and don't assume that the D5 hack logic will carry over into D6 modules.
>> Your content lives in the database and uploaded files. Treat the rest of
>> your site as disposable — to be used as notes but not necessarily as
>> technical architecture.
>>
>> Laura
>>
>>
>
>
>
> --
> Randy Fay
> Drupal Development, troubleshooting, and debugging
> randy at randyfay.com
> +1  970.462.7450
>
>