Drupal: Staying Organized with Module Changes

Question

The deeper I get with Drupal the more I have to make changes to code within other people's modules. These are usually small changes, and so far it doesn't make sense to rewrite the module's functionality for my own needs.

I'm trying not to make any modifications to Drupal core since that just seems like asking for trouble.

But sooner than later, I'm going to need to update these modules with new releases and then repatch my changes back in. How do you stay organized when making these changes, upgrading modules, and re-applying your changes back?

I'm taking as many notes as I can but the spiderweb is growing around me!

Answer 1

There is a good discussion in this question.

I particularly like Nick Sergeants article describing a method where you checkout the Drupal sources via CVS and then control your changes and the CVS records using SVN.

Answer 2

The book Leveraging Drupal: Getting Your Site Done Right (Wrox Programmer to Programmer) describes workflow and developing sites with cvs/svn from the beginning.

It's only $32 free shipping at amazon right now (as low as $24 used but remember $4 shipping you might as well get it new. I recommend checking your library for it, if they don't have it try inter-library loan. But this book describes exactly what you are seeking, step by step.

Answer 3

Another key is to maintain explicit .patch files for any changes you make, and include documentation with them. If you have to upgrade to a new version of a module, install the clean copy and re-apply the patch. If it doesn't re-apply cleanly, you know you've got a problem.

That's where maintianing your own source tree in SVN/git/etc can be handy.

Answer 4

Do you change the module in a way other people may benefit?

Then send the patch to the module maintainer, so everybody benefits and you don't have the trouble to stay organised.

Answer 5

You only have the two already mentioned Options.

1.) If your changes can benefit the community then give back and hopefully it will become Part of the next release.

2.) If your changes are to specific and fit only your needs than your only chance to stay organized is setting up your own VCS (e.g. Subversion) and learn to use it properly.. ;)

There are some good infos on using Subversion with drupal on the Drupal.org site.

There is also a new Module available that allow you to capture some features into your own modules (e.g. features (http://drupal.org/project/features)). I have not much experience with it but maybe this is also a solution for you.

Answer 6

The way that Eaton describes above tends to be how we handle the situation for relatively large sites. If you keep a running log of patches, you can always re-create changes.

One of the aspects that seems to be missed in a lot of the "submit back to the community" posts is that just because you submit it back to the community doesn't mean it'll ever get applied. The way we handle this scenario is by keeping an explicit patch file with an indication of what D.O. issue it's related to. In the case where the patch is eventually integrated, you can remove your patch and pat yourself on the back. In the scenario where your patch is never accepted, at least you still have your log.