🇩🇰Denmark @ressa

I am not sure ... I think the first step is to check if the documentation is correct (step#1 under "Proposed resolution") and if it is, then proceed to step #2, since the conclusion from step #1 will dictate if the commands are correct, and dictate what should be checked in step #3.

Thanks for maintaining this former Drupal core module @fgm.

I added a new section How to replace a deprecated core module with its contrib version → a while ago, to help users transition from Drupal core to the contrib version.

Perhaps modules such as Statistics, Ban, Forum etc. could mention something like this at the top of the project page, and in their README?

How to replace Drupal core Statistic module with this version

After downloading the contrib version of a deprecated core module with Composer, Drupal will automatically use the contrib version. You do not need to delete the deprecated core module. It's because module discovery looks for modules in core/modules last, after all the other possible places that modules can live.

See How to replace a deprecated core module with its contrib version → for more details.

Post-Installation

[...]

Moving to Contributed module documentation archive.

Moving to Contributed module documentation archive.

Moving to Contributed module documentation archive.

Moving to Contributed module documentation archive.

Yes, it should be deleted.

Yes, maybe we can get this page deleted?

Fix link to Installing Modules guide.

Update text for Drupal 11.

Thanks @greggles, I looked at https://www.drupal.org/docs/administering-a-drupal-site/security-in-drupal → today, and at the top I saw the outdated page https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... → -- perhaps it should be deleted?

Also, these two pages are placed at the top of that page, and in the menu:

• https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... →
• https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... →

Perhaps their weights can be removed, so they are simply inserted alphabetically?

Thanks for raising this question @mwymore, and I agree that Securing file permissions and ownership → is the authoritative page for this, so I am changing status and adding a warning at the top of the page.

Thanks for taking a closer look at this, it seems important.

I found another documentation page Preventing execution of untrusted PHP → which states that the .htaccess file in the files folder needs to not be writeable by the webserver, and added it in the Issue Summary.

Adding a link to the great  Security Review → module.

This page could use an update, Drupal 6 and CCK are mentioned, as well as other old solutions.

Adding  Cookie Bot Protection → .

Thanks for taking a look at this @o'briat. Moving the page and linking to it is a great suggestion.

Having worked with Solr, Redis, and  Crawler Rate Limit →  recently, I have come to appreciate the least number of moving parts. So I agree with your comment from September 2024, and would personally welcome a really basic example of the simplest possible Varnish set up -- using which ever module(s) could work in Drupal here, today (late 2025) -- and would be ready to try out such a page :)

For easy replication from local environment to server, if possible -- could the example use DDEV -- like, ddev ssh into it, and do the configuration from within DDEV?

My thinking is this: The closer the local example and the set up on the server are, the easier it is for the user to get started, set up and maintain it. Also, if DDEV is used, the user can experiment in a calm and safe environment.

You're welcome, the  https://www.drupal.org/documentation/manage → page is a great tool. I have added links to it from  https://www.drupal.org/drupalorg/docs/content/documentation → .

Your plan of consolidating the Varnish pages sounds like a great plan

Add link to  Documentation management →  which is a great tool. 

Perhaps one day we can #3314821: Add new Menu column and filter to Documentation management page (view) → ?

I agree -- but please do note, that this page is in the "Contributed module documentation archive" so basically, all pages are deprecated :)

ressa → created an issue.

Add delete Varnish → Guide task.

That sounds like a good idea, though I am not sure if it is already documented? There are many pages under  https://www.drupal.org/documentation/manage → if you search for Varnish ...

Also, the link is to  https://www.drupal.org/project/varnish_purge → and not  https://www.drupal.org/project/purge_purger_http →

I tried to create a "Varnish" Guide, to place several Varnish Pages under it, but got a "Menu hierarchy is not allowed in documentation." error, so a new page for purge and varnish_purge should probably be placed on the same level as this page.

Please delete this Guide, the plan was to place pages under it, but I get a "Menu hierarchy is not allowed in documentation." error.

Add tip that the Varnish → module is not Drupal 10 ready, so use the  Purge → module with Varnish purge → module instead.

Adding link to the Varnish → module.

Resetting weight, so that it's placed closer to the top.

Let' s publish the page, with a clear link at the top to the 📌 [meta] Drupal 10 version roadmap Active issue, to make the users aware that it exists, but needs assistance to get ready.

Thanks for creating this page @o'briat. Sorry it has taken a while to get it reviewed, I found it after I have become co-maintainer of this Guide.

It could be a great addition, but is it ready for Drupal 10? I see 📌 [meta] Drupal 10 version roadmap Active ...

I have been added, thanks @naveenvalecha :)

Adding page to the menu.

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 → ?