🇩🇰Denmark @ressa

I now see an issue, so posted there instead.

I would like to offer to co-maintain the Managing site performance and scalability → guide.

There are a few pages that needs to be reviewed and added to the menu.

• https://www.drupal.org/docs/administering-a-drupal-site/managing-site-pe... →
• https://www.drupal.org/docs/administering-a-drupal-site/managing-site-pe... →

Also, the order of Guides could be re-ordered.

ressa → created an issue.

Moving to Managing site performance and scalability  https://www.drupal.org/docs/administering-a-drupal-site/managing-site-pe... → since that's more correct.

Wouldn't it be great to get this pushed over the finishing line? :)

Thanks @mrx576, since then I have tried many different approaches (all the ones mentioned on Block bad bots and crawlers → ) and so far Crawler Rate Limit → is by far the most efficient bot-blocker, and combined with Solr and Reddit, the bad bots are under control.

@herved: +1 to investigate if removing the JS Cookie dependency is possible, and I created 📌 Remove JS Cookie dependency Active .

ressa → created an issue.

Thanks @strykaizer, that sounds great.

Wouldn't it be nice to alert potential updaters about the current limitations? Because it's not obvious, before you are far into the update process (see my comments #31 and #35), and placing Facets in other regions is a popular feature.

Something like this could be added on the Facets project page → and documentation page, also to help get this fixed faster:

Facets 3 AJAX only above the form

It is not yet supported to place Facets somewhere else than above the form in Views (the standard) with AJAX support, since Configurable Views Filter Block → does not yet support AJAX, see 💬 Works with AJAX enabled? Active .

Please help fix the blocking Drupal core issue 🐛 Views hardcodes exposed filter block form ID's which breaks AJAX when the same form is shown multiple times on one page Needs work , or consider sponsoring developers to do this.

Perfect @dydave, I am glad to hear that the two test issues can be handled, and great that they may even get extra improvements, thank you!

I hope the Project Browser issue can get some attention, a crash is never ideal 🙂

Fantastic @dydave, very nice to see the items on the Meta issue list dwindling down, and the structure of the code improving steadily!

And I totally agree: Let's make decisions if possibly little used features should be moved out or not, before spending time documenting them 🙂 They could also have been made redundant by a newer feature, offering a superior solution, like scrollable menu or a more compact design.

About the odd "Disabled, show on scroll-up"-thing, it seems to only happen for the Drupal 11.x-dev Git-version, so I have created a dedicated issue for that.

ressa → created an issue.

Updating the Issue Summary, and listing the tasks.

Great @dydave, thanks for yet another improvement on the Admin Toolbar module!

And great thinking ahead, that the flexibility may allow connecting to other modules, for example Navigation, and others as well in the future. I really appreciate your efforts with getting Admin Toolbar, as well as Block Class in tip top shape!

Oops, already referenced :)

Both README's look really great now, and cover all important aspects of the Block Class module, thanks @dydave!

You're welcome @dydave, thanks for expanding the tests with even more coverage. And yes, it was very interesting to see the interaction with the Navigation module 😊

I have subscribed to the #3556898: Admin toolbar tools: Improve support for core Navigation → issue and will follow along, and help out if I can. Thanks again @dydave!

Thanks @dydave for yet another epic effort, for Block Class there are now only 4 active issues, very impressive!
https://www.drupal.org/project/issues/block_class?text=&status=1 →

And really great to get tests up and running! Combined with the updated documentation, new users have a much easier time deciding which version to choose. And by the way, with your admin doc permissions, you should now be able to add https://www.drupal.org/docs/contributed-modules/block-class/version-comp... → to the menu 😊
It could be placed at the top?

Thank you @dydave, it's so great to get both Admin Toolbar and Block Class in very good shape!

Thanks for clearing this up @sheetal.pathak and checking @quietone, it has probably worked all along, but the missing "Site branding block" was the culprit :)

Thanks for sharing all the progress you are making, it sounds like you are close to a solution.

Feel free to share the code here, so that other users can try it out, and check if it looks good. Also, then other users looking for the same functionality can later on also use that code.

Looks great, thanks @berdir.

