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.


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.

Overriding the Facet API breadcrumbs

Facet API for Drupal is an amazing module that enables you to easily create and manage faceted search interfaces. The UI is fantastic and easy and it works perfectly together with either Search API or Apache Solr. It also changes the breadcrumb as soon as you start filtering further, which in many (probably most) occasions, is a nice default behavior. But not every project wants these kind of breadcrumbs. In a project we tried first to override the breadcrumb with hook_breadcrumb_alter(), but as we have a lot of search pages, the code was getting ridiculously ugly.

So we looked at where exactly Facet API is changing the breadcrumbs. This happens in a method called setBreadcrumb in a url processor class. So, we need to create our own processor and override the default behavior. First of all, we need to let Facet API know we have our own url processor:

* Implements hook_facetapi_url_processors().
function yourmodule_facetapi_url_processors() {
  return array(
'standard' => array(
'handler' => array(
'label' => t('Your module URL processor'),
'class' => 'FacetApiYourClass',

We are doing something wrong here: the standard key is also used in facetapi_facetapi_url_processors(), so we should use another name, because we are now overriding the default class. The trick is to extend on that class so the other methods will still do the heavy lifting. Oh module_invoke_all, we sometimes love your merge behavior (although technically here it's a CTools plugin, but the result is the same for both).

class FacetApiYourClass extends FacetapiUrlProcessorStandard {
  public function
setBreadcrumb() {
// Keep default behavior.

If this class is not defined in your .module, make sure you add it to the .info file so the registry picks it up.

That's it. Again, this post should probably also be tagged with 'You're doing it wrong', but it works perfectly for our current use case.

Exporting, reverting, disabling and enabling any exportable with ctools and drush

With the newest release of ctools, a new command was made available for drush to export all objects to code with one simple command to a module. Instead of having to copy and paste all code via the bulk export module to your custom module, a simple drush command now saves you a lot of time. But it doesn't stop there. Damian 'damiankloip' Lee started a sandbox to add more powerful funtionality and this has now been merged in the 7.x branch which will be available in the (soon) next release of ctools. An initial patch to select the exportables by hand has also been committed, but could need some more love on the UX side. Apart from that, the goodies that are in already, should make any developer extremely happy and opens up new possibilities in so many ways. So what commands can you use now and what do they do ?

  • drush ctools-export-disable: disable one or more exportables
  • drush ctools-export-enable: enable one or more exportables
  • drush ctools-export-revert: revert one or more exportables
  • drush ctools-export-info: get an overview of all possible exportables
  • drush ctools-export-view: view one or more exportables
  • drush ctools-export: export all exportables to a module

Excited yet ? We are, so we made a screencast, we're pretty sure you'll love it. Damian and I are planning more things for the future, so anyone who wants to help can post issues to the sandbox. Once they're done, we can commit these easily now Damian has access. Let's make ctools drush extremely powerful!


drupal, ctools, export, planet

Installing XHProf on a Mac with Homebrew

Update 12/3/2013: the absolute easiest way is simply https://github.com/cam8001/php-xhprof-mamp

There are several ways to install XHProf on your mac in a MAMP environment. After a lot fails, the easiest way in my opinion is using Homebrew. The rest of the article assumes you already have this installed, so let's get to the XHProf install.

  1. Download the XHProf Homebrew Formula from https://github.com/msonnabaum/homebrew/blob/92f3795d2dcd5e74fb6f47a30b4f... and copy this file to /usr/local/Library/Formula/
  2. Fire 'brew install autoconf' to make sure autoconf is installed.
  3. Fire 'brew install xhprof' on the command line. You might get an error downloading the pcre package (depending on your homebrew version):
    Error: Failure while executing: /usr/bin/curl -f#LA Homebrew\ 0.8\ (Ruby\ 1.8.7-249;\ Mac\ OS\ X\ 10.7.3) ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.12.tar.bz2 -o /Users/swentel/Library/Caches/Homebrew/pcre-8.12.tar.bz2
    In that case, go to https://github.com/mxcl/homebrew/blob/master/Library/Formula/pcre.rb and download that file into /usr/local/Library/Formula/ and run the command again from shell.
  4. The extension is now built and can be copied to your MAMP installation:
    cp /usr/local/Cellar/xhprof/0.9.2/xhprof.so /Applications/MAMP/bin/php/php5.3.6/lib/php/extensions/no-debug-non-zts-20090626/ 
  5. Go to your php.ini file in your MAMP installation and paste following code and restart MAMP.
    ;This is the directory that XHProf stores it's profile runs in.
That's it. Should take you about 5 minutes. Took me a couple of wasted hours, but it's worth doing. And now you can finally toggle the XHProf option on the devel settings page in case you're working with Drupal.

Other resources about installing XHprof:


php, mamp, xhprof, planet

Mobile restaurant app for EVA on Android

I'm proud to announce the first mobile application for EVA. Late december, I offered to develop an app allowing you to search for restaurants in your neighbourhood, or anywhere in Belgium, serving vegetarian food. After two months of learning and developing, the first version is available on Google Play (aka the Android Market in earlier times) and iTunes. The app is now taken offline.

Besides the java part for the application, I also needed to dive into Joomla, writing my first ever component adding extra administration features in the backend and new dynamic pages on the public website. The look and feel was designed by Koffie Verkeerd. I'm pretty excited with this first release and new features are already planned, so stay tuned. In the meantime, I'm starting (well, rather, learning first) to port the app to iOS, so in case somebody wants to help out, do contact me or EVA so we can make that happen much faster.

The mobile app itself connects with an online database which is managed by the EVA crew, so you are always sure the data is up to date. But that's not all. Features in this first release:

  • Geolocation through Wifi/edge/3G
  • Lot's of criteria to search on: postal code, veggie, etc ..
  • Upload pictures, share or add reviews per restaurant
  • View a google map and ask directions
  • Call directly, send a mail or surf the website
  • Lots of details per restaurant
  • Send in new suggestions

There's a clear social aspect to the site, because all pictures and reviews are also visible on the website. Besides the overview, every restaurant now has its individual page as well, showing all user generated content - if available. Checkout the Komkommertijd page, incidently, my favorite veggie restaurant.

Last, but not least, thanks to Tobias for letting me develop this, Vincent and Pascal for the java reviews and all the first beta testers, your input was invaluable!


Subscribe to realize.be RSS