🇩🇰Denmark @ressa

Thanks for clarifying @sourav_paul, it sounds great that this is not a problem in Drupal 11!

But in that case ... perhaps it does not makes sense to create a solution for Drupal 10 then, since it will become EOL in December 2026, later this year anyway, and perhaps the Status should be changed to "Closed (won't fix)"?

Fix markup.

Bold hosting providers.

For users finding this page in 2026, see https://www.drupal.org/docs/getting-started/system-requirements/hosting-... → .

Add Deploy your Drupal website from Gitlab link.

Adding Hetzner tutorial article.

Heh, learning to use the command line can be a challenging process, but very rewarding, because it's so powerful. Luckily I found add1son's amazing Command Line Basics (Drupalize.me) tutorial back in the day, and got a great intro. It's still one of the best.

About auto-installers, they usually result in a Frankeninstall ...

It seems unnerving that Hostinger's cheapest plan ($2 per month "Premium") may explode to $13 per month after a year ... or maybe you grabbed 4 years right away. https://www.hostinger.com/pricing

There is a Hostinger doc page and issue for Project Browser, maybe with some tips?

• 📌 Test Project Browser on Hostinger Active
• https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

It seems like this plan is required? https://www.hostinger.com/vps-hosting ("AI agent manages your VPS", hmm ...)

Interestingly, the best recommendation for affordable Drupal hosting for small and medium sized Drupal projects may be 7 Best Drupal Hosting Providers for High-Performance Sites from the enterprise web host Pantheon where #4 - #7 (A2 Hosting, IONOS, Cloudways, Scalahosting) might work?

For some advanced folder structure/folder-wrangling (which may be too complex) see https://www.drupal.org/docs/getting-started/system-requirements/relocate... → .

You need to share the code.

Also, it's better to learn the fundamentals, and not rely on AI:

• https://www.drupal.org/docs/user_guide/en/structure-text-formats.html →
• https://www.drupal.org/docs/core-modules-and-themes/core-modules/filter-... →

About defining $settings['file_assets_path'] = 'sites/default/files';, it should not be required, if sites/default/files is already the public files directory:

If the setting is not customized, then the files will continue to be written to the public files directory.

From the Change Record New assets:// stream wrapper for custom aggregate path location → .

See also Upgrade from 10.0.9 to 10.1.0 causes css/js problems → for more background and tips.

For Nginx users, the solution could be to complete ✨ Allow to validate Apache/Nginx configuration requirement for aggregation folder before enabling aggregation. Needs review .

Thanks for adding tip about not trying to create the fork from GitLab @charles belov. I am placing it in a tip template to highlight this important info.

Remove list of strings from the Issue summary.

I agree. Though I do see the value of having the basics listed on a single page, maintaining versions in two places is not ideal.

Thanks @charles belov, and for updating the documentation as well.

I use the Jumpstart, even though it is not recommended to use in production. In a related issue, I have made a cry for help, to include a production ready Jumpstart as well, since that would help a lot of users.

Thanks, I just meant that to make it more systematic, it might be best if you could share your opinion on the individual strings, as I listed them in the Issue Summary here:

Remaining tasks

Go through the settings strings on the page, and check if they can be improved. Either add "OK", or the new suggestion below:"

• The Admin Toolbar module provides [...]

But maybe your comment could work as well, let's see what @dydave thinks.

Actually, ideally you could create an MR, so that we can review your suggestions directly in the user interface ...

Thanks for the updates @quietone, they look great. I have added an intro and a title, to make it clearer that the main section of the page is currently mainly about that issue, and other subjects could be added later.

And thanks for adding it to the menu, I wonder if it should be placed at the top of https://www.drupal.org/docs/upgrading-drupal/upgrading-drupal → ?

Thanks for the update @timfletcher.

Well, the page is already created, so there's no need for an extra issue. But feel free to give it a look over @liam morland.

The failing tests seem unrelated ... I tried running them locally, with and without the MR, and get the same errors.

I added a new "Expand transliteration for certain characters" option on the Pathauto Settings page, could that work?

Clarify what "update" means in this context.

Heh, that's a classic, I have done it often. Every time I promise myself to verify that I am updating the right code base, before actually start making the changes :)

Many users are bound to have the same question, so thanks for raising it, and a fast answer.

