Een hart voor de Drupal Community

Rerolled #41 against 10.3.x

Hi @google01,

Merge request definitely applies to 10.3.x.

The contents of this: https://git.drupalcode.org/project/drupal/-/merge_requests/5373.diff Should be downloaded and placed in a local folder (e.g. YOUR_PROJECT/patches/core/3091336.patch), make sure there's an empty line at the end, and then add `patches/core/3091336.patch` in your composer patches list.

Code below was missing in the new submit method:

// Force a rebuild of the form.             
$form_state->setRebuild();                  
$form_state->set('tmgmt_suggestions', NULL);

New patch and interdiff attached.

Could a maintainer please take a look at this issue? It doesn't change the module's initial installation state, and it adds a lot of possible functionality.

I think this could really spearhead this module's already superb usefulness. (And I'd also be sad to see the work I put in it be for naught :))

Is there any progress on this, or any way to circumvent this and move forward? Recipes are included in 10.3.x, I feel like the priority of solving this should be a little higher now.

I can't seem to get it fixed myself, other than patching core and removing the functionality entirely, but that seems a little nuclear...

On the other hand, I personally do think that this copy functionality should be removed. It definitely doesn't make much sense to copy blocks from one theme to another, given that regions could be entirely different.

Thank you for your patch, alecsmrekar, it seems to work.

I am however unclear on why this issue pops up at all. why is the `layout_builder.move_block_form`-route being triggered when the arguments clearly call for the `layout_builder.move_block` route.

I'm wondering if changing the path for one of the two routes would be a more stable solution? Two routes with very similar paths and arguments, that seems like asking for trouble to me.

Perhaps all non-publicly accessible routes (like ajax routes) should get some prefix, for example.

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