Gin Toolbar erased from Frontend after flushing all caches and executing cron

Same here on Drupal 11.5.0 + Gin_Toolbar 3.0.1 ;

It seems that the third ".toolbar-tab" is missing the ".toolbar-tab--toolbar-item-administration" class to be visible

What version of Drupal core is that happening on? 11.5 as mentioned in #2 doesn't exist yet.

haha sorry, mismatch between 10.5.0 and 11.2.0 ; I was talking about 11.2.0 in #2.

After some digging, it seems that after a cache flush the function gin_toolbar_theme_registry_alter() is run and the check introduced in https://git.drupalcode.org/project/gin_toolbar/-/commit/80e4caa863df5a0a... prevent altering the theme registry if a user without access to the toolbar call the website first. (_gin_toolbar_gin_is_active() will return FALSE)

In the meantime, (Use at your own risks) this patch remove the _gin_toolbar_gin_is_active() check from gin_toolbar_theme_registry_alter().

Great findings, thanks @mediengenosse and thanks @opi

The fix described in #5 is actually legit because Gin certainly needs to alter the theme registry, regardless of the current context after a cache rebuild. I'll fix that and we publish a new patch release soon.

@opi contributions are much more helpful when provided in issue forks with MRs. Patch files will go away soon anyway. Just a friendly reminder for next time ;-)

Turns out, we now have changed gin_toolbar_theme_registry_alter to alter the registry, but I also found 2 more that should similarly always be executed after a cache rebuild but haven't:

• gin_toolbar_theme_suggestions_container_alter
• gin_toolbar_library_info_alter

I've now updated them both as well. Please test this thoroughly and let us know if everything still works.

The .patch was mostly created for quick composer patching ;)

Agreed with you for the 2 more hooks, according to my quick testing. Thanks for your fast reaction on this !

Thanks everyone for your contributions here.

A hotfix release of this fix would be greatly appreciated if possible <3

Here's a patch made from both commits fixing the issue.
Posting it in case someone needs to apply it via composer (and doesn't want to switch to dev version).

A hotfix release of this fix would be greatly appreciated if possible

Will come soon, just coordinating with a couple of other fixes here and in Gin.

Here's a patch made from both commits fixing the issue.
Posting it in case someone needs to apply it via composer (and doesn't want to switch to dev version).

@abramm Do you know that this is bad practice and you should never grab patches from d.o with composer? You should always download the patches locally and refer to them there.

@abramm Do you know that this is bad practice and you should never grab patches from d.o with composer? You should always download the patches locally and refer to them there.

I'm not seeing any problem with patches from Drupal.org. It's more a question of preference; in any case, someone could download the patch and commit it locally if they prefer.

(Using patches from d.org MRs is definitely a bad practice, though.)

I'm not seeing any problem with patches from Drupal.org. It's more a question of preference; in any case, someone could download the patch and commit it locally if they prefer.

There is no assurance that patch files do always exist on d.o - and the DA has always insisted in people not requesting patches from there. Soon, when the migration to GitLab will be completed, all the patch files will most likely be gone. That's why everybody is asked to keep their required patch files locally in the project that requires them.

There is no assurance that patch files do always exist on d.o

Well, in that case, I just hope it will live long enough until the release 😅.

That's a fair point, though.