🇩🇰Denmark @ressa

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 .

ressa → created an issue.

It looks like this issue: 🐛 TypeError Unsupported operand types int + string in Drupal\admin_toolbar_tools Active .

Moving more issues to the "Fixed" header!

I had another look at the second task ("Refactor the code for the 'menu' entity search links labels ...") and after comparing the two images, and the text side-by-side, I now see that the MR does fix this as well, so the issue is completed 🙂

Perhaps the "Structure"-missing ting, when you change "Maximum number of bundle sub-menus to display" value could be for another follow-up issue? Also, it seems to only happen with the reduced sub-menus ("3 - Configure the max bundle number to 2 [...]") and I am not sure if that was even a necessary step for this issue? But anyway, it has now been seen ... 🧐

Thanks for sharing the solution, and making me aware of the  Views Exclude Previous → module, which I never heard about before. I really should go through with my plan of checking out modules → , and watch out for small gems, like that one ...

Perhaps it's a candidate for inclusion on  What's your latest favorite module → ?

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

Thanks for the review @grimreaper :)

Just fixing tag :)

Just fixing tag :)

Thanks for looking at this one @dydave, another complex one to test :)

The first task, to show Permissions, I can confirm, the patch fixes that.

The second though ("The label for Menus Search links does not currently follow the same standard as other entity types") I am not sure ... Perhaps you can clarify the current wrong format, and the desired format?

Another observation:

"Structure" is not included as first part of the links displayed in the search field, if "Maximum number of bundle sub-menus to display" is set to "2", for example for the "Main" menu. Also, "Menus" change to "Menu". Shouldn't it always be "Menus", to reflect the actual Admin Toolbar menu items? (indented to highlight differences):

Structure > Menus > Main navigation > Add link 
             Menu > Main navigation > Add link 

Great work @dydave!

And no problem with the version, the mix up of versions happened a while ago, and it's only great to get it corrected now 🙂

About the update version, I just picked 37001, since that's the one used in the 🌱 [Meta] Roadplan for Admin Toolbar 3.7 Active issue. But using 8203 is just perfect, and least disruptive as a pragmatic solution. And maybe the version in the Meta issue title should be updated? I'll let that be up to you. Thanks!

PS. Just a detail, but for fun, I ran the Stylelint on the CSS file, and got a few "wrong order" errors

user@drupal10-web:/var/www/html/web/core$ npx stylelint "../modules/contrib/admin_toolbar/admin_toolbar_tools/css/admin_toolbar_tools.css"
../modules/contrib/admin_toolbar/admin_toolbar_tools/css/admin_toolbar_tools.css
  12:5  ✖  Expected "padding" to come before "background-image"    order/properties-order
  14:5  ✖  Expected "margin-left" to come before "padding-bottom"  order/properties-order
✖ 2 problems (2 errors, 0 warnings)

This order seemed to be the right one, it should be safe to add it without review, don't you think?

/* Replace the menu label text with the Drupal logo as an icon. */
&::before {
  box-sizing: content-box;
  margin-left: 0.25rem;
  padding: 0.125rem;
  padding-bottom: 0;
  background-image: url(../images/drupal-logo.svg);
}

Fantastic @dydave, another fixed issue, thank you!

I agree 100%, and am all about standardizing and streamlining as much as possible, to allow the maximum amount of automation and control. Handheld solutions will eventually break, or "something" happens. And reducing the amount of code is a great win as well, for less maintenance 👍

It's great with the steady progress in the issue queue, checking them off one-by-one!

You're welcome @dydave! And thanks for a thorough solution in the first place, and this follow up with a detailed description of your considerations.

I probably ran Stylelint to check if my changes were all right, because the test before my changes were also green. But the Gitlab CI Stylelint set up may be set up to be more lenient, for example to not fail, if the order is not absolutely correct? Like eslint test does now, where it seems to be set to "allowed to fail".

¯\_(ツ)_/¯

Though raising the validation level, can be considered, to also include wrong element order, it may result in an overwhelming amount of errors 😅

But interesting that VS Code seems to be more lenient ... perhaps you can give Stylelint in DDEV a try, and see if you get more feedback, if the order is wrong? And by the way, you can probably get a free PhpStorm license, if you're interested, https://www.drupal.org/drupalorg/blog/drupal-association-technology-part... → .

And yes, let's continue with the task of getting Admin Toolbar Search in better shape!

Reading the Issue Summary again, and I now realize that token browser is number #1 on the list.

Great module, thanks for making it!

Perhaps it can be made clearer that token support requires the Token module, and where to see available tokens? Inserting a token browser below the form could be considered, if it's not too much work ...

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

Adding Slack Export Viewer.

I created 📌 Archive Drupal discussions from Slack Active .

Add related issue.

Heh, yes it's a bit of a quest to find a tool which ticks all the boxes :) I created 📌 Archive Drupal discussions from Slack Active .

ressa → created an issue.

Nice, thanks for a fast review :)

Thanks for clarifying @strykaizer.

I still think my suggestion in #31 🌱 Facets 3.x - Exposed filters roadmap Active about adding a caveat in the documentation could be considered, since currently the Facets 3 AJAX filters themselves can ONLY be placed above the View, and not in the sidebar, as you could with a Facets 2 AJAX filter as a block. And that could be a blocker for many Drupal projects.

These two issues are required for Facets 3 AJAX filters in the sidebar (a Configurable Views Filter Block issue which requires a 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
• 💬 Works with AJAX enabled? Active

As I commented in the Drupal core issue, and @nod_ agreed:

This could be holding back many users from upgrading to the new and improved Facets 3, so should the Priority for this issue be raised to "Major", to help give it a nudge?

Or am I missing something?

PS: Adding related issues, to connect everything :)

ressa → created an issue.

Use composer_audit everywhere.

Remove extra div's and no ;nbsp's.

Thank you so much for sharing more details @joelpittet, I really appreciate it, because it helped me gain a better understanding, and reminded me that sending output from most Crontab commands, like hourly Drupal Cron into oblivion (> /dev/null 2>&1) is the way, but allow select messages to go through, such as if a vulnerability is detected.

So I have updated and simplified the instructions, based on your feedback. Feel free to correct any misunderstandings :)

That's a good point @smustgrave, and I have added a token example, so it's highlighted as an option. What do you think about that example?

Thanks for updating the project page @joelpittet, that helps clarify the situation. And you're right, maybe the move to GitLab will take care of the current "Recommended" gray zone-situation, and we can always revisit it, if it's relevant.

About Slack, I do understand there can be a reluctance to share a discussion. But it does show a few of the problems with Slack: Valuable discussions and information can be "garden-walled", and not found in search engines, and eventually lost. Also, users may feel that Slack is a safe, private space to share more than they normally would ... Anyway, this issue is not about Slack, so I'll stop here :)

Thanks for taking a look at the script page, I really appreciate it, as well as you sharing the script in the first place.

Fix path to views-responsive-grid.css file.

I agree, it looks great, and I have created an MR for the logo.