A General Strategy for Customizing Open Source Applications

In the course of developing web sites for clients, we incorporate a lot of off the shelf open source software. This includes packages such as WordPress, MediaWiki, Gallery2, Zen Cart, and others. To use these applications in our client sites we need to customize the templates and possibly add in extensions, but we don’t want to include the entire application in our client site Subversion repository.

Many applications, such as Zen Cart and MediaWiki are intended to be unpacked into the live web tree and then installed through a web interface. If we included the application in the Subversion repository, every time we ran the script to copy from the working copy to the development staging site we would override the customized configuration files and break the application. Also, by having the source code in our Subversion tree, every time a new release came out we’d have to merge that into our code. Also it makes it hard to determine what files we have customized and what is stock with the application. None of these are very attractive outcomes.

Instead, we create an empty directory structure within our repository for the directories that we need to customize and then copy in only those files which we actually need to modify. For example, with WordPress it might look like:

  /path/to/website/blog
    /path/to/website/blog/wp-content
      /path/to/website/blog/wp-content/themes
        /path/to/website/blog/wp-content/themes/mytheme
          /path/to/website/blog/wp-content/themes/mytheme/header.php
          /path/to/website/blog/wp-content/themes/mytheme/index.php
          /path/to/website/blog/wp-content/themes/mytheme/footer.php
          /path/to/website/blog/wp-content/themes/mytheme/...

By doing this, we can copy the working copy to the live web server it will only overwrite the files that we are managing and leave the rest of the installation alone. We are free to upgrade the WordPress install without having to touch the development tree. And it makes it very clear what we have changed, since only those files which we have modified are reflected in the repository.

While we use WordPress as an example, this approach works for MediaWiki, Zen Cart, Gallery2, and others. This approach is also not limited to themes and templates. Extensions and plugins can be managed in the same way.

 

Trackbacks

(Trackback URL)

close Reblog this comment
blog comments powered by Disqus