🇧🇪Belgium @gorkagr

I have opened https://www.drupal.org/project/group/issues/3494986 🐛 Review DI in classes and their construct methods Needs work to check the DI in controllers there (and maybe the __construct methods) :)

Best

I am not sure if you have also planned to do smth in the constructors and declare the variables directly in the params:

smth like
original:

  /**
   * The private store factory.
   *
   * @var \Drupal\Core\TempStore\PrivateTempStoreFactory
   */
  protected $privateTempStoreFactory;

  /**
   * The renderer.
   *
   * @var \Drupal\Core\Render\RendererInterface
   */
  protected $renderer;

  /**
   * Constructs a new GroupController.
   *
   * @param \Drupal\Core\TempStore\PrivateTempStoreFactory $temp_store_factory
   *   The private store factory.
   * @param \Drupal\Core\Render\RendererInterface $renderer
   *   The renderer.
   */
  public function __construct(PrivateTempStoreFactory $temp_store_factory, RendererInterface $renderer) {
    $this->privateTempStoreFactory = $temp_store_factory;
    $this->renderer = $renderer;
  }

idea:

  /**
   * Constructs a new GroupController.
   *
   * @param \Drupal\Core\TempStore\PrivateTempStoreFactory $temp_store_factory
   *   The private store factory.
   * @param \Drupal\Core\Render\RendererInterface $renderer
   *   The renderer.
   */
  public function __construct(
    protected PrivateTempStoreFactory $privateTempStoreFactory,
    protected RendererInterface $renderer,
  ) {
  }

But then i assume that should be done to all files that have a __construct(), so all of them are unified

gorkagr → created an issue.

Hi!
Thanks a lot for the roadmap :)

Maybe Stop saving an entity when it gets added to a group is linked to #3057483 (core) 📌 [PP-2] Better describe how SynchronizableInterface should be used for content entities Needs work and/or #2872697 (group) → / #3478088 (group) 🐛 Group relationship saving/deletion resaves entities without using ::setSyncing() Active

Best

Cspell error should be fixed.
Remain the other 2

Cspell error should be fixed. pending the other 2

gorkagr → created an issue.

gorkagr → created an issue.

Hi!

I can confirm the MR works. Support for old UA- properties ended this summer, so this code should be in place for any new GA-xxx property

gorkagr → created an issue.

Dios, esta no me la pierdo x nada :D :D :D

I think also a core-dev update also is needed (https://github.com/drupal/core-dev/blob/11.0.6/composer.json) as it requires both phpstan/phpstan and mglaman/phpstan-drupal

After testing the patch, i have realized that with the patch, any file uploaded does not follow 'File path' and 'file name' anymore, only what it seems the 'file_directory' path.

Best

The error seems to be in Chrome, as Dimitris says.

The error in our log looks like:

Type: 	access denied

Path: /user/{user}/masquerade?token={token}. Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException: 'csrf_token' URL query argument is invalid. in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 115 of /.../web/core/lib/Drupal/Core/Routing/AccessAwareRouter.php).

gorkagr → created an issue.

Same error making the site a bit unusable for us (at least is local and we did not deploy it yet).

MR works fine.
Best

fjgarlin → credited gorkagr → .

If a maintainer can close the MR, appreciated

Hi!

I came with this issue while doing an accessibility check on one of my sites taht uses the module and i came with a MR in a different issue ( https://www.drupal.org/project/eu_cookie_compliance/issues/3472337#comme... 🐛 Missing aria-labelledby element in definition of popup banner Closed: duplicate )
That one is closed, but i see I ussed the other attribute missing rather than the one used in this issue.

Best

AH, my bad. I did not see https://www.drupal.org/project/eu_cookie_compliance/issues/3379830 🐛 Elements with role="dialog" or role="alertdialog" do not have accessible names Needs work

Closing as duplicate of the other one

I have updated the JS and applied the locally, making the issue to be gone and be passed in the mentioned checker :)

