Track the steps needed to remove extension TBA from core to contrib. See Remove a core module and move it to a contributed project of the deprecation policy.
The removal of extension Ban was approved in https://www.drupal.org/project/ideas/issues/1570102.
Postponed on any sibling issues. See the parent, #3482198: [meta] Tasks to deprecate the Ban module.
lifecycle: deprecated
lifecycle_link: https://www.drupal.org/node/3223395#s-EXTENSION
@group legacy to all tests in the extension.Ban will be listed in a note for all extensions removed.
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes, plain diff MR !11126
Comments
Comment #4
annmarysruthy commentedTests failed as ban module is used in tests. Will work on these tests as part of https://www.drupal.org/project/drupal/issues/3488838.
Comment #5
quietone commented@annmarysruthy, thanks for working to deprecate Ban. I have only glanced at the MR but it looks correct.
Instead of updating the list of remaining tasks in the a comment on the MR can you put in the Issue Summary instead. The issue summary is the first place that contributors go to in order to understand what needs to be done. And reviewers and committers like it up to date so they know what to is expected.
This issue is to be committed last in the task listed in the parent issue so I setting to 'Postponed' and I have updated the remaining tasks accordingly.
Comment #6
annmarysruthy commentedUpdated remaining tasks.
Comment #7
quietone commentedComment #8
smustgrave commentedSeems #1 create a project for https://www.drupal.org/project/ban is still needed
Also who's taking over the module? They probably should make that project.
Comment #9
mstrelan commented#8 is done, we can continue here
Comment #10
mstrelan commentedAdded a section to the docs - https://www.drupal.org/docs/core-modules-and-themes/deprecated-and-obsol...
Comment #11
smustgrave commentedYup, verified the module URL, believe this is good to go. Thanks @mstrelan for taking on this module in contrib.
Comment #13
catchAdding a tag for release notes so we don't forget to mention it but agreed this just needs to be in a list.
I can't think of anything else and the MR looks good.
Committed/pushed to 11.x, thanks!
Comment #15
ressaIt's great with all the slimming down of Drupal core, easing the maintenance burden, so thanks for that.
I saw an issue the other day, about Forum module, and how to approach switching from core to contrib. I left this comment:
From #3539397: Document how to install the Forum contrib module, and change from core.
Now, seeing another core module getting deprecated today, it occurred to me that the process is probably more or less identical every time, so could it be considered to add the basic steps to transition from core to contrib in the README's of all these Drupal core modules (Forum, Tour, Ban, etc.) which have been retired, and are now contrib? It could also be a link to a doc page, outlining the required steps.
It could be added as a new item on the to-do list for Deprecate-issues, something like "Create README, include steps to transition from core to contrib."?
Comment #16
catch@ressa there's already a Drupal.org documentation page with recommendations for every removed module https://www.drupal.org/docs/core-modules-and-themes/deprecated-and-obsolete - this is also linked from the lifecycle link in the module's .info.yml which is used for deprecation/status messages. Each module has instructions for what to do (it's usually 'add a dependency on the contributed module' with a link to the project page, which then has the generic d.o instructions on how to add a contrib module.
Comment #17
ressaThanks for a fast reply. And yes, I know that the https://www.drupal.org/docs/core-modules-and-themes/deprecated-and-obsolete page exists, but it merely lists the deprecated modules, it does not list the steps required to transition from using a core to a contrib module.
I quickly checked three deprecated modules, and as far as I can tell, they do not guide the user through the process:
This is why I suggest that we either
or
Drupal can break down if you move a module, which is why I think having a recommended list of steps will help everyone complete this task in a more or less fail safe method.
Everyone here in this issue is an old Drupal hand, but for new users, moving a module, and getting a WSOD can be extremely unnerving, and I think we should help non-veteran users out as much as possible.
Comment #18
catch@ressa the process for changing from a deprecated core module to a contrib module is the same as installing any contributed module, there's no extra process. Potentially we could document that this is the case at the top of https://www.drupal.org/docs/core-modules-and-themes/deprecated-and-obsolete but there are no special steps at all.
Comment #19
ressaThanks for sticking with me :)
Going through the steps, emulating a person without deep Drupal knowledge, if I simply run
composer require drupal/forumand rebuild caches, Drupal crashes and I get this error message:Also, the URL has changed to
/admin/flush?token=tFhchVRz3uMAVRIapVZ7fuuYGKleN2pAtd_NslMbFpI.Of course, as Drupal veterans, you and me both know that Drupal core Forum module (
web/core/modules/forum) needs to be deleted and caches rebuild. Let's simulate that the user also realizes this. If I delete the core module, I now get this error:If I refresh, I get this error:
... and if I refresh, it now repeats the first error message. Rebuilding caches makes no difference.
If I then use the settings.php method (item #4 "Rebuild caches, and possibly extra steps" in the suggested list of steps from comment #15) adding this:
$settings['class_loader_auto_detect'] = FALSE;... and refresh, I get these final messages and errors:
... and finally, it looks like contrib version of Forum is in use.
Perhaps you can check if you see something else?
Comment #20
catchIt doesn't need to be deleted, just a cache rebuild is enough.
Comment #21
ressaSo you can fix it with a standard cache rebuild? A simple cache rebuild is not enough in my case ... I need to use the settings.php trick, as seen in my previous comment.
But why is it not necessary to delete the old core module? How can Drupal know which one to use? Does Drupal keep track internally, if a contrib version of a deprecated module is present, and then it intelligently uses that instead, and ignores the core copy? If yes, perhaps a sentence about that could be added in the introduction of https://www.drupal.org/docs/core-modules-and-themes/deprecated-and-obsolete?
Comment #22
ressaYou're right! I just tried again without deleting the deprecated core module, and it does look like the deprecated core Forum module is automatically hidden on the Extend page, as I theorized.
I do still need to use the settings.php trick, a simple cache rebuild is not enough -- the files from the core module are still used.
I verified this by editing web/core/modules/forum/src/Controller/ForumController.php and tweaking line 299 to this:
'title' => $this->t('Add new MY D10 CORE @node_type', [Only after nuking caches via settings.php did it start using the contrib file.
Perhaps this could be the help text, and the recommended steps? In theory, the contrib version could get hook updates after the separation, so isn't it prudent to recommend running updates as well?
Comment #23
catchIt's because module discovery looks for modules in core/modules last after all the other possible places that modules can live.
Comment #24
ressaThanks 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:
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 modules/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?EDIT: Nope, this method does not work. Contrib Forum 1.0.2 module may be listed, even while files are used from Drupal core Forum version ...Comment #25
ressaI created #3540339: Rebuild all caches, including APCu, when clicking "Clear all caches".