There’s a good TextMate bundle to support Git, but to be honest I’ve mostly used the command-line.

Weaknesses.

Vendor branching is possible, but awkward. I frequently use vendor drops of WordPress, SimpleTest and a number of other libraries. There may be a good way of doing this, but I haven’t found it online… yet.

I miss the svn:externals functionality, especially in applications that use a lot of plugins: WordPress in particular. Subversion allows me to define particular tagged versions of these to be pulled from their repositories during deployment without needing to bother controlling them myself.

Strengths.

Branch merging when trying out new ideas is a dream. I created a new branch, refactored huge sections of the codebase, and merged it all back together flawlessly. With Subversion this would have been a lot slower and more problematic. Git’s simply great for those investigatory spikes.

The verdict for Git.

I’ve yet to seriously try Git to interface with my remote Subversion repositories, using the ‘git svn’ series of commands. Having local copies of these, whilst still being able to use remote Subversion would be very useful. I’ve found using remote Subversion repositories easy, but trying to push a Git repository to Subversion is not so easy. I’m also going to try deploying from a Git repository using Capistrano in the near future.

It strikes me that Git is best at programmer related activities and weakest in those of interest to administrators deploying applications. I shall certainly continue to use it, but alongside Subversion.

Redefining the Architecture.

I decided to start again by defining the information architecture for the site based on a proper discussion with the Club committee. The first few meetings on this topic just weren’t as well focused as they should have been; mostly my fault for not knowing what I wanted from them; but this time I tried targeting those features that the membership would really value. Each of the features that emerged seemed to fall into logical sections of the information architecture:

• About the Club — including notices, events and membership contacts.
• Content on Birding — after all it’s the main focus of the Club.
• Social groups within the Club divided by specific interest.

These overall sections were used as containers for the more specific features, and these formed the basis for implementation.

I’ve tried an online tool called WriteMaps for developing and sharing the architecture of this site. I haven’t decided whether it’s the best way to approach the job yet, but here’s the link to the detailed sitemap.

Implementing the Design.

The original site used custom taxonomy — tagging — to enforce the architecture, with multiple sections of the site sharing the same content types. As I mentioned, this made it very confusing for the Club editors, which was reflected in the site presentation.

Installing new modules.

I needed to add several new modules to support the new content. There are several ways of doing this; this alone is a substantial topic; but the simplest is to download the module directory containing the code into the modules directory of your Drupal installation.

Content types.

For this redesign I decided that each of the features should have a dedicated content type so that users only need select the right one, there’s help text as you can see, and it’ll end up in the right place on the website. No more messing about with tags!

A great tool for this is the Content Construction Kit (CCK) module. It makes implementing new content types very easy; no PHP required; and there are a wide range of modules that provide additional data fields. I’ve used several to provide dates, images and even GoogleMaps, take a look at the full list of compatible modules on the Drupal website.

Once the CCK module is installed, all the changes you want to make can be managed from the Content types section of Content Management.

Providing access.

All these new content types need to have access control set–up before you can go any further. This is done in Access control, under User Management in the administration section of Drupal.

You should find both create and edit options to set under node module for the new content types.

Once these are set the content types should appear on the appropriate create content menus.

Setting up the paths.

But you’ll want to set the URLs to reflect the new architecture before deploying.

I use Pathauto to provide aliases for my content that better reflect the structure of the website and present friendly URLs. You can do this manually, but if you can’t rely on your users to do this consistently I would recommend using Pathauto.

The Pathauto settings are under Site Configuration, and it’s the Node paths you want to set–up for your new content.

These, combined with the individual content types, provide the structure for the website. For example I wanted the bird guide to appear within the birding section of the site architecture with individual entries beneath this, so I set the pattern to birding/birdguide/[title].htm.

Time for a View.

The Views module provides the ability to present node data in a range of different formats. With the module installed your views can be managed from the Administer views section found under Site building.

Here you can define new views for each of the content types and define a URL from which the specific view can be accessed in the browser. In the image above you can seen that I wanted the bird guide list to appear as the default in the bird guide, and gave it the URL birding/birdguide. These views can generate lists, tables and customised sorting, in addition to the more standard web page presentations.

…And a menu.

