On November 8 2023, I updated a couple of modules that I maintain. No significant changes, just some bug fixes and improvements.
The biggest change is that I’ve switched to GitlabCI for continuous integration. Now, all the modules are tested with phpcs, PHPStan, Stylelint, Eslint, and PHPUnit.
The integration with the new CI system provided by the Drupal Association is pretty simple to use; just follow the documentation: https://www.drupal.org/node/3356364.
I’ve made some changes to the standard template to be sure that the pipelines fail in case of errors (take a look at the
.gitlab-ci.yml file in the WebProfiler module: https://git.drupalcode.org/project/webprofiler/-/blob/10.1.x/.gitlab-ci.yml).
The provided template looks for configuration files for phpcs and PHPStan, and you can see how I’ve configured them here: https://git.drupalcode.org/project/webprofiler/-/blob/10.1.x/phpstan.neon and here: https://git.drupalcode.org/project/webprofiler/-/blob/10.1.x/phpcs.xml.dist.
PHPStan is set to level 5, not the maximum level, but it’s a good start. I’ve also added a set of rules to the phpcs configuration file that comes from the
Now, let’s see what’s new in the modules.
In the new Drupal 10.1, the Database API can trigger events on the execution of statements. Previously, the module was using the logging capabilities of the Database API to collect the queries, and now it uses the new events. This new system can be used to analyze better the database layer of Drupal.
The routing data collector now shows more information about the page title and the controller that will be used to render the page.
A couple of bug fixes have been made to the module behind the WebProfiler module.
At the moment, Tracer is not actively used by any other module, but its future is bright. I’m planning to start working again on the Observability suite module (https://www.drupal.org/project/o11y), and Tracer is the tool that will be used to collect the data.
Again, there are no big changes here, but a simple new feature that can improve the analysis of the logs produced by Drupal.
Due to some internal implementation, the batch operations invoked by Drush don’t work if the line formatter set in Monolog produces a JSON string.
Having the logs in JSON format is useful to analyze them with tools provided by all the major cloud providers. Until now, if you have to run some Drush commands that internally use batch operations, you have to switch to the
drush formatter. The latest version of the Monolog module adds a new conditional formatter that can be used to choose which formatter to use based on some condition. For example, if you want to use the JSON formatter for all the logs except for the ones produced by Drush, you can use the following configuration:
monolog.formatter.drush_or_json: class: Drupal\monolog\Logger\Formatter\ConditionalFormatter arguments: ['@monolog.formatter.drush', '@monolog.formatter.json', '@monolog.condition_resolver.cli'] shared: false
The first two arguments are the formatters to use, and the third argument is the condition resolver. The condition resolver is a service that can be used to check if a condition is true or false. In this case, we are using the
cli condition resolver, which checks if the current request is a request that comes from the command line.
You can define any condition resolver you want. Just implement the
drush_or_json is already provided by the module, you can use it directly (for example in a
parameters: monolog.level.info: info monolog.channel_handlers: default: handlers: - name: 'website' formatter: 'drush_or_json' services: monolog.handler.website: class: Monolog\Handler\StreamHandler arguments: ['php://stdout', '%monolog.level.info%']
See the Monolog module readme file for more information: https://git.drupalcode.org/project/monolog/blob/HEAD/README.md
In the next month, I’ll concentrate on some other interesting things, like improving the Symfony Messenger module (https://www.drupal.org/project/symfony_messenger), and add profiling support to Drush.