I'd like to propose that we document this under Upgrading from Drupal 8 (or later) → and I created this page:

Can I skip a major version during an upgrade? →

I based it mainly on @catchs's comment in #15, feel free to edit or add extra info, if you think it's needed. Perhaps someone can add it to the menu?

Fix link in Issue Summary.

@ghost of drupal past clarified in 🐛 Danish characters ø and å are not transliterated correctly Active that this should not be handled in Drupal core, so Pathauto is probably the best bet.

I got valuable feedback from @ghost of drupal past in 🐛 Danish characters ø and å are not transliterated correctly Active , and it seems like this should not be handled in Drupal core, but Pathauto in the issue 🐛 Danish characters Active .

I have added German letters as a possibility, and it's probably easiest to handle all special characters settings for Pathauto in the same issue, so this issue can now be seen as a duplicate, and I will close it. Of course, anyone should feel free to reopen, if the they think it's not.

Updating the Issue Summary and adding a related issue. Perhaps German letters could also be included?

Thanks for sharing your insight, and clarifying that editing the data bank is probably too risky ... It's great to get sorted out, since we can then move on to find another solution.

It would then seem like this is best handled in Pathauto, by adding something like the drop-downs under Punctuation > Double quotation marks (") like suggested in 🐛 Danish characters Active , for æ, ø, and å.

So closing this issue, and hope it can happen in that other issue :)

I wasn't sure if the individual checks could be more or less critical "enough" to justify this ... but thanks for fast feedback, since I guess then, that they're not different enough to put into categories of importance, so let's close it.

Thanks for looking at this and fixing the target version, I usually get it right these days, but this one must have slipped :)

I am not sure if this issue can be categorized as duplicate ... 🐛 Danish characters ø and å are not transliterated correctly Active targets only "æ", "ø", and "å" in Scandinavian languages, whereas this issue is about German languages, where "ä" and "ü" are frequently used.

So, if "ä" and "ü" were included as well in the other issue, then this would be a duplicate, but not yet, if it make sense? I'll add a question to possibly include German language in the "æ", "ø", and "å"-issue, and update this Issue Summary with a link.

Adding question if German letters should be included, and links to related issues.

An argument for disclosing AI-generated code could be the recent MongoBleed vulnerability, where:

[...] leaked memory can contain residual data from previous requests, potentially exposing highly sensitive artifacts such as cleartext credentials, authentication keys, session tokens, or personally identifiable information (PII) that the database recently handled.

From https://www.esecurityplanet.com/threats/87k-mongodb-instances-exposed-by...

See also MongoDB is F***ed for more view points, and perspectives as related to generating large amounts of code with AI. A single and small -- but dangerous -- piece of code can get missed by both the vibe coder, but also by the code reviewer on drupal.org, and slip into production.

In fact, even using IDE's with automatic code completion could be viewed as semi-AI'ish and considered included under a disclosure-rule, since they may also suggest dangerous code. But that's probably another discussion.

Looks good! Just adding the compact issue.

Thank you @dydave! It is really quite interesting with no issues, after the release of that many changes. I think basically it is proof that having a lot of tests, which cover broadly really does pay off, by catching unintended changes elsewhere.

I totally agree with dropping Drupal 9 support, it has been EOL for more than two years after all, since November 2023: https://www.drupal.org/about/announcements/blog/drupal-9-is-end-of-life →

It's great that you have started adding issues in the next Meta issue, Thanks! ✨ Make obvious when toolbar search returning no results Active is a nice improvement. Perhaps it could be added in the new 3.7 Meta issue? The compact issue could also be added ... I'll add them, and of course , feel free to move them between "Planned" or "Nice to have" as you see fit, I'll leave that up to you :)

Thanks for the updates to the release notes (Drush commands and install), the page looks perfect now 👌 And yes, let's focus on Administration Toolbar 3.7!!

Thanks for sharing extra information about the internal structure @bkosborne -- and yes, that is one of the three workaround methods I listed in the Issue Summary.

So I know that it exists, but my whole point is that the majority of users (especially those just getting started) should not have to use workarounds for something you expect as a user:

When you click "Clear cache", all caches should be cleared, and you should get a clean slate.

You mention multisite, and for multisite installations, I think conversely, that the default ought to be a total cache clear, since 99% of installations are not multisite installations (I have added it under "Proposed resolution"):