You're welcome @dydave, thanks for keeping so many contrib modules in tip top shape, I really appreciate it! The Download link looks great.

And sure thing about taking a look at some of the remaining Admin Toolbar issues, I tried to review a few of them, to the best of my capabilities. I hope you make progress, while taking care to not get over-worked -- at least, there are a few issues that are Done already :)

And yes, we should get in touch and exchange contacts, I'll send you a PM!

Heh, yes keep them coming!

I took a look at the two "Remove dependency on Admin Toolbar" issues, since they were not too code heavy, and manageable for me, and also the Admin Toolbar Search Code clean-up and refactoring. The two remaining test issues are probably too demanding, and I hope you or someone else can review/finalize them, and maybe also the Project Browser issue?

Great job @dydave, thank you! Very thorough as always, and all the new comments add context, as does the expanded README's. It is a nice touch, that the Search shortcut "Alt + a" is now only shown, if it is indeed enabled.

I tried the MR as a fresh install, as well as on an existing install, and ran updatedb. In both cases everything worked as expected, and Admin Toolbar behaves as always, with the improvements, such as shortcut tip only shown when enabled. I did find a single misstep, where it seems "Toolbar sticky behavior" > "Disabled, show on scroll-up" has stopped working, I am not sure why. I tested in latest Drupal 11.x-dev, if that makes any difference.

Also, in expectation of the two "Remove dependency on Admin Toolbar" issues the "This module requires the following modules ..." could be replaced with "This module requires no modules outside of Drupal core." in the two README's?

But other than these details, all seems good 🙂

Great work @dydave! Allowing the Admin Toolbar Tools to be installed by itself as a standalone module, while being able to work together with several other modules, is a great idea. I can confirm that the Admin Toolbar Tools module can now be installed by itself. Also, it is able to extend the functionality of the Drupal core Navigation module, for example by adding the actual content types under "Structure > Content types > Article", and also the "Flush XYZ cache" options. And it still works well with the Admin Toolbar modules, as previously. I agree that sorting out details such as adding support for "Flush all caches" when used with Navigation could be a follow up task. Thanks!

This was a very interesting experience, to only have the Admin Toolbar Search module installed :)

But it works well, by itself -- though it's a bit limited, since only the eight top level menu items are available. I can then individually install the Admin Toolbar module additionally, and it works as it normally does. More granularity and flexibility is always a good thing, so thanks for raising this idea, and providing a solution as well @dydave!

Thanks @rcodina and @berdir for working on this. I have recently been trying to get Redis configured, and support for a default TTL would have helped. The MR works well, and I can now set a global TTL for all keys, which is really great.

The discussion you had here is also useful, and may help new Drupal Redis users (it helped me!) and I have tried to integrate it into the README. I also removed the bit about it being strongly recommended. I hope it's all right I updated directly in the MR. What do you think?

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

Hi @dydave -- Heh, yes to old-timers such as you and me, it may look a bit too "used car salesman"-like :) Thanks for being open to removing it!

And yes, a Download link could be nice.

