When I create a git repository for a new project on Drupal.org I don't bother to create a master branch, branches named 6.x-1.x or 7.x-1.x have special meanings and are the ones that we're encouraged to use. However, drupal.org doesn't allow us to change the default branch on d.o itself, so even though there may be no branch called 'master', it's still the default branch, so sometimes cloning a repo will fail:
The Entity token module is part of the Drupal Entity Module package, it provides lots of new tokens to use everywhere that tokens are currently available. It does this by being aware of the structure of fields on entities and exposing extra options for fields that reference entities. For example, it allows you to use many more tokens about taxonomy terms added to content.
To see this in action we'll consider a simple example.
Drupal 7 ships with a module called 'Overlay', it is installed by the standard install profile and actually is pretty great for most people. If you don't know what I'm talking about then, it's this:
It's basically a nice wrapper around the jQueryUI Dialog component and has some nice features, like keeping the URL fragment up to date with the page being viewed in the overlay. This means you can create a link that goes to a page, and then opens the overlay automatically, it also means that it doesn't break the 'back button'. Using the drupal overlay it's very simple to get a page to open up in a modal popup, wouldn't it be great if you could just get one of your pages to open up in the overlay?
We put almost all of our Drupal sites behind the excellent Varnish HTTP accelerator, and it gives us a massive performance boost for most site visitors. However it seems to have a tendency to crash without warning and occasionally just dies, leaving our sites down.
We workaround this issue by using another piece of useful kit, called Monit, that keeps an eye on processes on your server and restarts them if necessary.
We recently needed to migrate all our sites on one physical server to another server, there were more than 200 sites, and they were all hosted with Aegir. The old server was to be decommissioned, so we had to move all of Aegir's data about the site to the new server import into a new Aegir master on the new server. We also needed to do this with as small amount of downtime as possible.
In the end we migrated all the sites with about 30 seconds of downtime each, here's how:
As the year draws to a close we thought it would be appropriate to look back at an exciting year in for Drupal modules, and to list our top 5 Drupal modules of 2011. To qualify for the list the module had to have it's first release in 2011, and have a Drupal 7 version - other than that, anything goes.
Drupal 7 brought us Entities, and with them the powerful Field API for 'storing, loading, editing, and rendering field data.' attached to them. If you're managing everything through 'manage fields' and 'manage display' tabs of your content type, then every part of that process is rather wonderfully taken care of for you.
We often, however, come across the need to render a field outside the context of it's entity. A common example might include rendering a node's author in a sidebar block. Sure, modules like Panels and CCK Blocks will do this for you, but doing it manually is actually not that hard.
Most projects start with you trying out something locally, getting it working and then after some initial testing you might then want to publish the project on Drupal.org. Sandboxes are a great way to throw up some code and the perfect place to pop random code that others might find useful or a project that you just don't want to maintain. If you go and create one on Drupal.org then you'll get helpful instructions for creating a new git repository and creating a basic module to go in the repository and then pushing that code to Drupal.org's servers.