Drupal CMS

Problem/Motivation

The module seems to call a function that doesn't exist anymore in Drupal 11.

Steps to reproduce

1. Install a Drupal 11 website
2. Install the latest layout_builder_at module (Mine is patched see below)
3. Create a block type to use in layout builder
4. Go to the form display of this block, the error hits

Patch:

"drupal/layout_builder_at": {
    "#3431569: Drupal 11 compatibility": "https://www.drupal.org/files/issues/2024-10-18/D11-compatibility-3431569-8.patch"
},

Remaining tasks

Look for a solution for the code at layout_builder_at.module line 56:

if ($hide) {
    layout_builder_form_entity_form_display_edit_form_alter($form, $form_state);
}

f0ns created an issue. See original summary.

Can confirm the issue persists and is solved by the patch, thanks!

I had the same issue and the MR fixed it for me in the form of a patch (in attachment for others that also need it).

Hi @julianriemersma,

Sorry for the delay, I'll try to take a look into this ASAP. I think something else might be wrong still, it's normal the authenticated role can't be chosen (since you *need* that role to use Masquerade by Role), but it shouldn't deny access when trying to masquerade as authenticated.

I think I've found a solution but need to do more testing. Will keep you updated.

Randal added a comment on drupal.org: Performance issue with the altSelector method in the SchemaMetatagManager class

Ignore my proposed solution, I just saw it's a static function. I tested it by adding a static property, but this doesn't seem to really help... The performance issue remains.

Perhaps a maintainer has a better proposal for this?

Problem/Motivation

On one of our websites, one that has a lot of available metatags/groups/.., we noticed the node edit page (and a custom entity's edit page) were extremely in loading. Through some profiling with xdebug and xhprof, I've come to the conclusion that the SchemaMetatagManager::altSelector method is the culprit. In our case, it got called 512 times but caused a very noticeable 400 ms delay. After uninstalling schema_metatag locally, the entities' edit pages were fast.

Proposed resolution

I'm not 100% certain on what a lasting/stable solution here would be, I think changing this code to the reworked snippet would already be a big step forward.

    /** @var \Drupal\metatag\MetatagManager $metatag_manager */
    $metatag_manager = \Drupal::service('metatag.manager');
    $metatag_groups = $metatag_manager->sortedGroupsWithTags();

    $group = '';
    $matches = [];
    $regex = '/:input\[name="(\w+)\[/';
    preg_match($regex, $selector, $matches);
    $id = $matches[1];
    foreach ($metatag_groups as $group_info) {
      if (!empty($group_info['tags'])) {
        if (array_key_exists($id, $group_info['tags'])) {
          $tag = $group_info['tags'][$id];
          $group = $tag['group'];
          break;
        }
      }
    }

Refreshed/reworked snippet:

  // Add a new property to the manager class.
  protected $metatagGroups;

    // Check and fill this property first, and access it directly on succeeding calls.
    if (!isset($this->metatagGroups)) {
      $metatag_manager = \Drupal::service('metatag.manager');
      $this->metatagGroups = $metatag_manager->sortedGroupsWithTags();
    }

    $group = '';
    $matches = [];
    $regex = '/:input\[name="(\w+)\[/';
    preg_match($regex, $selector, $matches);
    $id = $matches[1];
    foreach ($this->metatagGroups as $group_info) {
      if (!empty($group_info['tags'])) {
        if (array_key_exists($id, $group_info['tags'])) {
          $tag = $group_info['tags'][$id];
          $group = $tag['group'];
          break;
        }
      }
    }

But I'm open to other suggestions! 😇

randalv created an issue. See original summary.

I created a patch with replaces $.trim with .trim() based on the JQuery documentation:

Note: This API has been deprecated in jQuery 3.5; please use the native String.prototype.trim method instead. Unlike jQuery.trim, String.prototype.trim does not work with types other than strings (null, undefined, Number). Make sure that your code is compatible when migrating.

Source: https://api.jquery.com/jQuery.trim/#:~:text=Note%3A%20This%20API%20has%2....

The error is now gone and the functionality works again as it should with AJAX checked.

I have the same issues in a Drupal 11 environment using the Views Load More module with the following error:

An error occurred during the execution of the Ajax response: TypeError: $.trim is not a function"

Your reasoning on where this error comes from seems accurate.

Tested and works great, would be nice to get this in an official release. Thanks!

Problem/Motivation

For the Drupal.be I wanted to add links to our Facebook Group & Mastodon account at drupal.community. These do not generate an icon, like Meetup, Linkedin, etc.. do. I guess we can add them to our instance individually, but would be good to get that fixed upstream.

Maybe we need to make use of the new Icon API in Drupal? https://www.drupal.org/docs/develop/drupal-apis/icon-api

MR can be reviewed, it's a simple but logical change.

Problem/Motivation

In #3450154, the patch added `=== 0` to two of the preg_match comparisons which essentially wrecked this functionality. In our case, this fails in the js code that does this:

  if (additionalConfigInfo.length === 0) {
    gtag('config', config.tagId);
  } else {
    gtag('config', config.tagId, additionalConfigInfo);
  }

Because the `config.tagId` value is empty.

Steps to reproduce

This should be visible as soon as you configure google tag with the google analytics debugger chrome plugin.

Proposed resolution

Simply remove the `=== 0` in the comparison so this functionality works again like before.

randalv created an issue. See original summary.

Problem/Motivation

My PHPCS pipeline fails with the new 8.3.27 release. It throws the following error:

Fatal error: Uncaught Error: Class "Drupal\Sniffs\Semantics\FunctionCall" not found in /root/.composer/vendor/drupal/coder/coder_sniffer/Drupal/Sniffs/Semantics/PregSecuritySniff.php:22

When I update the pipeline to use 8.3.26 explicitly, it works again. I have checked the release notes for version 8.3.27, but can't find anything specific that would break it, since these classes were not changed recently.

Any pointers perhaps?

Problem/Motivation

I would like to become a co-maintainer of this module to merge the Drupal 11 compatibility patch along with any appropriate RTBC issues and create a D11-compatible release.

You can view my profile to see my large history of work.

Proposed resolution

Review my profile and, if approved, add me as co-maintainer with appropriate permissions to merge code, manage issues, and create releases.

Remaining tasks

Add me as co-maintainer for this module.

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

Fix CSpell warning reported in Gitlab CI pipeline.

Added the correct patch and not the old one that did not apply =)