I think you should apply to get admin documentation permissions, since you are involved in so many projects, and it would ease your task solving speed -- adding a new documentation Guide or Page, or editing the menu for an existing one could then be easily done. You could consider applying for getting an admin editor documentation permission globally (if it's possible) or for those projects you are involved with, where it makes sense? https://www.drupal.org/drupalorg/docs/content/documentation →

About everyday Block Class maintenance, including setting a default branch, it looks like @toddnienkerk is the only one with the "Maintainer" role: https://git.drupalcode.org/project/block_class/-/project_members

And he hasn't been active for a while, at least five years, judging from https://git.drupalcode.org/users/toddnienkerk/activity ... So maybe you could apply for the Maintainer-role? That would certainly make sense to me.

Sounds great with the update of README later, thanks!

A quick method to test a settings.php variable without creating a custom module is using the php:script command from Drush.

Add this in settings.php:

$settings['redis_perm_ttl'] = 3600;

Create a file test.php with this:

<?php
use Drupal\Core\Site\Settings;

$my_redis_perm_ttl = Settings::get('redis_perm_ttl', '86400');
echo $my_redis_perm_ttl . PHP_EOL;

... and run it like this:

$ drush php:script test.php
3600

Any feedback is probably best shared in these issues:

• 🐛 Fatal error: Declaration of Drupal\webform\EntityStorage\WebformEntityStorageTrait::__get($name) must be compatible with Drupal\Core\Entity\ContentEntityStorageBase::__get(string $name): mixed Needs review
• 📌 Revert deprecation in ContentEntityStorageBase::__get() Needs review

I agree, @dydave good calls! Both with moving the matrix to its own page, and the overall updates. Perhaps you can ask https://www.drupal.org/u/renatog → to add you as https://www.drupal.org/docs/contributed-modules/block-class → documentation admin, so you can add the new page in the Menu?

The project page also works much better now, but I do think the "📁 Download now!" looks a bit ... not so serious? Maybe it could be considered to be removed?

Also, perhaps the "Installation" step could be simplified, since Composer is the method now? From this:

2. Installation:
Install with composer or download the module and copy it into your contributed modules folder (for example, /modules/contrib/) and enable it from the modules administration page (requires the image and link modules to be enabled).
More information at: Extending Drupal: Installing Modules → .

... to something like this?

2. Installation:
Download and install Block Class as you would any other module, see Installing Modules → .

Thanks for creating the follow up issues, to streamline the 3.x and 4.x versions -- maybe into a future unified version 5? Or whatever the best solution turns out to be :)

I tried the latest 11.x-dev release today, and input fields are now centered again, so the problem has gone.

Are you manually modifying .htaccess? Because a single wrong character can make everything break down ...

It is a much safer method to patch Drupal core files with Composer:  https://www.drupal.org/docs/develop/using-composer/using-drupals-compose... →

Thanks for checking, I spent a long time to get just a basic understanding of Composer, and my take home is that precision is crucial, which was why I felt the need to double check :)

@rikibu: Great that you got it sorted out! I note that the Composer command you use is not included in the documentation, so maybe check which one to use?  https://www.drupal.org/docs/updating-drupal/updating-drupal-core-via-com... →

@daodoctrung: It could be this problem? 🐛 Fatal error: Declaration of Drupal\webform\EntityStorage\WebformEntityStorageTrait::__get($name) must be compatible with Drupal\Core\Entity\ContentEntityStorageBase::__get(string $name): mixed Needs review

Thanks for taking a deeper look into getting this module sorted out @dydave, it seems like it has been without a Captain for some periods of time, and "stuff" happened 😅

I hope that you, maybe together with @justcaldwell?, can make a downgrade path from 4 to 3 possible, in case that seems to be the best road forward ...

Awesome that you got the big picture now, and see what needs to be done for the next release! Let me know what you think about the "Proposed resolution", and if it could work, or in case you think some things need to be clarified?

Thanks for working on a solution for this task @justcaldwell and @dydave! I can confirm this bug.

I only use the Block Class module to add classes, so version 3 would work well for me, and after understanding the current V3 vs. V4 situation, I decided to downgrade manually from version 4 to version 3. Basically just uninstalling, and reconfiguring all blocks.

I hadn't taken a closer look at this issue, so did not understand what it was about. So I ran into an "interesting" situation, where some blocks without any Block Class configuration got deleted, because they had a dependency -- for some strange reason -- on the Block Class module.

I corrected it manually, by restoring everything, deleting the erroneous occurrences of - block_class in the innocent block config-files, and imported the configuration. And then I could uninstall the module, and proceed with the process, and am now on version 3 :)

After gaining a better understanding via another issue, I think the focused should be on clarifying the difference :)

ressa → created an issue.

Great feedback, thanks! I have updated the MR, and I think the README looks pretty good now.

Updating "Proposed resolution".

Yes, great to see you here as well, and thanks for giving this module some attention @dydave!

Your revisions of the project page text are great improvements already, and I have followed the other related issues you mentioned as well, so let's give this module some more attention 🙂

Fantastic, thanks @eric.vvf! I am ready to test when there's something ready :)

Thanks everyone! It's great to see that this module has multiple maintainers now. Perhaps credits can be given as well?

@eric.vvf: It feels like this is very close to completed, so wouldn't it be nice to push it over the finishing line?

Thanks for the alert about these changes in the Book module @mdranove, and for maintaining it. I just tried this Book Menu Sync module with Book version 3, and it seems to not do anything currently ...

PS. Perhaps the the "Convert" link (/admin/structure/book/convert) could be shown as a tab, next to "List" and "Settings" under /admin/structure/book?

Maybe a Documentation → link could be added on the project page under "Resources"? Thanks!

Mention How to Avoid Reinventing the Menu on a Drupal Project and  Megamenu SDC → .

Fixing wording.

Adding a moved and revised version of Comparison of Responsive Menus → previously for Drupal 7.

Update modules and install numbers.

Move from Drupal 7 to modern Drupal documentation, for further revision, and adding for example https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → .

Adding a task, to delete https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → .

Fix formatting.

Thanks for collecting the issues @dydave, and summarizing the differences between the two versions, very useful! I have tried to create a suggestion for a new "Should I use version 3 or 4?" section for the project page, based on your great summary. I also updated my suggestion about adding the ID and data attribute. What you do you think?

Thanks everyone for adding this great feature, it is indeed a huge win! And thanks @eiriksm for sharing the script. I never heard about the drush php:script command before. But it came in handy for me today, because I wanted to check if compression was enabled ...

These are the results, and I can confirm that compression is enabled by default, via the settings.redis.example.php file, and also in Valkey, which I also tested in DDEV:

I adjusted the values for these two settings:
$settings['redis_compress_length']
$settings['redis_compress_level']

First column = "Compression Length / Compression Level".

Valkey 8.1.4 (October 2025)

None:     1.20G
100 / 1: 92.31M
100 / 6: 92.28M

Redis 7.4.6 (July 2024)

None:      1.21G
100 / 1: 117.73M
100 / 6: 117.75M

Interestingly, there were no almost no difference between compression level 1 and 6. It could be due to the test-nodes being very uniform?

I got the memory usage (used_memory_human) with this:
$ ddev redis-cli INFO MEMORY | grep used_memory_human

I don't use them, but perhaps  https://www.drupal.org/project/project_browser → or  https://www.drupal.org/project/drupal_cms/ → could work?

I also found the command line scary, but eventually embraced it, and now love the automatic control you have over versions with Composer. The Drupal integration wasn't great 6-7 years ago ... but now, it behaves extremely reliably for me, and adding a patch has become routine, but of course after some practice :)

The speed at which you can try a fresh module, and not have to hunt for a specialized library, since it's probably included, is in itself also a big win.

About clearer onboarding for local Composer installation there is https://www.drupal.org/docs/develop/using-composer,  → so perhaps it is covered? Or if not, it could be added?

You're welcome! Thanks for getting it all kick started, with a positive reply and a use case, when I asked in the other issue. If no none had reacted positively, I probably would not have not spent time documenting this great module. It's amazing how far a little good will can go.

And thanks for the permission update, though the menu is still locked for me, for that page ... I do also read that it says "New pages and guides" so perhaps an already created page in fact still need admin intervention ... so perhaps I can ask you to publish it?

And yes, we still have a few more tasks on the project page, like adding a "Documentation" link on the project page, adding a bit more text about the module and a link to the Modules that embed views in fields → .

Very cool, great to see AJAX improvements! @scott_euser: Handling Views Ajax History → in a follow-up issue sounds like a good idea, and I have mentioned it in the Issue Summary.

Thanks for making me aware of the AJAX Reset issue @anybody. I in fact tried "Views AJAX History" just the other day, exactly to prevent page load after Reset or navigation back, with no luck. So since it's related, I am adding it.

I agree about removing the first "Created by" bit. Just having "This page updated 19 September 2022" would work great for me, as one metric to evaluate the project, as well as to suss out, if the project text is useful, or probably outdated.

As you write, the project may have changed significantly, or the current project may not even have any relation to the original project, but simply took over that namespace.

Other projects don't mention original creator, nor last page update:

• https://wordpress.org/plugins/cookiebot/
• https://extensions.joomla.org/extension/news-display/articles-display/la...

I did find two issues #3266262: Redesign the project page → and #3268219: 'created by' is not accurate for Abandoned Namespace modules → , and it seems like it could be a can of worms ...

