Een hart voor de Drupal Community

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

We're getting issues with the system_status module, when setting up this project for the Belgian website.

PHP message: Drupal\Core\Extension\MissingDependencyException: Unable to install modules: module 'system_status' is incompatible with this version of Drupal core. in /var/www/html/docroot/core/lib/Drupal/Core/Extension/ModuleInstaller.php on line 123 #0 /var/www/html/docroot/core/lib/Drupal/Core/ProxyClass/Extension/ModuleInstaller.php(83): Drupal\Core\Extension\ModuleInstaller->install(Array, false)

This looks like a module that relies on a 3rd party SaaS service, which we do not need. It also does not have a stable release, so we would like to get rid of it, since it provides no added value to our instance.

Proposed resolution

- Remove dependency on system_status module

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Thank you for your fix, Anmol. It's been committed and released.

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Upon installation of this module on Drupal 10, I get the following error:

PHP Fatal error:  Declaration of Drupal\request_logger\Logger\RequestLogger::log($level, $message, array $context = []) must be compatible with Drupal\dblog\Logger\DbLog::log($level, Stringable|string $message, array $context = []): void in /app/web/modules/contrib/request_logger/src/Logger/RequestLogger.php on line 42

Steps to reproduce

* Install module on a Drupal 10 installation.

Proposed resolution

* Implement changes as documented in [#3284415]

Remaining tasks

* Implement changes as documented in [#3284415]

Add support for Drupal Gitlab CI.

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Our customer is testing this module and noticed error messages like these: Smartling\Exceptions\SmartlingApiException: Async operation is not completed after 16 seconds.

Our investigation led us to the ContextUploader, the uploadAndMatchContext method in specific. What could be causing these time-outs? Is there any way to prevent them aside from increasing the default time-out of 15 seconds?

bceyssens created an issue.

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Fix warnings as reported by PHPCS.

The fix looks good at first glance, but please leave issues in needs review until the maintainer has actually committed the changes. I'll try to do this ASAP.

    // Allow other modules to alter the Mandrill message.
    $sendgrid_params = [
      'message' => $sendgrid_message,
    ];
    \Drupal::moduleHandler()
      ->alter('sendgrid_integration', $sendgrid_params, $message);

    // Lets try and send the message and catch the error.
    try {
      $response = $client->send($sendgrid_message);
    }
    catch (SendgridException $e) {

The $sendgrid_message Mail object can be complemented but can never be replaced completely. We need replacement replacement capability because the object won't let us change/replace already set properties.

Changing $response = $client->send($sendgrid_message); to $response = $client->send($sendgrid_params['message']); solves this issue.

bceyssens created an issue. See original summary.

The consent mode issue was fixed in 2.0.5, so the latest patch stopped working. Original patch by @emanaton works fine.

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Fix CSPELL errors as reported in Gitlab pipeline.

Problem/Motivation

Currently in code, only image styles from the 'default' view mode are discovered:

$plugin = $this->entityTypeManager
  ->getStorage('entity_view_display')
  ->load($entity->getEntityTypeId() . '.' . $entity->bundle() . '.default')
  ->getRenderer($this->fieldDefinition->getName());

Proposed resolution

Discover image styles across all available view modes.

Remaining tasks

I'll create a merge request, please review.

RandalV created an issue. See original summary.

The module does not seem to use the hook_schema, but instead define the schema within hook_install. It would be best to convert this to a hook_schema to comply with Drupal best practices, and to allow Drupal to always have the most up to date schema definition via hook_schema.

Problem/Motivation

Upon installation, I'm getting the following error:

In Schema.php line 701:
The 'user_session_id' field specification does not define 'not null' as TRUE.

Still on Drupal 9.5.11 + MySQL version 5.7 + PHP 8.1, for what it's worth.

Steps to reproduce

Install scorm_field module.

Proposed resolution

Check if https://www.drupal.org/project/drupal/issues/2841291 is related.

Setting "user_session_id" property to 'not null' => TRUE, in scorm_field_install fixes it for me locally. Not sure if that's desired behaviour.

Remaining tasks

Investigate if changing 'not null' from FALSE to TRUE is ok or not, or find another solution.