gorkagr → created an issue.

Hi!

I have set my tmp path in settings.php
Either i use /tmp or ../../tmp, the preview does not work and I have the mentioned error in the IS.
with the patch in 32, the preview is displayed in any edit form's field that uses filefield_path

Best

I was thinking as it is infrastucture as the mentioned file does not return anything, the msg in slack is just pointing to the same url i have posted (updates.drupal.org one)

Hi

I dont think it is a 10.3.2 issue (i can see this on 10.3.1)
It seems it is more an infrastructure issue as pointed out in: https://drupal.slack.com/archives/C51GNJG91/p1724654960784699

https://updates.drupal.org/release-history/drupal/current seems to return nothing

Best

Hi @saschaeggi

Latest dev release fixes this, i dont see the double checkbox where i had this.

   $ composer require 'drupal/gin:3.x-dev@dev'
   
   - Upgrading drupal/gin (3.0.0-rc13 => dev-3.x 13b5936)

Hi!

I think trying to apply a patch for a composer.json and then trying to do smth related with composer is smth that always fails (at least for me)
However, if i edit by hand my composer.lock with @aronne modification and also (just in case) the http_client_manager composer.json, and then i run composer require drush/drush:^13.0, then all good:

  - Installing illuminate/macroable (v11.20.0): Extracting archive
  - Installing psr/simple-cache (3.0.0): Extracting archive
  - Installing illuminate/contracts (v11.20.0): Extracting archive
  - Installing illuminate/conditionable (v11.20.0): Extracting archive
  - Installing illuminate/collections (v11.20.0): Extracting archive
  - Installing laravel/prompts (v0.1.24): Extracting archive
  - Upgrading drush/drush (12.5.3 => 13.0.1): Extracting archive

I also think that in the patch doing ^12|^13 could work

Best

In localhost,

first replaced the 2.0.0 version with the last in dev (dev-2.0.x 25cbfc8)
then applied MR 21 (as is 2.0.x) code as a patch via composer
a little bit of drush cr...

and then all good, if i repeat the steps from the original IS

1. Open a private session on the browser, so no cookies are on both sites (server and client)
2. Open the client page and use the 'login with CAS' to be redirected to the server
3. On the server site, fill username and password and login. Good!!

step 3 is executed good and redirects to the client site succesfully :)

Many thnks for the patch!!

Hi!
Tomorrow I will do the testing, i did not have time these last days due to last-minute urgent fixes on one project.
but those are done already, so tomorrow I will be able to jump on this

Sorry for the delay

A little bit more of info in my case: D@10.3.2 and gin@RC13
I can see the issue in both pages mentioned above (one from core, one on the upgrade_status module)

If i inspect the HTML from the page, it seems no other templates apart from core, gin or claro are used

The piece of code that seems to be duplicated comes from https://www.drupal.org/project/gin/issues/3458191 🐛 [webform] The table width does not fill the screen Fixed (MR diff)

in my case, on the page of the upgrade_status module, i can see the following code is rendered:

<th class="select-all gin--sticky-bulk-select">
  <input type="checkbox" class="form-checkbox form-boolean form-boolean--type-checkbox" title="Select all rows in this table">
  <input type="checkbox" class="form-checkbox form-boolean form-boolean--type-checkbox" title="Select all rows in this table">
</th>

and if we take a look at templates/dataset/table.html.twig (L66 onwards):

  <{{ cell.tag }}{{ cell.attributes.addClass(cell_classes) }}>
    {{- cell.content -}}
    {% if 'gin--sticky-bulk-select' in cell_classes %}
      <input
        type="checkbox"
        class="form-checkbox form-boolean form-boolean--type-checkbox bar"
        title="{{ 'Select all rows in this table'|t }}"
      />
    {% endif %}
  </{{ cell.tag }}>

