Deprecate the admin_toolbar_links_access_filter module

The hook introduced here ran on my site with 10.2.7 with no effect due to the condition. It won't run after I install 10.3 now, so will I have to remember to remove it manually?

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

@firewaller Yes, you'd have to remember to uninstall the module manually as part of the 10.3 upgrade.

The update hook that was introduced in this change caused a critical issue with the upgrade path for version 3.3.0 of the farmOS → distribution, which has a module that depends on admin_toolbar_links_access_filter.

By uninstalling admin_toolbar_links_access_filter via an update hook, it causes a cascade of all other modules that depend on it to be uninstalled.

We are working on putting out a new 3.3.1 release of farmOS to remove this dependency. Pull request with more information about how we discovered and debugged the issue here: https://github.com/farmOS/farmOS/pull/881

Just want to note here that the current implementation is going to cause issues in the future on sites that update admin_toolbar before they update to Drupal 10.3, once the maintainers of this project decide to delete the deprecated module from the repository, for the reason described by @firewaller above:

The hook introduced here ran on my site with 10.2.7 with no effect due to the condition. It won't run after I install 10.3 now, so will I have to remember to remove it manually?

If site administrators do not manually uninstall the module, and it is eventually removed from this repository, then they will experience "The following module is missing from the file system..." error: https://www.drupal.org/node/2487215 →

This is precisely what led to this issue going unnoticed in local farmOS testing. I updated the admin_toolbar module via composer update before I updated Drupal core to 10.3+. So this came as a surprise, and was even worse because it caused other modules that depended on admin_toolbar_links_access_filter to be uninstalled automatically.

I don't know what the right answer is here, but the update hook that was implemented is flawed for all of those reasons.

@japerry Is there a follow-up for an issue mentioned in #9 and #13? We run into the same situation. Updated the module on D10 (because there was no reason/incompatibility to prevent this and then after updating to D11, the update hook was not run again. So the module is still installed.

Agree with the above, this needs to be addressed in another way. Perhaps it's even best to put this in a seperate issue.

Postponing the update by adding an early return will cause issues with upcoming update, so not really an option. I think the best way to inform site maintainers about this issue is to add a status message to the admin/reports/status page. The context would be when the installed version of Drupal Core >= 10.3 and the modules are still active.

I created a new issue for this #15855693.