The problem: XDebug doesn't work for Composer scripts

PhpStorm is quite convenient to debug scripts with XDebug (do you support Derick for giving us XDebug ?): just add a "Run/Debug configuration", choosing the "PHP Script" type, give a few parameters, and you can start debugging your PHP CLI scripts, using breakpoints, evaluations, etc.

Wonderful. So now, let's define such a configuration to debug a Composer script, say a Behat configuration generator from site settings for some current Drupal 8 project. Apply the configuration, run it in debug mode, and ....

...PhpStorm doesn't stop, the script runs and ends, and all breakpoints were ignored. How to actually use breakpoints in the IDE ?

In most cases, call_user_func() and call_user_func_array() are just slower but more flexible ways to call functions or methods. But it turns out they are not entirely equivalent where methods are involved. Consider this fragment, and guess the output.

The problem: routing /blogs, not just /blogs/ in Silex

Route mounting in the Silex PHP framework allows conveniently grouping controllers per feature in separate files, then using mounting them on some prefix path like $app->mount('/blogs'). This will prepend the prefix "/blogs" to the paths defined in the the feature controller, effectively delegating to it all the /blogs/* routes. However, as the Silex documentation claims:

When mounting a route collection under /blog, it is not possible to define a route for the /blog URL. The shortest possible URL is /blog/.

This means handling the route mount point has to be done by a route outside the mounted feature, which makes it slightly less clean, as you have to do something like:

But is there really no workaround for this limitation ? Sure there is!

The problem: packages.drupal.org broken

I was starting my weekly work for the Drupal GraphQL module by the customary composer update --prefer-source -vvv command, ready to watch composer spit out some hundred lines sipping my coffee, but this time something turned out to be wrong:

  [...snip...]
Downloading https://packages.drupal.org/8/drupal/provider-2016-4%24a30289dd8394e5271bd77777bb14b361c5938656f1cddad7fae1c00d5d6ba9c6.json

  [Composer\Downloader\TransportException]
  The "https://packages.drupal.org/8/drupal/provider-2016-4%24a30289dd8394e5271bd77777bb14b361c5938656f1cddad7fae1c00d5d6ba9c6.json" file could not be downloaded (HTTP/1.1 404 Not Found)
  [...snip...]

OK, so packages.drupal.org is down for now. How can we work around this ?

OK, so you know the contents has almost nothing to do with the pseudo-clickbait-y title, right ? Well, actually it has: this is about the single most useful command in Drupal development. Guess which ?

While exporting a project from Unfuddle in order to import its issues to Jira, I took a look at the other files beyond backup.xml and the media/ directory. Turns out that when Unfuddle provides you with a project backup, it includes the repositories in an undocumented (on their site, at least) format, under the dmp file extension. Let's find out how to actually use these.

The mystery

There are a number of issues on StackOverflow and elsewhere about the problems met when upgrading to PHP 7, so when I upgraded a Debian Wheezy server this week, I only upgraded to Jessie with its standard 5.6 version, not expecting problems. But of course, there had to be this mystifying error which seems to be most often associated with PHP 7.0 : like Debian bug 709302:

[Wed May 22 14:20:26 2013] [error] [client 127.0.0.1] PHP Fatal error: require_once(): Failed opening required './libraries/php-gettext/gettext.inc' (include_path='.') in /usr/share/phpmyadmin/libraries/select_lang.lib.php on line 389
[Wed May 22 14:20:26 2013] [error] [client 127.0.0.1] PHP Fatal error: /require_once(): Failed opening required /'./libraries/php-gettext/gettext.inc' (include_path='.') in //usr/share/phpmyadmin/libraries/select_lang.lib.php on line 389
[Wed May 22 14:20:26 2013] [error] [client 127.0.0.1] PHP Fatal error: require_once(): Failed opening required './libraries/php-gettext/gettext.inc' (include_path='.') in /usr/share/phpmyadmin/libraries/select_lang.lib.php on line 389

So how do we fix this for 5.6 ?

When you use Drush, especially in crontabs, you may sometimes be bitten by RAM or duration limits. Of course, running Drush with the "-d" option will provide this information, but it will only do so at the end of an annoyingly noisy output debugging the whole command run.

On the other hand, just running the Drush command within a time command won't provide fine memory reporting. Luckily Drush implements hooks to make acquiring this information easily, so here is a small gist you can use as a standalone Drush plugin or add to a module of your own:

On behalf of all contributors to the MongoDB module suite for Drupal over the years, I am pleased to announce the 8.x-2.0-alpha1 release of the MongoDB package for Drupal 8, six years after we started this project on Drupal 6.

This release is the first step to an initial stable release of the MongoDB package for Drupal 8, containing:

• mongodb a module exposing the new PHP library as Symfony services exposed to a Drupal 8.x instance. It is designed as a minimal and consistent connection layer on top of the PHP library for MongoDB, for all modules targeting MongoDB on Drupal 8.x, be they contributed or bespoke.
• mongodb_watchdog a PSR-3 logger storing event data in MongoDB. On top of the features already present in 6.x and 7.x versions, it introduces a per-request report showing all events logged during a request, in order.