So DrupalCon Europe is out for 2018. But that does not mean a EU-level event does not exist, to bind the community beyond the specialization of DevDays, FrontEnd United, CxO, GovDays, and all the DrupalCamps. Drupal Europe is that event, and to support the community who wants to prove a large Drupal conference can reasonably happen after all the trouble the Drupal Association had with it, the best way it to register for the conference.

ASAP.

So join me there :-)

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:

<?php$blog = require_once __DIR__ . '/controllers-blog.php';// This will handle /blogs/ and below, but not /blogs$app->mount('/blogs', $blog);// So we have to use a non-mounted route from a sub-request to avoid a redirect().$app->get('/blogs', function () use($app) {   // forward to /blogs/   $subRequest = Request::create('/blogs/' , 'GET');   return $app->handle($subRequest , HttpKernelInterface::SUB_REQUEST);}?>

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 ?

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: