Modules remvoed from core are display on 11.x

Did you get there because you crafted the URL or because it was linked from somewhere else?

I entered 'api.drupal.org' which went to 'https://api.drupal.org/api/drupal/11.x'. I then used the search, such as,, 'forum.info.yml'.

Yeah, if you type exactly what you want, it will be there. When we reparse, we update existing pages and create new ones, but do not remove old pages that become orphaned.

I believe that this behaviour has been the same since the D7 days, anything removed from the codebase stops being linked from places, even tho the page still exists.

Implementing this removal would mean scanning all elements (not just files, it should be files, classes, namespaces, functions, constants...) and see if these are in the codebase somehow.

Possible solutions:
1. Add an "updated" field everywhere, and always update the timestamp on "git pull + re-parsing" (even when there are no changes to the file). That way we could clean up older entries for a particular branch.
2. Remove everything for a branch (aka delete branch) and recreate it. This process can take a few hours and the site won't show information in the meantime.
3. Implement some sort of "isInCode" function, that determines whether an element is being currently used in the code and then remove it if it is not found in the code. This could be a background job.

Note that 1 and 3 mean "removing" entries, and with these, we'd also need to remove all the possible related relationships to the entry in other tables.

None of the above are easy/quick/ideal, but I wanted to put my thoughts there anyway.

https://git.drupalcode.org/project/api/-/blob/7.x-2.x/api.update_branch.... looks like where files were removed in D7. Looks like the general flow was:

• Make a list of current files
• Make a list of previously-parsed files
• When processing current files, remove them from the list of previously-parsed files
• Remove anything left in previously-parsed files, starting with removing the items parsed from them

I’d do that again, or possible solution #1

Oh cool, that was totally missed in the porting of the project.

That logic sounds good. The parsing logic changed a bit between D7 and D10, but I think we should be able to pull a before/after of files, and then trigger a delete for the old files no longer present (we'd need to check relationships and dependant elements derived from the file).

Changing to Critical because this is a "Significant regressions in user experience, developer experience, or documentation".

There is an attempt at removing orphan entities: https://git.drupalcode.org/project/api/-/blob/2.x/api.module?ref_type=he...

It's probably not configured. So we should try this first.

ghost of drupal past → made their first commit to this issue’s fork.

To sum up a very hard and long debug session: On DocFile::delete needs to remove all the docblocks for the file being deleted but this creates another bug because DocBlock presumed DocFile::delete doesn't clean up so that delete call needed to be removed.

Made some comments in the MR.

Feedback was addressed. Code looks good. RTBC.

Tests are failing. Small detail that I forgot to check.

Missing file added and tests are green now.

Merged. Thanks.

Automatically closed - issue fixed for 2 weeks with no activity.

I checked today and the link in the Issue Summary still shows the action.info.yml file for 11.x. And so is forum, https://api.drupal.org/api/drupal/core%21modules%21forum%21forum.info.ym...

My bad, the code is deployed but I never changed the settings so it starts deleting them:

I will adjust the settings and deploy the new configuration.

I've changed the value now. I will revisit this by the end of the week to see if the old entries were removed.

I can guarantee it works. I set the value to 5 instead of 50 and it pretty much wiped out all the api site data.

It's bein regenerated now.

I checked again today and I could not find references to removed extension files in 11.x

Thanks!