I applied MR 35 as a patch:

https://git.drupalcode.org/project/context/-/merge_requests/35.patch

But then the D11 compatibility patch didn't apply anymore after that so I made a new one (in attachment) that does work.

Apply it after the above patch.

Problem/Motivation

Related to #3344334: Settings Tray does not close on placement of block, when using layout_builder_browser module, instead of the default settings tray, the browser window should also be closed upon placement of a block from within the iframe.

Problem/Motivation

I would like to become a co-maintainer of this module to merge the Drupal 11 compatibility patch along with any appropriate RTBC issues and create a D11-compatible release.

You can view my profile to see my large history of work.

Proposed resolution

Review my profile and, if approved, add me as co-maintainer with appropriate permissions to merge code, manage issues, and create releases.

Remaining tasks

Add me as co-maintainer for this module.

I was looking for this functionality as well. We have a website that has pricelists 'linked' to a value on the user entity.

We import our pricelists from an ERP, and we've worked around this issue by hooking onto the user & pricelist insert/update events.

Pricelist on insert/update: - Find all users with the custom value and attach them to the customers field User on insert/update: - Remove the user from pricelist(s) with the old value (if applicable) and add to pricelist(s) with the new value

The main problem here is that, if no users have the value of that pricelist, the pricelist applies to EVERY user. That's something that conditions would have easily solved. In our use case, we've solved this by creating a 'dummy' user and if no other users apply for the pricelist, we attach the 'dummy' user to the pricelist.

Configuration/development wise this would have been much faster and cleaner if we had conditions, but I understand the argument of speed is a factor here too. I'll set this as postponed, it's not and hasn't been really an active issue and if the need arises later on it can be reopened.

Just tested the new patch on 4.2.2, it works great.

Thanks a lot!

Fons added a comment on drupal.org: Fix the issues reported by PHP_CodeSniffer

Ah.. my bad, you're absolutely right. I overlooked the default value of the class property.

I'm not sure if a backport to 1.x is still necessary, I suppose it depends on how long 8.x-1.x will remain supported? If it will, then maybe it would be good to have that fix there too 😇

Hi @mably, apologies, I hadn't seen that!

Although if I'm not mistaken that doesn't entirely fix the issue I was experiencing, because the encoder will still not strip tags or trim strings unless a setting is specifically provided (whereas before it would strip/trim by default).

With the fix currently in the 2.x branch, the warning message is gone, but if the encoder is used in Views Data Export it'll still let any and all HTML through (without the possibility of configuring it otherwise 😞).

It would be easily solved if encoders allowed configuration forms, but since (I think?) they don't, would it be preferred to keep the old functionality intact?

I've created an MR that adds default values. This preserves the behavior pre-#3108301.