Hi, When developing with Drupal you often use contrib modules. When using contrib modules it happens that you find a bug or need it to behave differently than what was intended. So you modify the module. Now you have to have a method for knowing that this module is no longer the stock contrib module. I've seen different shops hande this in different ways but never really in a robust way. That's why I want to suggest the "module checksum" module. When you activate a module, the directory it is in is checksummed and the result stored. The module then allows you to rerun the checksum against all modules and shows for which modules the new checksum no longer matches. These are the modules that have been modified. With this list you can make sure you have the necessary patches before you upgrade said modules. I've briefly looked around and have not found anything like this. Is there? Any other suggestions or remarks? If not, I think I'll go ahead and make it. Best regards, Olivier
Hi Olivier, Many of us just use straight CVS checkouts of the modules. Then you can just do a CVS diff and see what kinds of changes you made to the module, if you did. Gábor On Wed, Feb 11, 2009 at 12:46 PM, Olivier Jacquet <ojacquet@jax.be> wrote:
Hi,
When developing with Drupal you often use contrib modules. When using contrib modules it happens that you find a bug or need it to behave differently than what was intended. So you modify the module.
Now you have to have a method for knowing that this module is no longer the stock contrib module. I've seen different shops hande this in different ways but never really in a robust way.
That's why I want to suggest the "module checksum" module. When you activate a module, the directory it is in is checksummed and the result stored. The module then allows you to rerun the checksum against all modules and shows for which modules the new checksum no longer matches. These are the modules that have been modified. With this list you can make sure you have the necessary patches before you upgrade said modules.
I've briefly looked around and have not found anything like this. Is there? Any other suggestions or remarks? If not, I think I'll go ahead and make it.
Best regards, Olivier
Gábor Hojtsy wrote, On 11/02/2009 13:31:
Hi Olivier,
Many of us just use straight CVS checkouts of the modules. Then you can just do a CVS diff and see what kinds of changes you made to the module, if you did.
Gábor
Thanks for the tip. I've tried it and I'll be using that method from now on. Even updates to a new version work that way and if your custom changes do not interfere they stay active.
There also this module attempting a solution: http://drupal.org/project/file_integrity -- Alan Doucette
That's why I want to suggest the "module checksum" module. When you activate a module, the directory it is in is checksummed and the result stored. The module then allows you to rerun the checksum against all modules and shows for which modules the new checksum no longer matches. These are the modules that have been modified. With this list you can make sure you have the necessary patches before you upgrade said modules.
Best regards, Olivier
Just indicating that a module has been altered is too limited, IMO. Journal module (http://drupal.org/project/journal) recently implemented a "Patch log" feature (only available in latest dev snapshot currently), which allows you to keep track of any patches and hacks you applied to the modules on your site. This means you can lookup whether you can safely update to a later version of a module (given the possibility that your patch has been committed). Daniel
Olivier Jacquet wrote:
When developing with Drupal you often use contrib modules. When using contrib modules it happens that you find a bug or need it to behave differently than what was intended. So you modify the module.
Now you have to have a method for knowing that this module is no longer the stock contrib module. I've seen different shops hande this in different ways but never really in a robust way.
Your mileage may vary, but I've found that checking code out from CVS helps a lot when tracking local modifications. I deploy all my sites this way. If you don't want to use the dev branch, you can check out a sticky release tag, too - you won't get updates via "cvs update" that way, but you'll still be able to see all your local modifications. That doesn't mean yours is not a good idea, of course. :) -- Arancaytar ---------------------- Nothing beside remains: Round the decay Of that colossal wreck, boundless and bare The lone and level sands stretch far away... ---------------------- PGP: http://ermarian.net/downloads/0x27CA5C74 XMPP: arancaytar.ilyaran@gmail.com AOL: 282026638 / RealArancaytar URL: http://ermarian.net
Arancaytar Ilyaran wrote:
Olivier Jacquet wrote:
When developing with Drupal you often use contrib modules. When using contrib modules it happens that you find a bug or need it to behave differently than what was intended. So you modify the module.
Now you have to have a method for knowing that this module is no longer the stock contrib module. I've seen different shops hande this in different ways but never really in a robust way.
Your mileage may vary, but I've found that checking code out from CVS helps a lot when tracking local modifications. I deploy all my sites this way. If you don't want to use the dev branch, you can check out a sticky release tag, too - you won't get updates via "cvs update" that way, but you'll still be able to see all your local modifications.
That doesn't mean yours is not a good idea, of course. :)
Apologies for the redundancy, my mail client had only downloaded the first message of this thread for some reason. Of course this has been said before by now. :) -- Arancaytar ---------------------- Nothing beside remains: Round the decay Of that colossal wreck, boundless and bare The lone and level sands stretch far away... ---------------------- PGP: http://ermarian.net/downloads/0x27CA5C74 XMPP: arancaytar.ilyaran@gmail.com AOL: 282026638 / RealArancaytar URL: http://ermarian.net
For this to be really useful, it would need to integrate into update.module. Doesn't Acquia Drupal include something like this already? Could that be generalized? (Many of us check modules out from CVS directly, but many of us don't. I don't, generally.) --Larry Garfield On Wed, 11 Feb 2009 12:46:49 +0100, Olivier Jacquet <ojacquet@jax.be> wrote:
Hi,
When developing with Drupal you often use contrib modules. When using contrib modules it happens that you find a bug or need it to behave differently than what was intended. So you modify the module.
Now you have to have a method for knowing that this module is no longer the stock contrib module. I've seen different shops hande this in different ways but never really in a robust way.
That's why I want to suggest the "module checksum" module. When you activate a module, the directory it is in is checksummed and the result stored. The module then allows you to rerun the checksum against all modules and shows for which modules the new checksum no longer matches. These are the modules that have been modified. With this list you can make sure you have the necessary patches before you upgrade said modules.
I've briefly looked around and have not found anything like this. Is there? Any other suggestions or remarks? If not, I think I'll go ahead and make it.
Best regards, Olivier
participants (6)
-
Arancaytar Ilyaran -
Daniel F. Kudwien -
dragonwize -
Gábor Hojtsy -
Larry Garfield -
Olivier Jacquet