• All caches should be cleared
• For multi-sites and similar edge cases, there could be a "Keep APCu cache" setting on the "Performance" page (/admin/config/development/performance), or simply just a $settings['keep_apcu_cache'] = TRUE; in settings.php?

What do you think about that?

Marking 8.x-1.x as unsupported and releasing 2.0.0 could work. But probably best to have a time buffer between releasing 2.0.0 (March 2026?) and marking as unsupported 8.x-1.x (August 2026?), since all maintainers for these ~20,000 installations on Matomo 8.x-1.x will then start getting email security warnings.

See 📌 False warnings about security updates Active and contrib module issues, where a version was marked unsupported, but then reverted:

• 📌 Update warning about module Active
• 🐛 No time for upgrading to latest stable release Active
• 📌 False warning about security updates Active
• 📌 False warning about Views Bulk Operations (VBO) security update Active
• 📌 False warning about JS Cookie security update Active

ressa → created an issue.

ressa → created an issue.

Perfect, it looks good now :)

@stasadev already fixed this. The high level of support in DDEV is really impressive, it must the best I have experienced, both in software, or just generally, including the real world :)

Fantastic @smustgrave! Thanks for fast answers and building a great solution. Happy New Year 🎉

That did fix the empty "Findings" for the Cron page, but the warning on the "Account Creation" page got lost.

To replicate:

1. Install the latest dev-version
2. Allow a visitor to create an account
3. Check for "Account Creation" with the module, and see "Visitors are able to create accounts."
4. Add the MR here, and see that the warning message, nor "Findings" are shown

For other checks, for example Headers, the same text is shown in both versions (and with "Findings" header after applying MR, as expected).

Maybe the new src/Plugin/SecurityCheck/AccountCreation.php file needs to get updated?

Thank YOU dydave! This is awesome, so many infrastructure improvements in a single release 🎉

Fixing that many issues, as well as tightening up the code base will reward us manifold in the future. About breaking things, I did just try an update from 3.6.0 to 3.6.3 and it went very smooth. But yes, let's keep an eye on the issue queue 😊

Thanks for creating the 3.7 meta issue, it sounds interesting with the plans for modernization.

The release note looks great! I do prefer to use either the original, words used in the GUI ("Install") or immediately understandable commands in documentation, to help beginners. I think "install" or "in" is better since "enable" is a Drupal 7 thing as I see it, whereas in Drupal 8+ we install or uninstall, since all config is nuked. So enable/disable make it sound not destructive, whereas these commands are that (if it makes sense). Put another way, "enabling" is part of "installing", but "install" also includes the adding or removal of configuration, on top of enabling a module.

It's important to discern between downloading and installing modules, they are two very different things in Drupal.

1. You download the module and its additional necessary libraries (defined in the module's composer.json file) with Composer.
2. Then you install the module either via the GUI on the Extend page, or with Drush -- the module gets enabled, changes are made to the database (the configuration), necessary folders are created, etc.

From https://www.drupal.org/forum/support/installing-drupal/2024-04-26/need-c... →

Perhaps drush en -> drush in (or install) could be considered, something like this?

The Admin Toolbar Search and Admin Toolbar Tools modules no longer require the Admin Toolbar module which will therefore need to be specified explicitly when installing the modules.

In other words, a command drush in admin_toolbar_search will no longer install the admin_toolbar module at the same time, it should be specified explicitly: drush in admin_toolbar_search admin_toolbar.

The update command could also be updated?
drush updb -> drush updatedb

... and great to hear that Matt Glaman's Generate release notes tool was useful, automate what can be automated :)

Thank you for all you are doing for the AT module!

Thanks for the heads up @jaypan, that helped me not waste a lot of time trying to understand the cryptic error message. I created a DDEV issue, since it would be nice to be able to set the version yourself in DDEV, until a new release is ready: https://github.com/ddev/ddev/issues/7993

Amazing @dydave! 🚀

Thanks for all you hard work on getting this release ready! It will surely be so much easier to expand with new features and fix things in the future, having a rock solid foundation!

Maybe you already know it, but if not, I heard about https://drupal-mrn.dev/ the other day, so just in case, I'll mention it. What a great New Years present, with a fresh Admin Toolbar release :)

Thanks again for a fast reply, it's much better now, and I don't get the errors. Also, since all paths work again, I could easily visit all pages, to check. And they all looked fine, except for "Security Review: Last Cron Run" (/admin/reports/security-review/help/security_review/last_cron_run):

A properly configured cron job executes, initiates, or manages a variety of tasks.

Findings

As the only page, it shows the "Findings" header, but without text below it ... on all other pages, the header is only shown with something listed below it, or not at all. Do you also see this?

I agree with using the blue info color, since it's not a security issue, to gently alert the developer, that they might want to check the account creation settings. I just noticed that the info text may need some punctuation marks, and added a comment. From my perspective it's ready, when the stray Twig has been removed :)