the additional input is the second one rendered in the table (i think in this case, the original cell.content already contains the 'select all' and then it is rendered a second time making hte duplication

I have checked other sites i have, and same issue appears in the others, same piece of code

Hope it helps

Hi!

Also same issue in admin/reports/updates/update and also in admin/reports/upgrade-status pages, to see if others also experience the error there.
I thought https://www.drupal.org/project/gin/issues/3460194 🐛 Double check-all checkboxes in sticky header Fixed could provide a fix but it is not the case for me, so changed to 'active' in order to dig more

Best

Hi!

Thnks for the quick reaction to the issue.
I cannot test it before the 12th, but i will do it first thing on that day :)

Best

MR added with a proposed solution that does work in our websites, making the error and the wrongfully redirection to disappear.

gorkagr → created an issue.

@ady1503, as far as i tested, those themes are not affected by this issue, at least not to me. Olivero implements its own drupal.messages override (if i am not wrong)

Bootstrap, radix.. those yes (at least to me)

I am not sure if it is on mine or if i did smth wrong (as i messed with my localhost a bit)

but it seems i have some DB tables named after group_content (nstead of group_relationship) in config_export table
and also a few entries in key_value with group_content_type keyword

I will continue testing this

el7cosmos → credited gorkagr → .

Hi!

Somehow i had this issue in one of my localhost while running cron, the same error has appeared in my "recent log messages" page.

Moved patch #44 to a MR

Best

gorkagr → made their first commit to this issue’s fork.

MR diff works fine in 10.3.1 and last pathauto.
thnks

Hi!

As mentioned in slack.
Performed:

ddev composer require 'drupal/group:3.3.x-dev@dev'
ddev composer require 'drupal/subgroup:^3.0' --no-update
added the patch https://git.drupalcode.org/project/group/-/merge_requests/151.diff
ddev composer update
drush updb

then a fiend & replace in all my code from group_content to group_relationship

all seems good.

I have only experienced 2 issues I have noticed today.

There was a pathauto alias that was broken: pathauto.pattern.group_content.yml
and also a core.entity_view_mode.group_content.token.yml

Then, i have no clue if it is just my DB, but when running cron() i have this log message:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "group_content" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (line 142 of /var/www/html/web/core/lib/Drupal/Core/Entity/EntityTypeManager.php).

but there is no trace of such string in my database, so i have no clue from where the error is coming from

MR works for me.
Also as this breaks any site that updates to 10.3.1, updated to major :)

Best

my setup (so far locally), works as all the Drupal sites share the same DB (using the domain module)

gorkagr → created an issue.

gorkagr → created an issue.

Seems to be good to me, i cannot say what might be the error.
I have tested so far locally and all works for me so far.

I have done a bit more testing in some of the sites i have:

Workaround on #17 works for the sub-themes made with bootstrap@3, radix@v4 & radix@v5.
Radix@v6 works fine without #17 (actually, with #17 it causes duplicated messages)

With #17, workaround #45 is not necessary, at least in all the pages so far i have tested it.

Ah, I forgot to mention that, it seems claro/gin themes are not affected (i believe big_pipe also works in admin mode but i am not sure about that)

claro/gin use different hooks and libraries for handle messages (hook_preprocess_status_messages and hook_element_info_alter), so that might be it fails on certain hooks??

If in the class @solideogloria is mentioning (core/modules/big_pipe/src/Render/BigPipe.php), i comment (i know i should not, i am not an expert of core but i have just tried):

          // Delete all messages that were generated during the rendering of this
          // placeholder, to render them in a BigPipe-optimized way.
          // $messages = $this->messenger->deleteAll();
          // foreach ($messages as $type => $type_messages) {
          //   foreach ($type_messages as $message) {
          //     $ajax_response->addCommand(new MessageCommand($message, NULL, ['type' => $type], FALSE));
          //   }
          // }

the output is good and hey, it takes even less time (0.00482 segs vs 0.00868 segs):

