🇧🇪Belgium @gorkagr

@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 :)

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

If that is the approach, then i assume the same view should be created in a hook_update for those with the module already enabled and the view not created.

The other option i was considering was to alter the GroupViewBuilder and overwrite isViewModeCacheable(), but might be better the view approach :)

gorkagr → created an issue.

Implemented @nod_ suggestion and also updated the test as node__1 there uses a template on the theme and not in core/modules/node/templates, so that's why the test was failing. All should be good, unless we need a new test to cover the case where no template is overridden (maybe with the node_edit_form template?)

ok, with my last commit, the test fails.
But if understand correctly the test flow, the active theme ($variables['directory']) is 'core/modules/system/tests/themes/test_theme/', correct?
and because of that, the template of check is provided by the theme too (not the node module itself), so the assert ($this->assertStringContainsString("BEGIN OUTPUT from '$template_filename'", $output, 'Full path to current template file found.');) should be changed too?

Changed to see if the template file that is being checked is from the active directory, so in that case it should be an overridden template, shouldnt it?

Best

I have removed the return type, but as the function is protected, i think it was ok to leave it there (i did query the function within git and i did not find a match except for his function itself)

If it is missing to anonymous only it could be some missing permissions (either general ones or maybe inside group if the module is being used)

gorkagr → created an issue.

Implemented the suggestion if I understood it correctly

MR opened and patch ported there

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

A template could also be placed in a module under the /custom folder, so the last commit I'd rather say "CUSTOM TEMPLATE" rather than custom theme as it might point to the wrong location

Test are green now :)

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

Just updated DDEV to latest version and it comes with php8.2.15 (and it seems with 8.3.2 too based on the changelog)

The error on the CLI is gone, and i assume any other error.

I am moving this to "needs review" but I'd say that we can change it to "Fixed" and close the issue if more ppl have the msg gone

Implemented suggestions

@larowlan

I opened an issue about that

https://www.drupal.org/project/drupal/issues/3414368#comment-15422422 🐛 Incorrect types in variables used in Drupal\Core\Field\Annotation\FieldType Needs review

Sorry, i forgot to remove the draft the last time.
Replied to the comment with one example where an array is used in core :)

IF this is implemented, should the file be added as well to the .gitignore file?

Test passed (failed due to an unrelated issue)

Hi!

I have adapted & implemented the changes done here (for 11.x) locally to a 10.2 (as FieldStorageAddForm is quite different) and fields with a 1-line description now appears properly (eg: reference fields or the ones of the address module with the patch in https://www.drupal.org/project/address/issues/3413017 🐛 Using a translatable string as a category for field type is deprecated in drupal:10.2 Needs work ), as you can see in both images uploaded.

Can be the test fails as i left @ingroup plugin_translatable but the var now is set as \Drupal\Core\Annotation\Translation|array? or it is not related and failed another thing?

gorkagr → created an issue.

As it seems to be fixed, we can set the issue as fixed I believe :)

Although fixed, another example of a module (comment module of core) affected if a role (authenticated in that case) is deleted.

Taking a look at the code lines of your error:

      $this->authenticatedCanPostComments = $this->entityTypeManager
        ->getStorage('user_role')
        ->load(RoleInterface::AUTHENTICATED_ID)
        ->hasPermission('post comments');

the code is trying to load the 'authenticated' user. If you are missing it from your system, then it will be null and hasPermission will fail obviously.

So try to restore the user as I have mentioned before :)

Hi!

For restoring your missing role, you can do either:
- create it via the UI and set the machine name "authenticated"
or
- if you have a second drupal site, get the file from config/sync/user.role.authenticated.yml, copy it into the faulty site, open it with the editor to double check first you dont have any permission you should not, and then run with drush a config import (drush cim) so it is restored.

Most likely, if you dont have that role, the problems might come from there

8.2.14 landed a few days ago :)

I dont know if DDEV updates php.automatically or a new release is needed, but smth for next week :)

Best

IS updated

gorkagr → changed the visibility of the branch 3409663-rebased-datetime-duplication to active.

gorkagr → changed the visibility of the branch 3409663-rebased-datetime-duplication to hidden.

Hi @kristiaanvandeneynde

New patch works fine at least in 3.2.2 :)
thnks