Written on July 31, 2012 - 09:53

In a previous article", I talked about the possibilities that CTools now exposes through its new powerfull drush commands. With the addition of a new alter hook just before writing out the files to a module, the sky is now the limit when it comes to having configuration of a site in code.

Knapsack

Almost two weeks from now, I created a project called 'Drush CTools Export Bonus' which does 2 basic things: writing a lot of new configuration to files and tons of commands to rebuild this configuration on command line. It finally gave me a reason to use the nice logo which was made a few months ago by Leen Van Severen. It pictures a knapsack which was the codename for a project I worked on at the end of last year, but got hold up by various reasons. Parts of that code ended up as the initial drush export patch for CTools.

So what does it do ? Simple: export or rebuild, via drush, any configuration that isn't supported by CTools' exportables, currently including common objects like content types, fields and instances, variables and many more. Entity exportables are on its way as well. See the project page for a full list. In the end, you should get the state of your site configuration in one single module, controllable by various drush commands. Drush being our Swiss army knife, the module our knapsack. In the end, I chose for a more descriptive project name referencing to its master drush command.

The workflow is extremely easy:

1. drush dl drush_ctex_bonux into your .drush folder
2. drush @site_alias ctex module_name to create a new or overwrite an existing export module
3. drush @site_alias cbum module_name (first time) or drush @site_alias cbrm module_name when updating
4. Sit back and watch the messages on your screen

For more commands, just type drush --filter=ctools

But hey, this sounds like features!

You're right, both projects (and maybe others out there) try do the same thing: make configuration available in code, but there's a couple of reasons why I chose to go down this road instead of using the features module. In a non-prioritized by importance order, this is why I've been thinking and coding about this the last year (probably even longer, I can't even recall anymore):

1. Full control: Damian 'damiankloip' Lee and I are the main contributors with access to the CTools project regarding everything related with CTools' drush commands and bulk exporting. That gives us enough flexibility, also because the exportables in CTools just work™. By adding the alter mentioned above, new projects can easily be created and we don't pollute the main ctools project with configuration that it doesn't support out of the box. This new project is mine, but I'm open to any contributors out there, so ping me if you want access to make this rock beyond imagination.
2. Killing module overhead: with features, you at least need 2 modules enabled. The exported module and features itself. If you want variables, you need strongarm - although that can be disabled and there's other modules out there exposing more configuration on top of that really shouldn't be enabled on your production environment at all. CTools is now slowly becoming a de facto contrib that you install on your Drupal 7 environment - think views and many others out there - which makes the choice very easy. With this project, you only need one drush file and the ctools commands to handle the configuration, including variables.
3. It's CTools man! I admit, I'm a fan, and not only because of the exportables, which in my opinion everyone should simply implement as it will save you tons of code and maintenance nightmare. Do not try to write your own logic for code vs overridden vs database version of configuration. It's all there. And that's only the top of the iceberg of fine developer tools inside that project.
4. It's about the state of your site. In its essence, you can export a complete site with both projects to one single module, commit that and update various environments. This is probably the workflow many developers have adopted using features, but there's also the tendency to split up use cases in various pieces. The philosophy of this project is simple: one site, one configuration. There's is absolutely no intention or need to split this up in individual pieces for flexibility. While it's possible, just don't do it, you don't need it.
5. Dependency on modules: as already mentioned, you need features enabled to run its exported modules. Another key difference in this project is how we handle content types by not implementing hook_node_info(), but simply exporting the content type info to a separate file and a call to node_type_save() when updating. We're still implementing hook_image_default_styles, but that will soon disappear as we'll be adding an option to save every exportable, even ctools', to the database, so you can disable an exported module generated by this project.

Meet us at DrupalCon Munich

We're holding a bof session, currently scheduled on thursday, about all these fine goodies. We'll give you demo on how these commands work, answer your questions and talk about the future.

Will this solve all my problems ?

Maybe. Maybe not. There's no guarantee this approach is better than others, but there's one thing I do now though: typing drush @site_alias cbum module_name on a minimal Drupal install and then looking at the screen is one of the finer things I've seen in months which I wrote myself - but that's not a guarantee either. However, it's getting close to a point I've been dreaming for at least two years, having full control of a D7 configuration in code without any issues - so far. Anyone interested, please test and help along. And be very descriptive in case you post issues.