...
<!-- RENDERING TIME: 0.004825830 -->
<!-- THEME DEBUG -->
<!-- THEME HOOK: 'block' -->
<!-- FILE NAME SUGGESTIONS:
   ▪️ block--egm-theme-messages.html.twig
   ✅ block--system-messages-block.html.twig
   ▪️ block--system.html.twig
   ▪️ block.html.twig
-->
<!-- BEGIN OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->
<div data-drupal-messages-fallback="" class="hidden"></div>

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'status_messages' -->
<!-- BEGIN OUTPUT from 'themes/contrib/radix/templates/misc/status-messages.html.twig' -->

<div role="region" aria-label="Status message">
  <div class="alert alert-success alert-dismissible" role="alert">
      All caches cleared.
      <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
  </div>
</div>

<!-- END OUTPUT from 'themes/contrib/radix/templates/misc/status-messages.html.twig' -->
<!-- END OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->
<!-- END RENDERER -->

Hi!

Experiencing the same error here with a theme based on Radix5.

This is the output I get on the theme:

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'region' -->
<!-- FILE NAME SUGGESTIONS:
   ▪️ region--notifications.html.twig
   ✅ region.html.twig
-->
<!-- BEGIN OUTPUT from 'themes/contrib/radix/templates/region/region.html.twig' -->
  <!-- START RENDERER -->
<!-- CACHE-HIT: No -->
<!-- CACHE TAGS:
   * block_view
   * config:block.block.egm_theme_messages
-->
<!-- CACHE CONTEXTS:
   * url.site
   * languages:language_interface
   * theme
   * user.permissions
-->
<!-- CACHE KEYS:
   * entity_view
   * block
   * egm_theme_messages
-->
<!-- CACHE MAX-AGE: -1 -->
<!-- PRE-BUBBLING CACHE TAGS:
   * block_view
   * config:block.block.egm_theme_messages
-->
<!-- PRE-BUBBLING CACHE CONTEXTS:
   * url.site
   * languages:language_interface
   * theme
   * user.permissions
-->
<!-- PRE-BUBBLING CACHE KEYS:
   * entity_view
   * block
   * egm_theme_messages
-->
<!-- PRE-BUBBLING CACHE MAX-AGE: -1 -->
<!-- RENDERING TIME: 0.003482819 -->

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'block' -->
<!-- FILE NAME SUGGESTIONS:
   ▪️ block--egm-theme-messages.html.twig
   ✅ block--system-messages-block.html.twig
   ▪️ block--system.html.twig
   ▪️ block.html.twig
-->
<!-- BEGIN OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->
<div class="" data-drupal-messages=""><div class="messages__wrapper"><div class="messages messages--status" role="status" data-drupal-message-id="status-516592592779658" data-drupal-message-type="status" aria-label="Status message">All caches cleared.</div></div></div>

<!-- END OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->
<!-- END RENDERER -->
<!-- END OUTPUT from 'themes/contrib/radix/templates/region/region.html.twig' -->

Now, if i use the code of #17 in my theme:

use Drupal\Core\Render\Element\StatusMessages;

function mytheme_preprocess_block__system_messages_block(&$variables)
{
  $variables['content'] = StatusMessages::renderMessages();
}

, the output changes to:

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'region' -->
<!-- FILE NAME SUGGESTIONS:
   ▪️ region--notifications.html.twig
   ✅ region.html.twig
-->
<!-- BEGIN OUTPUT from 'themes/contrib/radix/templates/region/region.html.twig' -->
  <!-- START RENDERER -->
<!-- CACHE-HIT: No -->
<!-- CACHE TAGS:
   * block_view
   * config:block.block.egm_theme_messages
-->
<!-- CACHE CONTEXTS:
   * url.site
   * languages:language_interface
   * theme
   * user.permissions
-->
<!-- CACHE KEYS:
   * entity_view
   * block
   * egm_theme_messages
-->
<!-- CACHE MAX-AGE: -1 -->
<!-- PRE-BUBBLING CACHE TAGS:
   * block_view
   * config:block.block.egm_theme_messages
-->
<!-- PRE-BUBBLING CACHE CONTEXTS:
   * url.site
   * languages:language_interface
   * theme
   * user.permissions
-->
<!-- PRE-BUBBLING CACHE KEYS:
   * entity_view
   * block
   * egm_theme_messages
-->
<!-- PRE-BUBBLING CACHE MAX-AGE: -1 -->
<!-- RENDERING TIME: 0.008680820 -->
<!-- THEME DEBUG -->
<!-- THEME HOOK: 'block' -->
<!-- FILE NAME SUGGESTIONS:
   ▪️ block--egm-theme-messages.html.twig
   ✅ block--system-messages-block.html.twig
   ▪️ block--system.html.twig
   ▪️ block.html.twig
-->
<!-- BEGIN OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->
<!-- THEME DEBUG -->
<!-- THEME HOOK: 'status_messages' -->
<!-- BEGIN OUTPUT from 'themes/contrib/radix/templates/misc/status-messages.html.twig' -->

<div role="region" aria-label="Status message">
   <div class="alert alert-success alert-dismissible" role="alert">
      All caches cleared.
      <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
  </div>
</div>

<!-- END OUTPUT from 'themes/contrib/radix/templates/misc/status-messages.html.twig' -->
<!-- END OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->
<!-- END RENDERER -->
<!-- END OUTPUT from 'themes/contrib/radix/templates/region/region.html.twig' -->

and the message is rendered as it used to be

Indeed that path is broken in 10.3.0

I have just noticed line 318 (the one that causes the error) is

    $form = $this->formBuilder()->getForm($this);

comparing the DraggableListBuilder class, in 10.2 there is available:

  /**
   * Returns the form builder.
   *
   * @return \Drupal\Core\Form\FormBuilderInterface
   *   The form builder.
   */
  protected function formBuilder() {
    if (!$this->formBuilder) {
      $this->formBuilder = \Drupal::formBuilder();
    }
    return $this->formBuilder;
  }

while in 10.3 that function it is not available anymore but it seems using $this->formBuilder is ok
So maybe having a code such as to maintain BC ??

    if (\version_compare(\Drupal::VERSION, '10.2.9999', '<')) {
      $form = $this->formBuilder()->getForm($this);
    }
    else {
      $form = $this->formBuilder->getForm($this);
    }

but i cannot check this right now in any 10.2.x or lower drupal site

+1

Hi!
You have to configure the domains on admin/config/multi_domain_login

Then, once you do login in one domain, a session will be open in the rest of the domains configured.

Hi!

Not sure if it is the same issue or not, as i did not see anything related with the "Send all affiliates" field.
I have opened smth similar with a patch provided there ( https://www.drupal.org/project/domain_path/issues/3452676#comment-15628074 🐛 Assuming 'field_domain_all_affiliates' exists create duplicate aliases Needs review )

Pipeline failed due to an unrelated test.

gorkagr → created an issue.

hi!

after https://www.drupal.org/project/http_client_manager/issues/3451503 🐛 Revert #3446808 and rename branch 3.x Fixed i believe this should be now against branch 10.x instead to 9.3.x.

Best

yeah, all seems good now.

9.3 should be back to be compatible with old drupals (sorry one more time) anow the newer version appears to be installed

@achton, i opened https://www.drupal.org/project/http_client_manager/issues/3451503 🐛 Revert #3446808 and rename branch 3.x Fixed as a follow-up to revert this change (so u can still use 9.x without pinning the version), but also to propose a renaming of 3.x so it uses a proper versioning :)

Apologies

I have pushed the code to revert 3446808.
Then the only tasks remaining are:
- to merge and do a new release on 9.x so people using the module are not affected
- maybe flag as unsecure 9.3.11 (apologies)
- and to rename 3.x branch to 10.x so the versioning is higher, making a 10.x release

gorkagr → created an issue.

hi @achon

After upating to 9.3.11 (therefore this pacth), all is good.
But it seems your symfony is a bit outdated, as

Symfony\Component\Config\Loader\LoaderInterface::load($resource, $type = null)

seems to be a bit old code

Which version of Drupal / PHP are you?

Just to see the version that I got installed of symfony:

$ ddev composer info symfony/config
name     : symfony/config
descrip. : Helps you find, load, combine, autofill and validate configuration values of any kind
keywords : 
versions : * v7.0.7
released : 2024-04-18, 1 month ago
...

All good now, update_status can analise the module and skip the @internal errors :)

