I am also sorry, since I can now see that my comment was ambiguous. But great that we are on the same page now :)
And I do agree with you, that Composer info may not belong on this page, and am actually in favour of deleting the Composer section, since:
- This page is about "Using Git to contribute to Drupal > Working with patches > Applying a patch in a feature branch" (like you noted)
- Patching with Composer is already well documented under https://www.drupal.org/docs/develop/using-composer/manage-dependencies#p... →
So maybe we can simply mention this option at the top of the page, with a single sentence something like this, linking to the doc page? I went ahead and deleted the "Composer" section, and updated the intro to this. Would that work?
You can also use the Drupal.org CLI tool to create an issue branch and apply the patch, as well as apply a patch with Composer → .
Thanks for a fast answer, but I am not sure I understand what you mean ... I merely attempted to use a local file, instead of a URL as patch, in the Composer example.
Perhaps you can clarify a bit more which changes I made, that were not to your liking? Thanks!
Thanks @briat, great additions! I think it would make more sense to use the recommended local patch file format. What do you all think about this update?
Adding example of a problem this MR fixes in Issue Summary.
That's a great method, laying out the multitude of options available to solve this challenging task, thanks!
Though I did add a caveat about blocking via .htaccess, so a link to the main doc page https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... → could be considered instead? I will attempt to keep it up to date, with the latest developments in this ever evolving space:
- [...]
- Using other modules or strategies to block or throttle bots →
- Or considering further approaches based on this blog post from @smustgrave
Oops, I forgot to add a MR back then ... It's now ready for review again :)
PS. I just re-read the great article Building a Firewall in your Drupal Application, which has an awesome list of paths for Perimeter.
Should we consider adding a doc page for Perimeter module under https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → with basic info about the module? Because then the rules from the article could also be shared there ...
Fantastic article by @smustgrave, I somehow missed it on Planet Drupal, so thanks for sharing it! I added a link to it in the Forum post, and added it to the Bad Bots doc page → as well.
I will totally use the article as a blueprint for my future strategies. I do note that @smustgrave seems to believe that switching from facets as links to checkboxes has made a difference ... I am encouraged by that observation.
About the Honeypot approach, you're right that there could be accessibility issues having hidden form fields, but then won't the Honeypot → module have that problem? I created ✨ Honeypot Facets 3 submodule? Active , let's see if it's possible :)
Add link to @smustgrave's incredible article AI Bot Abuse: Our Evolving Strategy for Taming Performance Nightmares on Drupal Faceted Search Pages and clarify that blocking individual IP addresses may not be a great idea.
Hold on, I just now checked in Facets 3, and with "Checkboxes/Radio Buttons" selected under "Exposed form > Exposed form style > Better Exposed Filters" in the View, the facets are output as actual checkboxes, not links.
So it seems like this task is already fixed in Facets 3, and can be closed?
Thanks for a fast answer, and just to be clear, I do think this module is a great addition - the other module works very differently.
It could be something like this?
There's a slight overlap with Crawler Rate Limit → , but it requires more configuration, where this module is simpler to set up.
Some block aggressive IP's manually via .htaccess → , where this module could serve as an automated alternative.
Adding
Protect Views Flood Control →
under "Block bot IPs in .htaccess
" sections as an alternative solution.
Thanks for sharing that switching from links to checkboxes hasn't really worked to prevent aggressive scraping, then I won't put all my eggs in that basket. The Ajax method sounds interesting, though that may limit some from using it ...
One thing I have noticed, is that my statistics system Matomo will not register bot visits, it seems mainly by ignoring users without JavaScript, which most bots seem to not execute, thought as they write "... but advanced bots now have the capability." https://matomo.org/faq/new-to-piwik/faq_63/
Still it might work, but the question is how to reliably block users without JavaScript.
Another approach could be using Honeypot checkboxes, where a Views exposed form could be stuffed with extra checkboxes hidden for regular users. As soon as a bot checks a Honeypot checkbox: "Bam, Banned!"
Strange how Archive.org ignores this great tool, you would think that having the module installed on potentially thousands of Drupal sites would be appealing ... I have tried to do my little bit with the https://www.drupal.org/forum/general/general-discussion/2025-01-23/whats... → Forum post.
Great that a WordPress version has been created as well -- remember to slap on a $40/month WP-fee, when it hits 500 installs :)
I thought about something else -- I fear a day in the future where archive.org is gone ... Is a belt-and-suspenders kind of feature worth considering? I created an issue ✨ Download and serve archive.org captures locally Active .
If you have web site that is older than five years, with a lot of outgoing links, chances are that many of these pages are gone or the URL changed, giving the user a "404 Page not found".
I recently had to find a solution to this problem. Checking each link one by one, and try -- and probably fail for many -- to find the new URL was unrealistic.
I had planned to use archive.org's Wayback Machine, creating "dummy" links, simply pointing to the overview page ("calendar view of all captures" with web.archive.org/web/*/https://www.fsb.dk/om-fsb/nybyggeri/tingbjerg-kulturhus/
)
But the user would then laboriously have to sift through captures, to find a good one, and I hoped to avoid this.
So I was very glad when I found the Wayback Filter → module: It automagically adds a link directly to the capture of a URL, with actual content, and not the last capture, which may in fact be a "404 - Sorry the page is gone...".
ressa → created an issue.
Add new module:
Protect Views Flood Control → - Limit how often a Views form can be submitted
Thanks for creating Protect Views Flood Control @scott_euser, the more options, the better! The bot onslaught seems to be ramping up, and previously I just banned the most aggressive bot IP's, but the past few weeks the bots are increasing in number, and most interestingly, from a multitude of IP's, making it look a lot like a DDOS-attack, and also making IP-based rules obsolete.
For sites using Facets 3, switching from links to checkboxes may help ( 🐛 [Facets 3] Render using theme input and select instead of lists with links for checkboxes and dropdown Active ) ... still, using a module like Protect Views Flood Control → may help in some scenarios, though it will of course also throttle regular users.
Adding tip that for Facets → , turning links into checkboxes may be the solution, 🐛 [Facets 3] Render using theme input and select instead of lists with links for checkboxes and dropdown Active .
I created a fresh issue, to allow creating a GitLab MR (#95 comment patch) for Facets 3:
Turning Facets links into checkboxes to block bad bots still seems like an efficient approach, and I created a new child issue, to allow creating a GitLab MR for Facets 3:
Setting to "Needs work" since taxonomy hierarchy display needs to be fixed. Feel free to add more tasks :)
Also, adding a new primary reason to implement this:
A few issues arise:
- Bots are increasingly aggressively following any links, causing DDOS-like situations, due to heavy traffic. Switching from links to checkboxes may prevent this (added Aug 2025).
Adding remaining task from parent issue 🐛 Render using theme input and select instead of lists with links for checkboxes and dropdown Needs review .
Make it clearer that authenticating with Personal access token over HTTPS is a viable option. Setting up SSH keys can be complicated, whereas using GitLab Token was a breeze.
ressa → created an issue.
I have seen an increase in traffic recently, hitting a maximum yesterday and today 🐛 Updating settings requires a cache clear Active , with Load Average hitting 97 on the server!
Interestingly, the visits now come from a varied range of IP's, so it's impossible to block them by IP, making it look like a DDOS. Maybe a new generation of multi-IP bots have been released?
So if anyone is able to do the required Git Magic → to add a GitLab MR for Facets 3 based on the patch #93 🐛 Render using theme input and select instead of lists with links for checkboxes and dropdown Needs review (thanks @damienmckenna!) it would be awesome.
CPU and traffic last 30 days.
Old posts getting re-published seem to happen less frequently, so closing this issue. It can always get reopened, if the problem resurges.
Interestingly, I have also seen an increase in traffic recently, rising the last 7-10 days and hitting a maximum yesterday and today, with Load Average hitting 97 on the server! Interestingly, a new trend is emerging: All visits come from a varied range of IP's, so it's impossible to block them by IP. I thought it was a DDOS, because it certainly looks like a DDOS .... I see no pattern in Chrome versions. Could it be that a new generation of multi-IP bots have been released?
Thanks for fixing this, I have seen it in other modules as well. It makes you wonder if saving a settings form should be default rebuild caches, except if it's disabled in the code. On the other hand, it might makes things slow down -- it's a balance :)
Thanks! Yes, it would be great to be able to exchange issue credit for money. Though a position on page #2 of https://www.drupal.org/organizations/all → may also be considered worthwhile. But mainly, it feels good to contribute to different awesome modules and have them listed under my profile, like this one now.
Thanks for explaining the magic, it's a killer feature, and great additions under "Nice to know" in the module, and on the project page. They really drive home how this feature works.
I had originally planned to just create "dummy" links to archive.org, simply pointing to the overview page ("calendar view of all captures" for example web.archive.org/web/*/https://www.fsb.dk/om-fsb/nybyggeri/tingbjerg-kulturhus/
) where the user would then laboriously have to sift through captures, to find a good one.
I hoped to avoid this ... So I was very glad when I found this module, and saw actual direct links, and thought it deserved to be highlighted, since having a direct link to an actual content page is incredible. I sincerely hope archive.org will exist forever.
It sometimes feels like there has been a "Link Killers of The World Unite" call. I have seen a business get almost wiped out, after all links were broken after a move from one CMS to another. When I called it out to the responsible developers (I arrived after the deed), it was dismissed with "You all just need to build new landing pages".
PS. It would be a badge of honour to have Wayback Filter listed as a project I have contributed to on my profile, if possible. It has gotten easier to grant credit, and can be done at any time, even after an issue is permanently closed. So a maintainer can simply check the box and Save, and credit is given.
I did a test run together with @grzegorzbartman from Droptica.com in #3521696-13: Embed fonts to comply with EU GDPR → , and it worked well, so I updated the Credit documentation page https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... → .
@mkalkbrenner, by the way @rfay replied a few weeks ago:
localhost
doesn't really work in the vast majority of situations, as explained.It's not necessary to reopen this, if you want to experiment with a PR, it's welcome.
Perhaps you can attempt to find a great solution with @rfay in the Github issue, and make Solr Host more likely to work with default settings?
Thanks for reporting and clarifying the error source and task, I am updating the Issue Summary.
It does look like the GitLab MR is pretty big, so maybe the Status should be "Needs work"?
Thanks for raising this issue @besek, there has previously been a challenge with the Polish character of "ś" and Alt+s (Option+s) as mentioned in ✨ Allow shortcut key to be configurable Active .
Would it be possible to detect the system language, and display a warning like below if Polish language is detected AND shortcut Alt + a is enabled?
It looks like your system language is Polish, which can conflict with the Admin Toolbar Search shortcut Alt + a.
Thanks for sharing @aschiwi, just connecting these two issues.
The other day I created ✨ Support rebuild of all caches, including APCu, via the browser Active , clearing the right caches can be a challenge :)
I also now notice that it says "4 followers", so if that's the three of us, it seems that most maintainers are not automatically subscribed to new localize.drupal.org issues, and have not been alerted to this issue.
Deleting non-issue related question, and move it into a separate issue.
I can't seem to select 1.2.x-dev here on drupal.org (only 1.1.x-dev) but at least the GitLab MR targets 1.2.x.
Since the https://www.drupal.org/community/contributor-guide/reference-information... → doc page was originally based on https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... → it could be used for inspiration ...
Perhaps you could consider reaching out to some of the https://www.drupal.org/project/localizedrupalorg → administrators via the Contact tab on their profile page, since an individual language could be considered a "sub-project"? :)
Perfect, thanks for maintaining this great module!
I tried moving and adding different characters in different fields ("/", ".", etc.) but still got the long word warning. Eventually I reset the processors, but happened to have also changed the order of processors into the below, which seems to have made the long word warnings go away. Search (even inside URLs) and Autocomplete seem to work as expected ("Preprocess query" has the same order):
Preprocess index
- HTML filter
- Tokenizer
- Ignore case
- Transliteration
- Ignore characters
[...] using a dedicated field just for autocompletion, indexed in the desired way, is usually the way to go.
Thanks for sharing that tip @drunken monkey, you're right -- that was also the solution for me, when I had trouble getting it to work.
I added a new "Suggestions with special characters" section on this doc page:
https://www.drupal.org/docs/8/modules/search-api-autocomplete/getting-st... →
Add "Suggestions with special characters" section, see 💬 No suggestions with special characters like accent Fixed .
Remove Views Help page text from Issue Summary, since it is in the MR.
Thanks @oily for adding test coverage, it's a big help.
@smustgrave: Using the Help page is a great idea, and I have added it in the Issue Summary as well as MR, and demoted the Status page suggestion. We could expand it, and link to it from the Views path field description text? Or maybe it's fine as it is ...
@khiminrm (12 Feb 2025):
When exposed form in block, all attributes including classes are moved from the form to the block.
It looks like custom classes are not output for an exposed form in block, and I created an issue.
This would still be a great feature, and I hope the maintainers will consider it.
Adding link in Issue Summary about a single underscore in a class name.
Interestingly, the error message and the regex are in conflict -- the error text states that underscores are not allowed, yet is included in the regex as an accepted character. I also found the reason for the behaviour, and updated the Issue Summary.
Thanks for fast feedback, it's really great that issues can maintain their momentum. I have changed the category to bug, and added some more tasks.
Thinking more about this, wouldn't it be great, if Drupal listed reserved paths somewhere, perhaps on the Status page? I have added a proposal in the Issue Summary, what do you think?
I clicked around and found /admin/help/ah
("Extensions with help available") which lists all the modules which has a README.md file, which are most by now.
It would help if there was an obvious link to this page, both on "Extend" page and when you install it with Drush, and I have added:
Describe where you as a user can see it in effect: Add "Help" link which points at
/admin/help/ah
("Extensions with help available"), next to "Permissions" for "Advanced Help" on the "Extend" page (/admin/modules
).
It seems like this module now mainly is for rendering Markdown files, if present. I.e., it does not currently enhance the user interface with popup/question-marks for user interface elements, is that correct??
Yes, the project page could do with an update, it also says "Drupal 98 and later: Help Topics and Tour".
Overall, it would be great with some documentation about this module in modern Drupal, and I created 📌 List modules which support Advanced Help framework Active .
Thanks for clarifying that @anicoto. In case you used the doc page to edit a GitLab MR, and it worked for you, feel free to change status to "No known problems" :)
I have now created a patch with #79 and patched Drupal 10.5.1 with it. It went well, and I can create a Menu item for a Search API View with many Facets:
$ composer install
[...]
- Applying patches for drupal/core
assets/patches/3106205-length-menu-tree-too-short-10.4.x-79.patch (3106205: Length of menu_tree.url and menu_tree.route_param_key are too short (255 characters) https://www.drupal.org/project/drupal/issues/3106205)
$ drush updatedb
-------- ----------- --------------- -------------------------------------------------------------------------------------
Module Update ID Type Description
-------- ----------- --------------- -------------------------------------------------------------------------------------
system 10401 hook_update_n 10401 - Update length of menu_tree fields url and route_param_key from 255 to 2048.
-------- ----------- --------------- -------------------------------------------------------------------------------------
┌ Do you wish to run the specified pending updates? ───────────┐
│ Yes │
└──────────────────────────────────────────────────────────────┘
> [notice] Update started: system_update_10401
> [notice] Update completed: system_update_10401
[success] Finished performing updates.
I skimmed the interesting issue 📌 Handling update path divergence between 11.x and 10.x Fixed (a long discussion about numbering upgrade hooks) and added it to the update hook doc page → .
I also added link to the doc page in the Issue Summary.
Add link to 📌 Handling update path divergence between 11.x and 10.x Fixed for background about numbering upgrade hooks.
Thanks for reporting this. It looks like 🐛 Length of menu_tree.url and menu_tree.route_param_key are too short (255 characters) Needs review fixes it, but feel free to reopen, if your issue is about something else.
You're welcome :) But looking at the patch, there are many changes ... Maybe you can try the MR in a fresh Drupal 11 installation, and verify if it fixes all the problems, and leave a comment in the issue? (DDEV is great for this)
When things break, it's usually because new code and features are added, or old code removed. But if there were no changes, Drupal would become irrelevant, so change is necessary. I have had multiple patches (core and contrib) in my projects, but over time, most of them got implemented and rolled out, and the patch became irrelevant :)
It looks like this issue? 🐛 [regression] Class is not added to MediaLibrary dialog Active
Thanks for the link @handkerchief. My problem was also caused by updating a View menu tab set up, and only changing it half way, and I left a comment in the other issue.
Thanks for linking to this issue @handkerchief from 🐛 Cannot redirect to an empty URL Needs review , and @lthomasen sharing your scenario.
I also ran into this after updating Menu settings in a View, in the process of not using Tabs with a "Parent menu link", after letting go of the difficult menu tab set up → .
The only way I could access the front page was disabling "Global redirects" > "Enforce clean and canonical URLs" in the Redirect module.
After changing to a standard "Normal menu entry" in the View, all is well again, and I can again enforce clean and canonical URLs with the Redirect module.
This map looks great, and would be a nice addition.
Is it worth considering adding Carto Vector as well? https://console.tracestrack.com/vector-explorer
The format looks different though, so maybe it's not possible? https://tile.tracestrack.com/v/maps/carto/style.json?key=APIKEY
First of all, I need to emphasize, that I am extremely grateful for your fast and investigative questions, I feel quite privileged.
So I am sorry if I sounded irritated, when I asked the question, which I am definitely not -- I just don't know anything at all about the inner workings of Composer, Symfony, autoloaders, etc. since I am not a developer, but a simple site builder.
My approach here is trying to report down from the Drupal trenches, trying as best as I can to investigate, and try out different things, in an actual "regular user" scenario (i.e. using recommended project in DDEV with plain vanilla settings, meaning default caching, no configuration tweaks, etc.)
So when I asked "Like, how do you suggest ...", my point was simply this:
How does this new method in actual effect differ from adding $settings['class_loader_auto_detect'] = FALSE;
in settings.php
? Because editing settings.php
is what I want to avoid ...
But it's interesting :) So I have now tried adding a dummy $settings['deployment_identifier'] = "forum_102";
in settings.php
and rebuilding caches, and it works equally well as setting class_loader_auto_detect
, so now there are two methods.
core/rebuild.php
or update.php
do not clear caches
Browsing core/rebuild.php
nor update.php
clears the caches, and so far only class_loader_auto_detect
or deployment_identifier
in settings.php
has worked.
Also, I have noticed that after getting everything set up for test, you need to rebuild the caches while the core (or original module) is the only one present, before proceeding with downloading contrib version and clearing caches -- I guess to populate the caches?
Otherwise, you might check the /forum/1
path, download contrib, clear cache, and then contrib code will be in effect.
I have updated the Issue Summary with a reproducible method, which yields the same stale caches result every time. I first tried using DDEV's snapshots feature, but it looked like the caches were not totally emptied.
Perhaps you can give it a shot, and check if you see the same thing that I do? Feel free to ask, if anything in the process is unclear.
I have now added a new Setting number for custom update hook → section, it would be great if someone could review it, and make sure it's not wrong? Thanks!
Thanks for confirming @uccio. I have updated the commands, and also added a new "Setting number for custom update hook" section, perhaps you can review it, and check if it makes sense? Thanks!
Stuffing a name in everywhere, asking non-sense questions is usually reputation spam:
- https://www.drupal.org/forum/general/general-discussion/2025-07-10/reput... →
- https://www.drupal.org/docs/administering-a-drupal-site/troubleshooting-... →
The account and its posts should be deleted.
About using a single underscore in a class name, I can't seem to find a statement where it's explicitly stated that this is not allowed, and will be replaced with a dash.
I found an issue about it, and perhaps it can be used to either allow a single underscore, or document that it's not?
Adding suggestions for help text in Issue Summary, in case it's the intended behaviour.
You're right @mlncn, a single underscore is changed into a dash in Views classes in Drupal 11, and I just updated an issue about this. It looks like it's intentional, and not a bug, so documentation is perhaps the solution?
This bug seems to still exist in Drupal 11, and since Drupal 7 is EOL, I am updating the version.
Mention 📌 Use a better container cache key Active in the Issue Summary.
Yes, the 📌 Use a better container cache key Active issue will probably take care of stale APCu cache-related problems, since Composer should then also clear the APCu cache, after a contrib project is added or removed.
If you cannot restart the web server to clear APCu caches, the other alternative is to add $settings['class_loader_auto_detect'] = FALSE;
in settings.php
and rebuild caches.
From https://www.drupal.org/docs/administering-a-drupal-site/troubleshooting-... →
Thanks for your thorough Issue Summary @ekes, and for guiding me to the 📌 Use a better container cache key Active issue, I would never have found it without your help :)
In fact, I think it could be worth considering to add parts of this Issue Summary to the container cache key issue being worked on, to add some context. Or we can hope that people searching for a solution to the APCu cache challenge finds this issue, and get guided to it?
Thanks for working on this, it sounds like it may help clear APCu caches, after switching from using a deprecated core module, to its contrib replacement?
Adding a few related issues, with examples of the problems a stale APCu cache can result in.
I ran into a stale APCu cache challenge after switching from a deprecated core module to its contrib replacement (Forum). Drupal continues to use the core module files, even after a standard cache rebuild ( ✨ Support rebuild of all caches, including APCu, via the browser Active ) and I found this issue while searching for hints.
@joachim:
Shouldn't Composer clear the apcu cache whenever the composer.lock hash changes?
That would be wonderful, but seems to be not active ... otherwise, I believe the module paths would have been refreshed automatically.
PS. About clearing APCu cache:
@longwave: [...] you need to also clear your APCu cache - the easiest way to do this is to restart your webserver or PHP-FPM.
Since not everyone has permissions to restart their web server, adding the string settings['class_loader_auto_detect'] = FALSE;
in settings.php
and then clearing caches may also get rid of the old paths cached in APCu, see
How to fix The following module is missing from the file system... warning messages > You moved the module inside your Drupal installation →
.
Adding Composer issue about APCu cache.
Thanks for the link @cilefen. I am not sure if it could help. Like, how do you suggest it should be used to solve the task outlined in this issue?
My aim is to make it easier to clear all caches without editing settings.php
, but simply by visiting an URL, or some other "one step" action, like clicking a button, issuing a command on the CLI, etc. and I have updated the Issue Summary to make this clearer.
I found a comment in another issue #3492523-41: Class "Doctrine\Deprecations\Deprecation" not found → which looks really interesting:
Shouldn't Composer clear the apcu cache whenever the composer.lock hash changes?
That would take care of the stale paths after switching from a core to a contrib module, since composer.lock
will have changed.
I created ✨ Support rebuild of all caches, including APCu, via the browser Active .
Connecting the issue which triggered this issue.
Like @wombatbuddy suggested, it would help him make a much more precise suggestion, if you shared a simple use case:
https://www.wrike.com/blog/what-is-a-use-case/
Just a single sentence is probably enough, like "When the user does X, Y should happen".
By the way @larowlan, to verify this, I use DDEV with a fresh Drupal 10 instance, install Forum, and then simply download drupal/forum, and do the rest of the steps. Just to clarify that this is not an existing installation, but a plain vanilla instance.
Thanks for clarifying @catch, I looked for a documentation page about module discovery hierarchy and behaviour, but didn't find anything. It seems to be an undocumented feature:
By design, Drupal allows multiple copies of a module in different directory spaces (eg one in /core/modules, one in /modules, one in sites/all/modules).
However, if duplicate copies exist in the same space, this works too, though I assume this is by accident rather than by design. So for example if I have:
- sites/all/modules/foo
- sites/all/modules/contrib/foothen the first one is taken by Drupal, and the second one is simply ignored.
However, because this behaviour is undocumented, it effectively puts the codebase in an unstable state: a developer doesn't know which module is being used by Drupal without inspecting the system table.
From #2647388: Don't allow duplicate modules in the same directory space → .
I have added a new section "How to replace a deprecated core module with its contrib version" https://www.drupal.org/docs/core-modules-and-themes/deprecated-and-obsol... → trying to summarize the findings here, and steps required.
Though, thinking more about this, a user who does not clear caches via the settings.php trick may in fact still be using files from core/modules/forum, even if contrib/forum is downloaded. Perhaps checking on the Extend page if Forum module is listed or not under "Core" modules section could serve as a method of verification, since the module path cache have probably then been refreshed?
Since my comment, I have realized that rebuilding caches more thoroughly than with the standard methods (like with drush cache:rebuild
) may be required. Deleting the old core module, however is not a requirement.
I have added a new section "How to replace a deprecated core module with its contrib version": https://www.drupal.org/docs/core-modules-and-themes/deprecated-and-obsol... →
Though, thinking more about this, a user who does not clear caches via the settings.php trick may in fact still be using files from core/modules/forum, even if contrib/forum is downloaded. There's no real way to tell if one or the other is in use, as far as I can tell ...
Or, I guess visiting the Extend page and checking if Forum module is listed or not under "Core" modules section could work as a method?
Does that make it clearer what needs to be done @freelylw? Like @larowlan asked, can you see drupal/forum
in the composer.json file? Is Forum module listed or not under Core modules on the Extend page? (Ideally it should only be included as a standard contrib module)