Een hart voor de Drupal Community

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.

@marcus thank you, this answer is really helpfull. As we probably can't fix this for all providers, we probably will create a seperate module.

How would you block the requests when the limits are reached?

In the world of agencies it's not uncommon that the web agency manages the API keys of the projects of their clients. The clients pay for a fixed fee and they have a limited amount of API requests for that specific key.

OpenAI, gemini, ... all have a system of spending limits, but they don't have a system to restrict limits per API key. This makes it hard for an agency to manage abusers.

It would be really helpfull if you could restrict the number of API calls for a specific API key. API calls and billing are not 100% correlated but it's enough to monitor and limit the usage within a project.

On top of that, some kind of overview with the number of API calls/month would be needed as well. We could provide some resources to help building this system but it would be nice if we could have input and guidance from the maintainers and the community.

aspilicious created an issue.

Bram Goffings added a comment on drupal.org: Fatal error when testing drupal 11

Bram Goffings added a comment on drupal.org: Fatal error when testing drupal 11

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

aspilicious created an issue. See original summary.

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.

Hey,

This adds drupal 11 support but it's very unusual to have a complete instal (including .ddev) folder inside a module. Try to restructure your module to remove any dependencies that are not needed.

The updated composer file in the patch is a start in the right direction.

Bram Goffings added a comment on drupal.org: Add Drupal 11 support

Drupal 11 support is missing

aspilicious created an issue. See original summary.

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.