Thanks for looking at this so quickly and fixing it, it was a strange situation. I did look for an issue about the help page you mention, without luck.

Oops, removing doublet of "Make Who can register accounts? Administrators only by default" in issue Summary ( 📌 Make "Who can register accounts?" "Administrators only" by default Fixed ).

I suggested ✨ Add account creation check Active in the great Security Review module.

Thanks for clarifying, and for being open to include visitors_admin_approval in the MR. I interpreted @greggles comment (#8) to mean that, whereas allowing a user to create an account is not a direct security threat, it's similar to a "risky content" check, and so an account creation check could be included as an option.

About saying that core is knowingly allowing a security vulnerability using these 2 settings for registering accounts, I would more view them as "risky settings" where the Drupal developer should keep an eye on, and check them.

The default setting was after all changed from "Visitors, but administrator approval is required" to "Administrators only" in Drupal 11.1 via 📌 Make "Who can register accounts?" "Administrators only" by default Fixed . From that issue:

By default Drupal enables account creation (with verification)
This is no longer adequate since you will quickly get flooded by many, many, many spam accounts.
If you are going to enable anonymous account creation you need to set up several contrib modules to protect your site before you enable them.

I agree that we shouldn't introduce confusion, and I totally support adding the comment that "This is not a security vulnerability per se but more a security recommendation" at the top. Maybe @greggles can weigh in?

PS. It looks like the new "Findings" section from ✨ Make warnings or errors pop on Details page Active crept into this issue in templates/check_evaluation.html.twig :)

Add more context.

About my last comment and update of the Issue Summary, I am not really sure how or when these paths changed, I can't seem to find the changes in older versions ... So I'll update the Issue Summary.

This looks great, a clear improvement! I do get an error when I tested in Drupal 11:

Security Review: Administrative Permissions

Drupal's permission system is extensive and allows for varying degrees of control. Certain permissions would allow a user total control, or the ability to escalate their control, over your site and should only be granted to trusted users.

The website encountered an unexpected error. Try again later.

TypeError: Drupal\security_review\Controller\HelpController::title(): Argument #1 ($title) must be of type string, null given in Drupal\security_review\Controller\HelpController->title() (line 107 of modules/contrib/security_review/src/Controller/HelpController.php).

I think I had an encounter with this problem in 🐛 Some Details links give Page not found Active .

It looks like some paths were updated (like administrative_permissions > admin_permissions) and since Drupal can have a hard time clearing ALL caches (uninstalling a module + drush cache:rebuild is not enough see ✨ Support rebuild of all caches, including APCu, via the browser Active ) I guess the crufty old paths remained. A re-install of Drupal cleared out the debris, and all pages are now found :)

I first planned to close this issue with "Works as designed", or should the path updates be reconsidered, since it can result in 404 pages, unless caches are thoroughly cleared? Or a hook_update be run to thoroughly clear caches?

ressa → created an issue. See original summary → .

Thanks so much for creating the MR @Sourav_Paul. Should Drupal 11 be included in the MR for core/modules/update/src/ProjectSecurityData.php ... or is Drupal 11 handled differently?

Also, perhaps you could share how to test the new message? (Like which versions to set in composer.json)

Fantastic @dydave! This meta issue seems to be on track, and only the two test issues remain, if I am not mistaken? I'll move the two recently fixed issues, to clarify the current situation. Thanks for taking a look a those issues so quickly, I very much appreciate all your efforts with getting the module in great shape!

Thanks for taking a look at this issue, and following up @dydave!

What a nice side effect of the JavaScript refactoring in the other issue, that it is now paying dividends, with unintended but nice consequences elsewhere 🎆

I checked the dev-release, and Admin Toolbar Search indeed don't offer suggestions matching the random token string in links any longer. So yes, this issue is fixed, thanks @dydave!