It looks like PHP 8.4 is the version on Debian stable:

The current distribution of Debian is version 13, codenamed trixie. It was initially released as version 13.0 on August 9th, 2025 and its latest update, version 13.1, was released on September 6th, 2025.

From https://www.debian.org/releases/

From https://wiki.debian.org/PHP#PHP_version_by_Debian_release

Wow, that's an epic list of features @droath, fantastic! As a final touch, maybe add a link to https://www.drupal.org/docs/extending-drupal/contributed-modules/compari... → from the project page?

The task in this issue is completed, which is great. The Chart module has a lot of "How to's" under https://www.drupal.org/docs/8/modules/charts/charts-howtos-0 → and the Views Field View has Event logger: How to show most recent log entry → and How to list users, and their most recent content → .

Perhaps this module could also get a few use cases, with step-by-step tutorials on how to build them, perhaps under a new Entity Extra Field documentation Guide → ?

Adding new example  How to list users, and their most recent content → to the list.

I went ahead and created a dedicated page for the user list.

I don't have permissions to add it to the menu, probably because new pages in the Guide have been set to "Require review":

New pages and guides
  Are approved automatically
x Require review and approval to be added to this guide’s menu

Perhaps, it could be considered to relax the permissions, so that other user can also add a new page to the menu, to allow more easily creating documentation?

Thanks @droath for adding that very thorough list of  Entity Extra Field →  capabilities, it's really great.

And thanks for adding the steps to create a list of recent content from users @mortona2k. I  expanded it and moved it to a dedicated example page under  https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → and instead linked to the two use cases available.

If it makes sense a Views Field View "Core Capabilities" list (like Entity Extra Field has) would be awesome :) Unless it's already covered by the current wording?

Group into three tasks.

I included the tasks from the other two issues into 📌 Document examples on how to use the Views Field View module Needs work , so maybe it's easiest to handle all the recent documentation activity in that issue?

They are all small tasks, and many have already been completed ... So I would think it's most efficient to close this, but feel of course free to reopen, if you think it's best :)

Thanks for creating this issue, more documentation is always nice. I created the issue 📌 Document examples on how to use the Views Field View module Needs work , and have integrated this task into it, so closing here to solve it there.

Thanks for creating this issue, more documentation is always nice. I created the issue 📌 Document examples on how to use the Views Field View module Needs work , and have integrated this task into it, so closing here to solve it there.

Thanks for the links to the other issues @mortona2k, that was very helpful. I have tried to integrate them into this documentation issue, to consolidate all these documentation tasks into a single issue.

Also, it's great with the info you added on https://www.drupal.org/docs/extending-drupal/contributed-modules/compari... →

But perhaps -- as with Event logger: How to show most recent log entry → -- those steps could instead be added under a new "How to list users and their most recently edited content" documentation page?

So the text on the comparison page could be something this?

Views Field View →

Provides a views field plugin that renders a view inside another view.

Here are a few use cases, and how to build the solution, step-by-step:

• Event logger: How to show most recent log entry →
• How to list most recently edited content for the users → << CREATE THIS

This module creates a subquery for the field, so take note of performance when using with a big view.

I created an issue.

ressa → created an issue.