Than you very much!!

Hi!

Before applying the patch, i get the following error in one module:

Class Drupal\ieg_core\Form\BaseCreateNodeEventForm extends @internal class Drupal\node\NodeForm.

after applying the patch, i get the following error:

PHPStan command failed:

/usr/bin/php /var/www/html/vendor/bin/phpstan analyse --memory-limit=1500M --error-format=json --configuration=/tmp/upgrade_status/deprecation_testing.neon /var/www/html/web/modules/custom/ieg_core
Command output:

Empty.
Command error:

In NeonAdapter.php line 44: Error while loading /tmp/upgrade_status/deprecation_testing.neon: Duplicated key 'drupal_root' on line 6, column 3. analyse [-c|--configuration CONFIGURATION] [-l|--level LEVEL] [--no-progress] [--debug] [-a|--autoload-file AUTOLOAD-FILE] [--error-format ERROR-FORMAT] [-b|--generate-baseline [GENERATE-BASELINE]] [--allow-empty-baseline] [--memory-limit MEMORY-LIMIT] [--xdebug] [--fix] [--watch] [--pro] [--fail-without-result-cache] [--] [...]

best

Hi!

As per (https://github.com/mglaman/phpstan-drupal/pull/754/commits/e3f40b68f35d4...), released in mglaman/phpstan-drupal V1.2.11 on May 10th, if you have that version in your local the error is accepted.

There is a second issue opened in upgrade_status module ( https://www.drupal.org/project/upgrade_status/issues/3445307 ✨ Disable ClassExtendsInternalClassRule Fixed ) so until that one is merged, the error is only fixed in the CLI analysis.

Nevertheless I have update the phpstan.neon of the module to include the rule that triggers the error for then upgrade_status is updated :)

+1 :D

As this is blocking the option of removing the users (and somehow the patch is not applied fully in the composer.lock when I am doing composer update drupal/http_client_manager -W), could we also have a 9.3.11 release when this is merged, please?

gorkagr → created an issue.

gorkagr → created an issue.

I think the issue only appears when doing PHPStan analysis to the code, but I havent run drupal-status to the module nor PHPstan command to this module.

Best

Hi!

I have also noted in 3.3.x the issue is still active.

When doing a basic code such as:

  $new_location = \Drupal::service('entity_type.manager')->getStorage('node')->create([my_fields]);
  $new_location->save();
  $new_event->addRelationship($new_location, 'plugin');

if the node entity contains any postSave() function, such as:

  /**
   * {@inheritdoc}
   */
  public function postSave(EntityStorageInterface $storage, $update = TRUE): void {

    // PostSave as expected.
    parent::postSave($storage, $update);

    // Do this only in an update; the insert should be done via hook too.
    if ($update) {
      // Let's do here some redirection here for example
    }
  }

}

