Latest sites

Quick news

  • 2014-03-27: MongoDB Watchdog module ported to Drupal 8 at the Szeged Dev Days.
  • 2014-01-26: My post on the Symfony web profiler in Silex selected in Week of Symfony. w00t !
  • 2013-10-18: My first commit went into MongoDB today. And, guess what ? It's in JavaScript
  • 2013-09-20 to 29: Working on Drupal 8 EntityAPI at the extended code sprints during and around DrupalCon Prague
  • 2012-08-19: Working on Drupal 8 EntityAPI at Drupalcon Munich
  • 2012-06-15: Working on Drupal 8 EntityAPI at DrupalDevDays Barcelona
  • 2012-03-23: Working on the future Drupal Document Oriented Storage at DrupalCon Denver. D8 or later ? Bets are on Later

When Drush Make fails to apply patches...

The issue

These last few days, I had noticed a problem with Drush Make and patches: some patches, be they rolled by our team or from elsewhere, would apply without a glitch, but some others, which worked normally according to the test bot on, would fail to apply without any obvious reason.

I had mostly put it out of my list of pressing issues when I really had to use an old version of OpenLayers, 7.x-2.0-alpha2 to be specific, AND apply a patch fixing one of the bugs in that module: behaviors plugin not being located correctly ( if you want details). So I rolled the patch, tested it locally, the qa.d.o bot applied it and did not report more errors than expected for that old version.... and my Drush Make install refused to apply it.

Here was the relevant excerpt:

projects[domain] = 3.7
projects[domain][patch][] = ""
; ...snip...
projects[openlayers] = 2.0-alpha2
projects[openlayers][patch][] = ""
The Domain patch applied normally, but the OpenLayers patch would't apply. What could be wrong ?

The diagnostic

After tracing my way into DrushMakeProject::applyPatches(), I got a more explicit message: neither git patch nor trusted old patch could locate the patched file, includes/ Why ?

Comparing a standalone checkout of OpenLayers 7.x-2.0-alpha2 and the one in /tmp/make_tmp_(some id)__build__/sites/all/modules/contrib/openlayers, the problem became more obvious: that file was missing, as well as a good number of others. What ? Download failure ?

Not in the least: checking, I noticed the version downloaded by OpenLayers was no longer the chosen 7.x-2.0-alpha2 specified in the Makefile and which it previously downloaded normally, but the currently latest 7.x-2.0-beta3. Ahah...

The fix

After digging a bit more into Drush, it appeared that whenever you specify an extra info bit about a project download, lines in the short format like projects[openlayers] = 2.0-alpha2 are ignored, so Drush downloads the latest published version. The fix became obvious: use the "extended syntax", like this, for the same excerpt:

projects[domain][type] = module
projects[domain][version] = 3.7
projects[domain][patch][] = ""
; ... snip ...
projects[openlayers][type] = module
projects[openlayers][version] = 2.0-alpha2
projects[openlayers][patch][] = ""

This also explained why the other patches applied normally: each of them had been rolled against the latest module version, so the specified version was ignored, but the version actually being downloaded ended up being the same, and the patch applied normally.

Drush issue queue

Thank you for the write-up. I posted a bug report in the Drush issue queue for this:

Well, bug or feature ?

Thanks for posting the issue. I hesitated, but felt it was too minor to justify bumping the Drush queue.

Bug or feature remains to be seen

Whatever it is, I think that the situation that you ran into is kind of subtle, and not necessarily easy to track down. Since make files are stored in Drupal .info file format, the argument could be made that it is correct behavior for the project's "array" elements to overwrite the "string" (version) item. I posted a patch that took the first step towards merging these items together; we'll have to see what the other maintainers think of it. In any event, this is definitely a valuable writeup, and should at a minimum be a documentation task in the queue. Thanks for your work on this.

Massive timesaver

I think you've saved me, any many others, a lot of debugging time by posting this tip.

I was having trouble with this too.


Maybe, whilst annoying, it would be better to always use the long form in drush make forms, to ensure that there is no ambiguity?

Long form when needed

What I tend to do, actually, is:

  • use the short form for completely default cases
  • use the complete form whenever something needs to be specified

That's not needed, but my subjective opinion is that it is simpler to parse visually than a sea of complete (long !) stances or, even worse, a mix of stances in various degrees of completion, each of which needs to be verified individually.

Thank you!

Thank you!

I found another case

I found another case where the patch doesn't get applied.
When you are patching the info file and you are downloading the stable version adds lines at the end that may mess with your patch.