I am not sure what you mean. Where was your understanding stated?

If you check the comments, and the updated summary from 19 November, the check should be if only admin can create an account.

What would be the harm in doing it that way?

But visitors can still create accounts, even if they are unapproved.

My point is that if visitors can create accounts (even unapproved) the system may still get flooded with bogus (unapproved) accounts. Also, the administrator could then get flooded with "New account created" alert emails, like this:

From	drupal11 <admin@example.com>
To	<admin@example.com>
Subject	Account details for Test at drupal11 (pending admin approval)
Date	Mon, 29 Dec 2025, 12:30 pm (667 B)
Test has applied for an account.
https://drupal11.ddev.site/user/4/edit

This can be problematic, if your email provider has set a limit of emails to send.

Maybe you can use a few more words to describe what you mean, and why we should not include visitors_admin_approval in the check?

Thanks @smustgrave, it looks great! The check works as expected, and if I switch "Who can register accounts?" from "Administrators only" to "Visitors" and run the test, I get a warning.

There are a few details.

• Hard coded date under "Checks to skip" options (/admin/config/security-review)
  The hard coded timestamp 1766869104 resulting in "Account Creation skipped by UID 1 on Sat, 27 Dec 2025 - 21:58" could be confusing ...

  +skipped:
  +  account_creation:
  +    skipped: true
  +    skipped_by: '1'
  +    skipped_on: 1766869104
  

  Is it possible for the value in skipped_on to use the current timestamp, in a fresh installation? Or bypass it in the output, if the skipped_on value is not set, and just output "Account Creation skipped by UID 1"?

• Check visitors_admin_approval as well?
  A visitor can also create an account, only it is not approved, with the setting "Who can register accounts?" > "Visitors, but administrator approval is required". So either:
  1. The warning text could be updated (adding "active") to "Visitors cannot create active accounts."
     OR
  2. The check could include creation of inactive accounts, by checking both register: visitors_admin_approval together with register: admin_only

  Personally I would prefer number 2, and check for any account creation, since flooding the site with bogus accounts can in itself be annoying, and cause trouble. I added a comment and proposal in GitLab.

• Link to doc page?
  The info text on the "Account Creation" page looks good, but we could also include a link to the Drupal documentation page, like suggested in the Issue Summary? Something like "[...]. Read more about Configuring User Account Settings → on Drupal.org.". I added a comment and proposal in GitLab.

Merry Christmas @dydave to you as well! 🎄
And no problem at all, I think you are always very quick to handle the Admin Toolbar issues. And getting the JavaScript in tip top shape with your huge efforts is amazing! Thanks for creating a follow-up issue for the 'admin-toolbar-search-ignore' feature, it's great to deal with left overs, which could perhaps get cleaned out.

It sounds like a great plan to detach Admin Toolbar Search from the Admin Toolbar module, for maximum flexibility with other modules, and interaction with them. And great that almost all issues are now done, and the next release might be close. I'll follow along in the meta issue, thank you so much @dydave!

Thanks @charles belov, these are great suggestions, and they improve the text.

But like @dydave suggests, ideally we should give the whole page a look-over, and tighten up the text strings more methodically.

I have added the strings in the Issue Summary, from the latest 3.x dev-release, maybe you can add your suggestions there? Thanks!

Thanks for taking a look at this @dydave!

I tried with a fresh install, and latest dev-versions (Drupal core from 26 dec. and Admin Toolbar from 27 dec.), and got the same result ...

I took a look at admin_toolbar/js/admin_toolbar.sticky_behavior.js, and it seems like some checks may not work as intended, because I get different outputs. Around line 34, a check is used whether to proceed or not, and the variable Drupal.adminToolbar.toggleToolbarHidden is not identical ...

I inserted alert(localStorage.getItem('Drupal.adminToolbar.toggleToolbarHidden')) on line 20 (above "Attach to the ...") and get these results:

Drupal 11.2:
null

Drupal 11 DEV:
true

Maybe the toggleToolbarHidden variable needs to be initialized, for a consistent result?

If I switch the check for from true to false, it seems to work in both Drupal 11.2 and Drupal 11-DEV:

window.addEventListener('scroll', () => {
  if (
    localStorage.getItem(
      'Drupal.adminToolbar.toggleToolbarHidden',
    ) === 'false'
  ) {
    // If the toolbar is hidden, do not execute the scroll logic.
    return;
  }

PS. I also quickly looked at the JavaScript files, and these seem to have been added since Drupal 11.2, in case it could play a role:

• /core/assets/vendor/htmx/htmx.min.js
• /core/misc/htmx/htmx-utils.js
• /core/misc/htmx/htmx-assets.js
• /core/misc/htmx/htmx-behaviors.js
• /core/modules/big_pipe/js/big_pipe.commands.js

You're welcome, and thank you for a speedy response as well @dydave, it's great to keep the momentum!

Honestly, I almost also missed the duplicate page titles, and was ready to hit RTBC, when I wanted to check something else quickly, and noticed it 😅

The new MR you created so fast works perfectly, and page titles are only shown once, as expected.

Thanks for the tip about the Front page lines. I tried it, and I prefer to include the "Front page" ("/") in the results, and vote for removing those three lines. If it simplifies things, even better! This looks good to go, thanks once again!

You're welcome, and thank you as well! And no problem at all @dydave, I am just glad I can assist with getting all your great code improvements included in the module!

It was good that you caught the misbehaving ESLINT tool, it also seems to me like npm can be a bit ... unreliable occasionally. So yeah, a fresh install is always a great idea, regularly. I should do that more often, as well 😅

And thank you so much for creating that follow up issue refactoring the JavaScript, and adding extra improvements, like showing the page title, instead of the URL -- a great little improvement. I'll take a look at the updates ASAP, it sounds fantastic that we're getting closer to the next stable release!

Thanks for another great job on improving Admin Toolbar @dydave!

Questionable features

About the questionable features, the risk could be that someone is using the "hide certain menu items in the breadcrumbs" with CSS feature, so it might be premature to just remove it ... Perhaps create a follow up issue for this?

About excluding the Front page, it seems like searching for "front" offers you /admin/index but not the "real" front page. Maybe that was the thought behind this code -- to only offer the admin front page ("/admin/index") but not real front page ("/") to admin users? My 2 cents: I would be fine with including the real front page ("/") in search results :) So it could be removed, or alternatively taken care of in a follow up issue?

Having the title in the input field rather than the URL is much better, so a great little by product of the update!

I did catch a single problem, which is that the titles of pages in the result list is shown twice ("Manage display > Manage display"):

Currently, page title shown once

MR, page title shown twice

But besides that, the patch applies well, and search works fine, just as before (with the URL to Title improvement) and there are no errors in the Console. So thanks for yet another improvement @dydave!

Thanks for the issue and a patch, maybe you can create a GitLab MR? https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →

It's great that you found the cause and a solution, perhaps one of you can create a Drupal core issue → to get it fixed? I looked, but couldn't find an existing issue. Thanks!

Thanks @dalin, this will save future MR creators from wasting a lot of time. It's puzzling to see the ghost of 1990s Mystery Meat Navigation making a come back. Hiding the "Follow issue" function ("Notification") under the three dots in the right hand side is another GUI abomination. It makes sense under mobile and small displays, but not really for Desktop ...

You're welcome @vitaliyb98, adding a Quick Start is a great idea!

But I still think my proposal of mentioning nodes and terms at the very top would be the most inclusive method to instantly convey to everybody -- both site builders and developers -- what it is capable of. The module name itself is "Entity Prepopulate" after all, so developers will already know what it's all about, I would think.

Sadly, I see quite a few modules with a very developer-centric description, and I feel they are shooting themselves in the foot, since many potential users will simply bypass it, since it's not clear how it works, or what problem it solves.

Perhaps we could do both, and both tweak the intro, plus add a Quick Start? :)

Thanks for the feedback from both of you, I attempted to update the Issue Summary, to make the support situation clearer.

Thanks for testing this patch, too bad it seems to not work ... in that case, it seems like the status should be changed to "Needs work".

It would be valuable if you shared your steps, to make it clearer where and how it fails. Like:

• I downloaded the latest version of 3.x-dev →
• I applied the patch from comment #49
• I updated the file a_file_in_the module.php with ...
• etc.

But the best would be some feedback from the other developers here who supplied patches (@dinarcon, @xpete, @hongpong, etc.) since they know best what to look out for.

I saw this Rules issue earlier today.

Connecting related issues.