that one is triggered one more time during the addRelationship() function as the following function is triggered (in GroupRelationship.php):

  /**
   * {@inheritdoc}
   */
  public function postSave(EntityStorageInterface $storage, $update = TRUE) {
    parent::postSave($storage, $update);

    // For memberships, we generally need to rebuild the group role cache for
    // the member's user account in the target group.
    $rebuild_group_role_cache = $this->getPluginId() == 'group_membership';

    if ($update === FALSE) {
      // We want to make sure that the entity we just added to the group behaves
      // as a grouped entity. This means we may need to update access records,
      // flush some caches containing the entity or perform other operations we
      // cannot possibly know about. Lucky for us, all of that behavior usually
      // happens when saving an entity so let's re-save the added entity.
      $this->getEntity()->save();
    }
  ........

+1

Hi @amandeep_lnwebworks

Patch in #8 seems incomplete and code missing, and the install() seems to not work as the info of the module is incomplete.
My patch only works with the latest code from the dev branch, not if you have the latest release install (for that you need the rest of the patches in between this MR and the last release); If i see the image of the error, it looks like you have missing code as line 139 does not match with the changes i did.

I will hide for the moment your patch just in case and will wait for a maintainer to take a look at both.

HI

I have reviewed the comments. In https://git.drupalcode.org/project/consumers/-/merge_requests/12/diffs?c... i c&p from the class to the installer and i did not notice the @label, but in the first commit was good, so i set directly consumer inside the t().

Best

I forgot that tests could fail as the patch is using code that does not exist in the consumers module. So back to "needs work" until consumers has a new release with the proposed MR

thnks

Hi!

I think that is the code needed to create a new status field and set a value to existing consumers.
I have also added a new column on the listBuilder as well.

Best

Hi!

I believe that is the place to check if a consumer is active/inactive in combination with the Consumers' MR mentioned in the issue.
Best

gorkagr → created an issue.

gorkagr → created an issue.

Hi!

if using this module (v5.2.5) for login in a gitlab instance from a D10, I get the following error with the respective MR:

Could not authenticate you from OpenIDConnect because "Request uri must have schema. possibly add 'http://' to the request uri?".

Without the patch, i have the error in #1.

in gitlab I have 2 login providers: oauth2_generic (works fine) and openid_connect (error)

Config details:

gitlab_rails['omniauth_providers'] = [
  {
    name: "openid_connect",
    label: "OIC",
    args: {
      name: 'openid_connect',
      scope: ['openid', 'oauth2_access_to_profile_information'],
      response_type: 'code',
      issuer: 'https://oauth.ddev.site',
      discovery: false,
      uid_field: 'preferred_username',
      client_auth_method: 'basic',
      client_options: {
        identifier: 'gitlab',
        secret: 'gitlab',
        redirect_uri: 'https://gitlab.ddev.site/users/auth/openid_connect/callback',
        userinfo_endpoint: "https://oauth.ddev.site/oauth/userinfo",
        authorization_endpoint: "https://oauth.ddev.site/oauth/authorize",
        token_endpoint: "https://oauth.ddev.site/oauth/token"
      }
    }
  },
 {
   name: "oauth2_generic",
   label: "OAUTH",
   app_id: "git",
   app_secret: "git",
   args: {
     client_options: {
       site: "https://oauth.ddev.site",
       user_info_url: "/oauth/v1/userinfo",
       authorize_url: "/oauth/authorize",
       token_url: "/oauth/token"
     },
     user_response_structure: {
       root_path: [],
       id_path: ["sub"],
       attributes: {
         email: "email",
         name: "name"
       }
     },
     authorize_params: {
       scope: "oauth2_access_to_profile_information"
     },
     strategy_class: "OmniAuth::Strategies::OAuth2Generic"
   }
 }
]

Agreed on the comment, it is always the hardest part :D :D , but i liked your last sentence so i have used it ;)

@cat, you mean in core/modules/system/tests/modules/performance_test/src/Cache/CacheTagsChecksumDecorator.php::isValid(), correct?

if we do as well there the

    if (empty($tags)) {
      return TRUE;
    }

should we also do a $this->logCacheTagOperation([], 0, 0, CacheTagOperation::isValid); (or smth like that before the return? Or there is no need to log the operation?

Hi!
I hope is fine, i have added the snippet of @wim Leers in https://www.drupal.org/project/drupal/issues/3421881#comment-15456992 📌 Track cache tag queries separately in performance tests Active in here :)