Why decoupling Drupal

Amongst other things, I hear this quite a lot on my conversations around the subject, why decoupling Drupal, is not like you are giving away what Drupal is and overkilling with something you could do with other tools? What's the point?

Well, in this keynote talk on Design4Drupal Dries mentions something interesting. Everyone things on Mongodb or any other cool technology in order to build your api... but what about the backend, the administration of that api? Who is going to input and maintain the content there? Will you have to build something from scratch?

Well, this is where Drupal decoupled comes into action. Why not having something that is API first ready and designed specifically to manage content?



Executing memcached in Travis

So, I heard you need Drupal and memcached running in Travis, right? But you have this "little" issue that Travis/Drupal cannot connect to memcached, something like:

WD memcache: You must enable the PHP memcache (recommended) or [error] memcached extension to use memcache.inc. 
WD memcache: Failed to connect to memcache server: [error]

Before you jump into docs and tutorials on how to install memcached in Travis, probably it's already there, you just have to enable.

Simply add a new php.ini file somewhere in your source, for example in travis_scripts/php.ini:

extension = "memcached.so"

and point that from your Travis, for example from your before_install section:

phpenv config-add travis_scripts/php.ini

Or even better, from your setup_environment.sh or equivalent

Your error should have gone now.

Parse error: syntax error, unexpected ':', expecting ';' or '{' in vendor/doctrine/annotations/lib/Doctrine/Common/Annotations/AnnotationRegistry.php on line 50

Easy error to fix, once you know what's going on (is not always the case?).

Just upgrade your system from php 5 to php7. Drupal8 requirement.

In BLT, just edit your box/config.yml and change this line

php_version: "5.6"

to this:

php_version: "7.2"

Good old vagrant provision should do the rest of the trick. You are welcome :-)


Ansistrano, deploying Drupal with Ansible

Last months have been pretty busy here at BBC Worldwide with some of the projects we've been involved in.

In my case, one of the main areas I’ve been trying to improve (apart of the daily busy routine) is our devops / CI approach. The previous approach was using Chef, but it was not really adopted by the developers (which meant that after some months, the system was broken) and we were lacking some fundamental things (like integration with the production system, a real CI flow, etc…).

On the other hand, my previous experience with puppet was that the system grew too much to be easily maintained, specially if you don’t have a big dedicated devops team. To sum up, during last months research I was pretty amazed with Ansible, it's amazingly simple, very flexible and a truly joy to maintain. So, to me, the way forward was Ansible.

So, we started rewriting some of the old broken features in Chef and, sooner than later, we found ourselves reinventing the wheel. Some features were custom things, like triggering "drush cc all”, executing grunt, phpcs, etc... but obviously lots others were not… well, we are not the first team in needing an apache and mysql database, are we?

And deployment is one of these things that I was not too keen to reinvent. It would be pretty simple with Ansible, to be honest, but why not use something that is already tested, works well and at the same time give some love back to the community? Enter Ansistrano.

Ansistrano is a deployment tool based in Ansible. The relation with Capistrano ends just here, with the name similarity (no code base was harmed during the process). For more information about Ansistrano please visit the official repository: https://github.com/ansistrano/deploy

- Step 0. Install ansistrano (deploy and you’ll probably be interested in the rollback too):

ansible-galaxy install carlosbuenosvinos.ansistrano-deploy carlosbuenosvinos.ansistrano-rollback

- Step 0. Clone the deploy repo in the folder you’ll be using the app. Let’s say we’ll be working in ~/my-app-build :

git clone https://github.com/ansistrano/deploy.git ansistrano-deploy

Notice that we are cloning the deploy repository.

We’ll be using the latest stable release, list tags:

[email protected]:~/my-app-build$ git tag

at the moment, the latest stable release is 1.4.1, so:

git checkout 1.4.1

Step 1. Now, the ‘tricky part’. We are going to write a file where we’ll execute all the magic. Let’s call it build-my-app.yml:

- name: Deploy example app to local.myapp.com
  hosts: all
    ansistrano_deploy_to: "/var/www/myapp.local"
    ansistrano_keep_releases: 3
    ansistrano_deploy_via: "git"
    ## GIT pull strategy
    ansistrano_git_repo: [email protected]:myapp-in-git.git
    ansistrano_git_branch: develop
    ansistrano_git_identity_key_path: ""

    - { role: ansistrano-deploy }

Notice that the role we have at the end is just the deploy repository cloned from Ansistrano (https://github.com/ansistrano/deploy). You can change the name, as I've done in this example (ansistrano-deploy) but you'll have to upgrade the roles variable in your yml (again, as shown in this example).  

Step 2. Run deploy:

ansible-playbook -i "localhost," -c local build-my-app.yml -vvv

Instead of specifying localhost you could also use a hosts file, as recommended in the official documentation. This is also going to give you the freedom of deploying your app not just in your local environment, but potentially in any remote server, i.e. aws, digital ocean, etc...

Step 3 (optional). From here, the limit is the sky. In our case, we have some complex deployments running grunt, drush, clearing cache… The advantage here is that ansible is pretty flexible, so you could for example add your own tasks in your deploy file (build-my-app.yml), i.e.:

  - include: goodfood/tasks/apt.yml

The right, official way of doing this is using the hooks that ansistrano itself offers you:

  # Hooks: custom tasks if you need them
  ansistrano_before_setup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-setup-tasks.yml"
  ansistrano_after_setup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-setup-tasks.yml"
  ansistrano_before_update_code_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-update-code-tasks.yml"
  ansistrano_after_update_code_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-update-code-tasks.yml"
  ansistrano_before_symlink_shared_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-symlink-shared-tasks.yml"
  ansistrano_after_symlink_shared_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-symlink-shared-tasks.yml"
  ansistrano_before_symlink_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-symlink-tasks.yml"
  ansistrano_after_symlink_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-symlink-tasks.yml"
  ansistrano_before_cleanup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-cleanup-tasks.yml"
  ansistrano_after_cleanup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-cleanup-tasks.yml"

where playbook_dir is the folder where your yml file lives.

That's it. Simple, elegant, and really powerful, I love it :-). Next episode, we'll talk about the rollback artifact.

Notes: Amended Step 0, as you don't need to install the playbook through the ansible galaxy, just cloning would do. Thank you Carlos Buenosvinos.

Profiling PHP and Drupal with XDebug (In OSX)

Problems with a rogue app you built (maybe not you)?

Just some links which I found useful in order to debug/profiling your app:

Run it in you Mac with OSX:

Sometimes you need your profiler to be executed everytime. You can do that with this:


This is my whole xdebug.ini:

; Enable xdebug extension module











Other general links:


Using Symfony Dependency Injection in Drupal 7: Software Engineering in Drupal

I still remember in a previous job discussing with a partner about doing things the proper way, using coding standards, commenting what you are doing, ... giving your code some love in definitive.

I'm still amazed of his answer, basically he was refusing to doing things the right way (the only way) because using his way he was a lot quicker... Well, probably, but on the meantime modifying some of the crap we had there (not just him, I have to say) could take us like 4 to 10 times more time.

That's basically because you needed to understand what was going on that code... and I promise you, when you have a single function of around 3000 lines, no comments, things happening without too much logic, no standards, dozens of lines commented... that is not easy at all, even for the owners of that code. That's why you use Coding Standards, code reviews, Pull Requests and all that stuff in serious environments of Software Engineering.

Anyway, developing using the Object Oriented paradigm is quite a lot more organized than doing it using simply .modules and .inc files in Drupal. It does not matter how organized you are, at the end you'll end with lots of files and functions in a nightmare to understand for third developers. And, when you are working in Enterprise environments, with lots of people sharing and creating code, things like coding standards and doing things the proper way becomes a very serious thing.

Solution? As I said, using Object Oriented programming paradigm. In Drupal is easy enough since Drupal 7 allows you to add directly classes included in .php, .inc/* files. Simply do:

files[] = lib/MyClass.php

Well, that's easy enough... but there is a better more sophisticated way of doint it: Symfony Dependency Injection.

There are some good advantages of doing this that way. First and maybe most important, you are starting to be ready for Drupal 8. Second one, you objects can use Lazy loading. That's a great thing, basically means that your objects will be using the Proxy Pattern, which allows your code to load things only when they are going to be needed.

That's a good trick to improve your Drupal site performance from your own code (a big big percentage of performance problems are derivated from bad coding practices).

Want more advantages? Did I say that you make your code ready to Drupal 8? Well, that's just the begining. Starting to use Symfony components like Drupal Symfony inject open us a world of thousands of bundles ready to use from Symfony, and just using them through Composer. Win win :-).

We will need basically two modules, Drupal Symfony inject which a college is developing here, in Capgemini, and Composer Manager as it is a dependancy:

It is important you install them using drush, so the vendors folder will be created for you (with all the dependencies that the module has):

drush pm-enable drupal_symfony_inject --y

Once installed, DSI makes you available three new hooks:

  • _namespace_register()
  • _symfony_yaml_config()
  • _symfony_yaml_config_params()

The first one, _namespace_register, allows you to register your new classes like that:

Now we will need to add the config.yaml, where we will declare the classes we will be using, parameters, etc...

Now you need to define your classes in the yaml file. Create the file in config/yaml/config.yaml and declare there the classes you'll be using:

And finally, the parameters:

That's it, Drupal is ready to use the Symfony Dependency Injection component. Lets move to create a new class, for example, CruiseHunter:

That's one of the Abstract classes I use in CruiseHunter from which I inherit to fetch the different contents the Cruise crawler uses. It is a lot more organized, it declares a common mechanism to fetch information from the crawler, etc...

Well, now that we have the class, we need to be able to import it and use it. And here is where the Dependency Injection appears:

Once you have all in place, you have to rebuild the symfony components you have just built:

drush rsc

If you see some error, you made a mistake, probably in your yaml. If you see something like this:

Symfony DI container compiled and cached successfully !!!

Congratulations, you are ready to use your new Symfony components :-).

Related articles:

Changing Short project name in a Drupal.org project

Typical problem, you have just gained your full project permissions role in Drupal.org, and you make your first mess... you have promoted your so loved first project without changing the Short project name.

Well, you have a problem, but not too big. Drupal.org will not allow you to rename your Short project name, so you will have to create a new one if you don't want to have an ugly url like that: https://drupal.org/project/2062343

Fortunately git can help. You will simply have to:

  • Create a new project, sandbox or not,
  • Go to the "Version control tab" and get the url of your new git project, something like: [email protected]:project/2062343.git
  • Go to the folder of your old sandbox, the project in which you cannot change the Short name, and change the remote for this folder. For my url example, the command will be: git remote set-url origin [email protected]:project/2062343.git
  • Nearly finished. You probably have to merge, as you will have to make your first commit in the new project: git pull
  • And finally, git push origin master will get the job done.
  • Remember to create a new branch, like 6.x-1.x and commit to that one to create a new official, downlodable release of your module. Congratulations :-).


Next time, take it easy cowboy ;-).


More information:


Drupal form api select elements returning integers instead of string

I always have the same problem when using select forms, and I always forget the solution.

Instead of returning an array, like: return $competitions; you have to return a drupal_map_assoc, like this: return drupal_map_assoc($competitions);

Otherwise, when selecting the form in hook_submit you will get a number, instead of a human readable string.


Customize a webform with


Convert dates from UNIXTIME in mysql

Reading a date in mysql can be frustrating, unless your brain is able to convert Dates from UNIXTIME formats. Let's see for example this scenario in Drupal:

SELECT * FROM `node` ORDER BY `node`.`created` DESC LIMIT 0 , 30

If you need to fetch, for example, when it was the last time that a node was created, this format doesn't help too much.

The solution is quite simple, FROM_UNIXTIME( field_with_date )

For example:

SELECT * , FROM_UNIXTIME( created ) FROM `node` ORDER BY `node`.`created` DESC LIMIT 0 , 30