I also noticed this, and found 💬 Option to Suppress Core EOL Warning in Status Report Active which also raises this issue.

On a related note, since the date under  Drupal 10 end of life → section is often what a user is looking for, should it be placed at the top of the page?

Thanks for a fast response. I skimmed the README, and the only mention of order seems to be images before Posts, under https://git.drupalcode.org/project/wordpress_migrate/-/blob/8.x-3.x/READ....

There will probably be more who wonder about this, so perhaps you can create a new issue to clarify this, and then add the answer in the FAQ page, or README, possibly under a new "Recommended order of import" section?

It seems like you both are using the Rules contrib module, so it could be this issue? 📌 doctrine/annotations is abandoned Active

Great that you got it working!

Did you already check "Documentation" and "Readme" under Resources on https://www.drupal.org/project/wordpress_migrate → ?

Thanks for the updates, since the commands seem to be working, I'll change status.

Thanks for a fast reply @fjgarlin, that sounds great, and also that there will be granular notification settings. I am looking forward to the switch to GitLab :)

I really appreciate how you share the progress under https://www.drupal.org/drupalorg/blog → , and also how you share the set up as well, so that other projects can leverage all the know-how and tools you have gathered during the process, in true Open Source sprit.

ressa → created an issue.

Thanks @batigolix, perhaps a global "Comparison of content access modules" documentation page could be considered, which all the access modules could link to?

Here are a few pages for inspiration:

• https://www.drupal.org/docs/comparison-of-contributed-modules/comparison... →
• https://www.drupal.org/docs/extending-drupal/contributed-modules/compari... →
• https://www.drupal.org/docs/extending-drupal/contributed-modules/compari... →

Perfect! Thanks for a fast response and fixing this @anybody, version 1 is again reported as supported.

I am very grateful for all the Drupal modules you all maintain at DROWL.

Thanks for maintaining this module @anybody and @grevil! Just want to alert you that the related release of JS Cookie and version support adjustment triggered a false security update warning.

Bumping up the Priority, since there are +50.000 installations → of this module on version 1.

ressa → created an issue.

Thank you @dydave, for improving Admin Toolbar again and again, it's really fantastic! I feel privileged to help (where I can) with moving all your great work along, and get it included in the Admin Toolbar module.

Thanks for taking a look a the bonus task, of the extra scroll bars :)

I tried the latest dev-release, and your solution to fixing the scrollbars of changing the spacing around the search field form elements from margin to padding works like a charm, and scrollbars no longer pop up under smaller resolutions. And yes, let's keep an eye out for future scrollbars, and deal with them in a follow-up issue.

It sounds great that fixing this issue unblocks further JS refactoring, and I will try to help where I can, and allow the next release. Thank you so much @dydave!

Thanks for the update @senzaesclusiva. It can be a bit of a challenge to isolate the cause of something breaking down. In theory, the "Take half and test"-algorithm could work, installing the first half of modules, and check if it happens, if not, eliminate the first half, and take the half of the remaining and test, etc. Of course, it's possible to test each module, if there are only twelve, but imagine there are +50 modules ...

If it turns out to be File Log, it could look something like this:

Round #1

Test first six modules. Everything works, so they get eliminated:

• Field Formatter Class
• Field Group
• File Cache
• File Log
• Media entity remote image
• Token

Round #2

Test first three modules. Everything works, so they get eliminated:

• File Log
• Media entity remote image
• Token

One of these three:

• File Log
• Media entity remote image
• Token

In case it is caused by interaction between two contrib modules, it can get complicated to isolate them :)

I also just noticed this. Should the text include the version as well, to clarify that it's referring to Drupal 10.5 and not Drupal 10? Because the current text could be understood as "Drupal 10", whereas in fact, it's referring to "Drupal 10.5".

Currently

Drupal core security coverage:
Covered until 2026-jun-17

Better?

Drupal core security coverage:
Drupal 10.5 covered until 2026-jun-17 and Drupal 10 until 2026-dec-7.

The link is still using Markdown on the project page:

For more details, see the official documentation:
[How to replace a deprecated core module with its contrib version]( https://www.drupal.org/docs/core-modules-and-themes/deprecated-and-obsol... → ).

Two new spammers:

• https://www.drupal.org/u/oliverhenry142 →
• https://www.drupal.org/u/soophie8989 →