FAQ
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

Search Discussions

  • Gábor Hojtsy at Feb 11, 2009 at 12:31 pm
    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 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
  • Olivier Jacquet at Feb 11, 2009 at 2:00 pm

    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.
  • Dragonwize at Feb 11, 2009 at 3:03 pm
    There also this module attempting a solution:
    http://drupal.org/project/file_integrity

    --
    Alan Doucette
  • Daniel F. Kudwien at Feb 11, 2009 at 12:42 pm

    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
  • Arancaytar Ilyaran at Feb 11, 2009 at 3:28 pm

    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 at gmail.com
    AOL: 282026638 / RealArancaytar
    URL: http://ermarian.net

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 250 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.drupal.org/pipermail/development/attachments/20090211/db788780/attachment-0001.pgp
  • Arancaytar Ilyaran at Feb 11, 2009 at 3:32 pm

    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 at gmail.com
    AOL: 282026638 / RealArancaytar
    URL: http://ermarian.net

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 250 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.drupal.org/pipermail/development/attachments/20090211/71025fe4/attachment.pgp
  • Larry Garfield at Feb 11, 2009 at 5:49 pm
    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 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdevelopment @
categoriesdrupal
postedFeb 11, '09 at 11:46a
activeFeb 11, '09 at 5:49p
posts8
users6
websitedrupal.org
irc#drupal

People

Translate

site design / logo © 2022 Grokbase