development

Hello! I'm back. I've not made any blog posts in over a year and a half due to the site where my blog was before, drupaler.co.uk, closing down. And while it took me some time to get round to writing a Migrate script to import my posts from the old site's database, it was actually getting round to setting up this new domain that took the longest.

So what have I been doing all this time? Especially as I still don't have a single Drupal 7 site out there to my name? Well, these days I work on a humongous web application which has kept me busy for the last 18 months; it's a large Drupal site (we hit a million of one of its several custom entity types recently), but to the general public it's just a login page. I may talk more about the development challenges in future posts.

Prior to that, I was building what would have been one of the earliest big Drupal Commerce sites to launch... except that very shortly before launch in October 2012, the whole project got canned.

That was obviously rather demoralizing, as it had been a year in the building. However, it's interesting to look back and see just how much a large-scale project can contribute back to the Drupal community. The following is a list of the contrib modules that were created as part of the development of the project. Many of them are pretty simple; many of them don't get that much use. But they get some, and so it's interesting to see how much code a project can share if development is steered towards reusability, and also how a single project, even one that never sees the light of day, can have effects that ripple out and benefit many others.

Reference field option limit

This was built to improve the UI for selecting terms from large taxonomies, where one vocabulary groups another. For example, you could have a huge vocabulary of cities, and a smaller one of cities. Each city term has a term reference to the country it belongs to (the glee of the early days of Drupal 7: all the fields on all the things!), and the entity that you want to tag (in my case a product) has term reference fields to both the country and the city. The way this module works is that the city terms shown in one widget are filtered each time you change the selected country term in the other field's widget. So you select 'France' and the city field widget updates with AJAX to show only cities in France.

It sounds simple to explain (I hope!), but involves a fair amount of work under the hood in the form alteration to pull it off. It's one of my most popular modules, and has received a fair number of patches from other users.

Devel Contrib and Field Tools

These two are developer modules. Devel Contrib arose from my constantly needing to dsm() the data from info hooks such as hook_views_data() and hook_entity_property_info(). When the thing you're developing keeps going wrong, one of first things to do is poke around to check you've properly declared everything to the APIs you're using. I started out just having this as a couple of menu items declared in a custom module, but pretty soon I added more, and I wanted it on other development sites, so the obvious thing to do was clean it up and release it.

Field Tools was something I wrote because the Commerce site in question had dozens of different product types and corresponding node types, with lots of common fields, and I really didn't want to spend hours clicking through the field admin UI to set them up. This may seem like a case of condiment-passing, but I'm sure it's saved me hours of tedium: create the fields once, and then quickly clone them to any other entity types and bundles.

Field Instance Cardinality

A very small tweak module, this lets you override a particular instance of a multi-valued field and set it to be single-valued only. It's a hook_form_alter() hack made reusable by adding some field admin settings, and a good example of how site customization can often be done as modules rather than alter hacks.

Field Value Link Formatter

Very simple module: your taxonomy term fields (or other entity references) should link to a view with an entity ID argument. I guess the more traditional way of doing this is with a lot of path aliases for your taxonomy terms. I think we may also have used this to create Profile-style lists of related entities.

Commerce Shipping Weight Tariff

This was created to deal with the complex business rules we had for shipping costs. Written very near to our planned launch date, it's an example of what I call the 'skimp on the admin UI' contrib module: hardcode the settings, but do so in a way that's cleanly separated from the rest of the module, so that later on an admin UI can be added, perhaps contributed as a patch. Though I think that's yet to materialize for this one.

Views Grouped Table

This was created to help keep track of how the product entities and product display nodes all related to one another.

Views Dependent Filters

Allows the presence of exposed filters on a view to be controlled by values in another exposed filter. This was intended to handle filtering Views of products, though we later switched to using Views with Solr.

Taxonomy add previous

A little bit of UX sugar for when you're adding lots of taxonomy terms that are very similar. In our case, this was terms representing sizes. On creating a new term, this takes you straight back to the form for adding another term, and prefills the field values from the one you just added.

Flag Expire

Allows flags to have either an expiry date, or an expiry period. This was going to be used to feature products, or mark them as new, or discounted. (For new product, you could just automatically mark all products that were created in the last x days, say. But as I recall, the client didn't want ALL new products marked, just selected ones. The way clients do.)

As well as new contrib modules, the project resulted in work on existing contrib modules, in particular Flag, Data, Views Hacks, and Commerce Delivery.

I've been putting off setting up multisite on my localhost for ages, mostly because in the past I've found getting Apache virtual hosts to work can be a bit tricky: not impossible, but the sort of thing where I could easily lose an hour on a minor thing I've forgotten to do. And after all, with a shiny new iMac and a hard drive whose proportions I can't even remember, why not just 'drush dl' all over again?

But I'm actually working on a multisite project at the moment, and suddenly getting this to work becomes more interesting than having another SVN copy of my code kicking around.

Given multisite can respond to subfolders, I was wondering if this could work when Drupal itself is in a subfolder, like this:

Turns out it can. Suppose you want a new subsite called 'drupal-subsite'. Here's what to do in your webroot:

Your lolcathost(*) sees just another subfolder that's a site; the symbolic link sends you to the existing Drupal folder; and finally, the multisite system sees that you're browsing 'localhost/drupal-subsite' and selects the localhost.drupal-subsite folder as the one holding your site.

You can also have your subsite explicitly sit below the main site like this:

In which case your sites folder is localhost.drupal-multisite.drupal-subsite and the symlink should be inside the multisite folder:

So when I next get a moment I'll consolidate the various test sites I have, and when I have more than one patch on the go that I want to keep segregated, I can just add a multisite, get a fresh CVS copy of the code, and get going.

I've added details to the documentation too.

(*) yes, I keep typing it like that.

Okay, so I lied. But module builder can save you a lot of time when writing custom modules.

And it now works with drush, too. I added support for drush a few weeks ago, which let you do things like "$ drush mb mymodule cron init menu nodeapi --write" and hey presto, a new module folder is created, with an info file and a module file, with hook implementations ready to do your (evil) bidding. (Note: this blog does not sanction use of Drupal, module builder, or drush for evil.)

If you're super lazy you can even say "$ drush mb mymodule cron init menu nodeapi --go", using the wash 'n' go option which writes all the files and enables the new module for you. But don't do this if you're writing an install or enable hook, as they won't have any code in them!

The downside was that you needed to install module builder into each Drupal installation you wanted to generate modules for. Bit of a pain if you're developing a few sites and have a few more test sites kicking around.

But no more! You can now stick the module builder folder wherever drush can find it, and build modules in any Drupal 6 installation. You can download hook data to that installation with "$drush mbdl", or store it in a central location by specifying the --data option.

You might say at this point, core hooks are all very good, but what about hooks for CCK, Views, Ubercart, and so on? Well, like all good modules, module builder comes with a hook. Implement hook_module_builder_info, tell it where you hook documentation can be found on the interwebs, and add your module's distinctiveness to module builder's sugary goodness.

And how might you do this?

With module builder, of course!