Een hart voor de Drupal Community

A configure link was added in the D11 release.

Thank you, i'll review this patch.

I just released a Drupal 11 update.

Hi markconroy,

Thanks for reporting a possible bug. Could you provide a little more information on how to reproduce this error? I don't seem to get this on a clean install. Any contrib modules that might interfere?

From what I can tell, the unserialize function in the below piece of code should only be run if the data isn't empty.

    if (!empty($this->getData($uid, 'roles'))) {
      $data = unserialize($this->getData($uid, 'roles'));
    }

However, it should be impossible for this data to be anything but a string, since it's only set by one function (the below code) and that code serializes the value before committing it to the DB.

  public function setRoles($uid, array $roles) {
    return $this->setData($uid, 'roles', serialize($roles));
  }

Hence why it sounds like some external source might be messing with the msqrole user data 🤔

PS. While the MR seems just fine, it simply shouldn't be needed.. Hence why I currently see that check more as unnecessary clutter, so I'd prefer to be able to reproduce it and perhaps fix it in a different way 😇

Just scanned the code of the module real quick and indeed this module would need a good portion of rewrites in order to work with Layout Builder.

Glad it worked!

Good luck with the project

Kind request for the current maintainer of this module to grant this person co-maintainership. I see there's no longer any supported version, while this is definitely a useful feature.

Thanks in advance!

@ozin MR updated according to the last patch provided by @Dylan Donkersgoed.

RandalV made their first commit to this issue’s fork.

Hi @remoschneider,

Please, refrain from posting a patch that isn't functionally brought up to date. The patch you posted applies, but is buggy due to the lack of the 'getPluginBlockId'-method in the InlineBlockEntityOperations class.

I'll post a patch that is functionally in line with the old one, if someone wants to turn it into an MR.

@alexpott

• MR applies cleanly to 10.3.x
• Done some tests and the results are as expected:
  • Same hash salt -> same session cookie name
  • Different hash salt -> different session cookie name
  • Can stay logged in across all subsites of a multisite on the same hostname with different hash salt
  • Giving all subsites the same hash salt has the expected behavior of being logged out when visiting a different subsite

Seems ready to me! Thanks for the MR.

This module provides an email message field (consisting of an email subject and email body). While this could also be achieved by a regular textfield + textarea field, there are occasions where you want to reference an email message as a whole. This module provides that ability.

Features

• Drupal field for adding an email subject / body.
• SOON: Submodule: optional integration with Site Settings and Labels module, to allow easy integration of configurable email messages into Drupal mails - via hook_mail() or Symfony Mailer.

Recommended modules/libraries

SOON:

• Site Settings and Labels
• Drupal Symfony Mailer

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