It seems to use /myview/* ... and I found another module https://www.drupal.org/project/page_cache_exclusion → , which might support regular expression, so I'll pursue that for now.

Actually, with the recent bot avalanche, Facets-driven sites using Facets Pretty Path → may want to allow caching of up to three facets, like /myview/color/blue/color/red/color/green but not a fourth facet.

I wonder if /myview/*/*/*/*/*/* would work like that, or if this would simply be seen as /myview/* by the module?

If it works, great, we can use that, but if not, would it be possible to add support for multiple wildcards in a path, using regular expression, or some other way?

Thanks for clarifying @prudloff. I have tried applying the MR from ✨ Make ViewAjaxResponse cacheable Active in Drupal 10.5.4 (I removed the tests, but maybe that patch will only ever work in Drupal 11?) and the MR from this issue.

I still get x-drupal-cache: UNCACHEABLE (no cacheability) as well as this in my View config file:

    cache_metadata:
      max-age: 0

...or maybe this patch does not add AJAX caching support?

These are the modules, in case they may play a role:

• Facet Range List Item 1.2.0
• Facets 2.0.10
• Facets Pretty Paths 2.0.3

Also the View is using Solr, in case that makes a difference.

Maybe I am trying to test this MR with too may parameters, and should use a more systematic approach, like this?

1. Drupal 11 plain vanilla, just Facets + this module with the patch
2. Same as above, add AJAX
3. Same as above, add Solr

Thanks @alexpott, it did cross my mind that something like that might be factor here ... so thanks for clarifying.

@strykaizer answered the question in 🌱 Facets 3.x - Exposed filters roadmap Active , so maybe close this as a duplicate, so we can keep the discussion in one place?

Clarify that you only uninstall the module on the server, if you need to delete a module.

I needed to do some Redis debugging today, and was reminded about this MR, and it helped me :)

Wouldn't it be great to complete this, since it's probably close to ready? If it would help getting this MR over the finishing line, if I added answers to the comments in your review, I'll of course do that, but I basically attempted to implement all your suggestions.

Should a browser based tool be mentioned as well under "Test your installation", or maybe it's too much?

Here's a first draft. I also capitalized the first word in the Feature list, reformatted some target + link-text into links since Markdown allows that, and added a header. What do you think?

ressa → created an issue.

ressa → created an issue.

ressa → created an issue.

Thanks for maintaining this great module!

To avoid accidentally making a patch for the wrong branch (which I have done myself countless times) is it possible to set the default GitLab branch to current Drupal (8.x), and not Drupal 7?

Sounds great, thanks for taking a look at this and even including a patch poker10. Fingers crossed it can eventually be expanded with features, such as a time-filter or similar method, to more easily see the latest 404's.

Thanks for taking a look at this and the other issue @poker10, and even including an example. I agree that having this and related Views as configuration would be the preferred method, since it would allow for more features to be included, and allow customization.

At least, there's a patch here, in the meantime, until it is possible :)

ressa → created an issue.

Another one is done :)

You're welcome @shaesen, I am glad to hear you got it fixed :)

Feel free to add [Solved] first in the title → .

You're welcome @dydave, thanks for yet another fast response and commit. Great that obsolete images were removed and CSS files refactored!

Thanks @dydave for a fast response and for creating the issue and the MR in the first place, it's so great to land another one!

Your images were really helpful, it was just that the changes between them were so small, and easily missed ...

And yes, I get max_bundle_number now 😅

But like you write, it's oddly inconsistent, and I also noticed that the looong list of Views are unaffected. So I agree, that if it adds a fair amount amount of complexity to the Search and Tools code, that removing it could be evaluated in a follow up issue. A lot of test code could also be removed I suppose, and further simplify maintenance. I left a comment about it in ✨ Bundle sub-menu maximum not honored Needs work .

I have started preparing the next round of tickets for the refactoring of module's Javascript admin_toolbar_search.js and the SearchLinks class, which should add a lot of improvements to the User Interface (UI) of the toolbar search field. 👌

Sounds good! Thank you @dydave for keep on going full steam ahead with the Admin Toolbar improvements, I very much appreciate it.

Perhaps a compact display option could also help optimize the usage of space, as a supplement?

Thank you @dydave for an excellent summary of the situation, I agree with all your considerations and suggestions.

I would guess that the majority of users don't even know what a bundle is ... they may just notice that under some menus, the number of items are limited to the maximum number, whereas under other, all are shown -- for example Views or Roles. Until a decision has been made on which solution to go for, the text could be updated, to spell out which sub-menus are currently affected, and which are not, and I created 📌 Spell it out which sub-menus are affected by Maximum number to display setting Active .

It seems that:

• The Maximum sub-menu feature adds complexity to the code
• It would require work to make it work everywhere
• Expanding and maintaining the tests as well adds extra work

... so instead of working on getting it to work everywhere, it could be considered to remove it, to simplify the code base?

Alternative solutions for handling many menu items could be a scrollable menu, or a compact display, as can be seen in ✨ Make the menu dropdown as scrollable. Needs review and ✨ Add support for compact display options Active .