Exporting more configuration with Drush CTools Export Bonus

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.

Comments

Submitted by dkingofpa on July 31, 2012 - 17:00

I'm very interested in hearing alternatives to Features. Could you elaborate more on your thoughts when you say, "There's is absolutely no intention or need to split this up in individual pieces for flexibility."

What about developers that want to re-use a piece of pre-configured functionality? For example, I've seen Features for a blog or wysiwyg. Those are common pieces of functionality that are mind-numbing to recreate for every new site. Re-usability appears to be a very important, but admittedly difficult, aspect of Features.

So from what I've read, it appears the biggest problem you're attempting to solve is moving a site's configuration between environments (dev, test, prod). What happens to this project when D8 is released? It sounds like the Configuration Management Initiative (CMI) is going to address this same problem.

Thanks for the blog post! It certainly prodded me to think a bit more about the different approaches to config management.

Submitted by swentel on July 31, 2012 - 17:22

When D8 is out, this project should stop completely, but that's at least one year from now, maybe even longer.

Regarding: 'There's is absolutely no intention or need to split this up in individual pieces for flexibility.'

That's our philosophy at work indeed, but that's maybe because the projects we work on are always so completely different that we simply can't reuse previous configurations/setups - especially at the content type level. I agree there is a use case though but it's a thin line.

Submitted by dixon_ on July 31, 2012 - 17:25

This sounds really interesting! I really like the idea of having fewer modules in the mix! I also like the idea of saving object directly to the database so export modules can be disabled. With Features there's a lot of code being included on every bootstrap (although Features does a good job trying to keep it to a minimum).

I'm definitely going to give this a ride! :)

Submitted by swentel on July 31, 2012 - 17:46

'although Features does a good job trying to keep it to a minimum'

Absolutely. I like the idea of having an empty .module file as well as features does by default, so I'm still experimenting with the idea of moving the ctools hooks as well or keeping some sort of cache so that you can actually add more custom code to this exported module.

There's already an option to ignore exported files anyway for the next export, so I need to find out the best route here.

Submitted by dixon_ on July 31, 2012 - 19:36

Yeah, I see file include/memory bloat to be a very important matter to address in an efficient way. But centralizing around CTools is definitely making it easier to optimize I believe.
Will be interesting to see what we can make out of this :)

Submitted by Giordy Salvi on January 13, 2013 - 20:42

I've just come across this and it looks like it could be very useful for managing configuration between test and production sites. Before this I was looking at patterns which seems to do similar things although it doesn't (yet?) seem as comprehensive. Can you comment on the differences between the two? I'd be very much obliged.

Oh, and I don't suppose there are any videos around helping with export bonus?

Thanks

You are here