Finally we’re going to want a menu from which all our good work can be accessed. The menus and blocks in Drupal can all be found in the Site building section.

The sequence is simple, first create a new menu for the features you’ve implemented, under the Menus section, using the URLs of the views;

and then go to the Blocks section and put the new menu where you want it to appear on the website.

That should be it! Your new functionality has been added.

Conclusions?

Having established this workflow, I implemented each of the identified features one at a time, ensuring it was working and acceptable before moving on to the next.

I believe, and feedback suggests my users agree, that this approach to building a Drupal website is far more successful than a taxonomy based one. I still use taxonomy, but it now provides addition information for particular types of content rather than forming the basis for site architecture.

As for Drupal itself, it’s relatively easy to use, even without significant PHP knowledge, and the large community provides a huge range of contributed modules and support. This makes it a powerful way to develop feature rich, multi–user websites very quickly.

On the downside, I’ve found providing users with an easy way to upload and insert images very difficult. There are serious problems with using the popular TinyMCE WYSIWYG editor and IMCE file handling together; individually they work OK, but together… I need to look at this again.

I would definitely recommend trying Drupal out if you need a CMS, for an image rich website; such as a gallery; I’d try Flickr or, for ultimate control, hand coded XHTML.

I’ve always edited my online content remotely, I have a local copy and can work off–line. I use TextMate for most of my development work and I’ve been using it for blogging too.

OK… I was reluctant to change. I like having full control over mark–up and haven’t been impressed by a WYSIWYG editor yet, for Web use at least. Untried, I ranked MarsEdit amongst them.

I must apologise to the developers. It’s a great and flexible tool. Hope I’ll be doing a little more blogging!

On the Web.

My production server environment is virtualized by the Xen hypervisor; providing a more flexible and cost effective solution.

I like the freedom of complete root access but, given my relatively low traffic volumes, the cost of a dedicated server would be prohibitive. However, Xen provides me with my own little chunk of hardware resources that no other user’s going to break for me.

The great thing is that these resources can be altered very quickly to respond to changes in my requirements; great scalability in a changeable world.

On the Desktop.

I’m also making extensive use of virtualization on my desktop using VMWare Fusion. I’m a Mac user, but one of the attractions of the VMWare product is the interchangeability of any virtual machine (VM) between platforms.

VMWare Fusion.

VMWare have been in the business of Virtualization of a while now, and have a powerful range of products. Whilst many of these are targeted at the enterprise environment, Fusion is definitely a consumer product; in a good way; and the benefits to me so far…

• Surprisingly seamless Windows XP including Office, in my experience a much better product than the sadly neglected Mac version. Fusion has a ‘Unity’ mode, which places these applications, running in a Windows environment, right on my Mac desktop.
• I’ve tried different Linux flavours for the desktop and server, and I haven’t needed multiple machines. A great asset when you like to dabble but don’t have much free space; small house you see; and want to keep the bills down.
• I’ve tried a whole range of software products without the usual worry of messing up my regular working platform, if it all goes wrong I just delete the VM and start again. If I might want to return to this set‒up again, I can take a snapshot of the current installation, or copy the VM file to a backup location so I don’t have to start from scratch each time.
• Finally, I’ve build VMs of the production server for deployment testing. I know that they’re not identical, but they’ve been good enough to iron out problems in build and deployment scripts before unleashing them on the production server itself.

A virtual network.

Fusion has a built‒in DHCP server to provide IP addresses, or they can be assigned by an external network using the bridged network option.

After exploring these options I discovered that I could build a virtual development network right on my laptop and make it as private as I want. Oh, yes, you can fix the IPs the server hands out, making it much easier to edit that hosts file.

The NAT option can access the outside world, to install updates for example, by sharing the host connection. However it’s protected from external access. My physical home network uses NAT via an ADSL router, but this is a great option if you’re likely to take your laptop network out on the road and I use it for the majority of my installations.

If you’re even more worried about unauthorised access to your latest development project, you can use the host‒only option; access only from the host machine or other local VMs using this network set‒up.

With all the VMs using the same network option, they can all see and access one another. So now I can write my code on the host Mac, test deployment to a virtual CentOS Linux server, and check how it looks on Windows. It’s self contained, I can flip between machines and it’s all totally mobile.