Problem/Motivation

Track the steps needed to deprecate the Ban module. See Remove a core module and move it to a contributed project of the deprecation policy.

The removal of extension Ban was approved in #1570102: [Policy] Deprecate Ban module.

mstrelan has agreed to maintain version 1 of the module in contrib, see #13

Remaining tasks

  1. Begin finding someone to maintain the contrib version of the extension.
  2. Move integrations implemented by other modules to the extension.
    Create child issues or child meta issues, as needed, to address the following points. Not all points will apply to all extensions.
    • Move non-migration tests to the extension. - N/A
    • Move Help Topics to the extension. - N/A
    • Remove the extension from one or more profiles.
      Used in testing_install_profile_all_dependencies #3488838: Use a test module instead of Ban in tests
    • Remove references to the extension from database dumps. Like for last major update this will be done in a single issue for all deprecated extensions.
    • Remove templates from the extension’s markup.
      • Remove templates from themes that are staying in core, leave them in deprecated themes
      • Keep skipping the template in the stable copies test.

    • For a module, handle migrations, if the module has migrations.
      1. #3488834: Remove Ban module from migration tests not in the module
      2. No changes are needed in the migrate_drupal_ui functional tests. The module is not installed and there are also no entity count tests since the blocked ips are not entities.

  3. Do a thorough search of core for any remaining references to the extension. If references are found, outside of the extension, then create issues to remove the references.
    1. #3488836: Remove Ban from help topics
    2. There are usages of 'ban' in comments in \Drupal\Core\Config\ConfigImporter::createExtensionChangelist. It is in the context of how a sort works and is not about the functionality of 'ban'. This can stay unchanged.
  4. Create the contrib project with a stable release, before the alpha version of the major release. Follow the process in Create the contrib project with a stable release for creating the sub tree split.
  5. Deprecate the core extension. #3499865: Deprecate the Ban module
  6. Update the doc page

Comments

andypost created an issue. See original summary.

quietone’s picture

quietone commented
Title: Deprecate Ban module » [meta] Deprecate Ban module
Issue summary: View changes
Issue tags: -@deprecated
Parent issue: » #3466088: [meta] Deprecate dependencies, libraries, modules, and themes that will be removed from Drupal 12 core

@andypost, thanks for starting the issue. If you like, I will setup the issues for the other planned removals.

andypost’s picture

andypost
he/him
Primary language Russian
commented

@quietone thank you, makes sense

quietone’s picture

quietone commented
Issue summary: View changes
Related issues: +#3488827: [meta] Tasks to remove Ban module
quietone’s picture

quietone commented
Issue summary: View changes
quietone’s picture

quietone commented
Issue summary: View changes
berdir’s picture

berdir
Primary language German
Location Switzerland
commented

Situation here seems a bit different/more complicated than some other core removals as there are multiple alternative modules and additions. We use it in combination with https://www.drupal.org/project/perimeter and https://www.drupal.org/project/auto_unban, which also overlaps with autoban and advban.

Should we consider to deprecate ban in favor of an existing contrib project like advban? Or do the opposite, and merge those additional features into the ban contrib project and attempt to establish a new 2.x release branch of that as the canonical solution for some of these ban features?

I'll ping a few of the current maintainers of those projects on slack.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

Or do the opposite, and merge those additional features into the ban contrib project and attempt to establish a new 2.x release branch of that as the canonical solution for some of these ban features?

That would definitely be my personal favourite!

quietone’s picture

quietone commented
Title: [meta] Deprecate Ban module » [meta] Tasks to deprecate the Ban module
Issue summary: View changes
catch’s picture

catch
he/him
Primary language English
commented

@berdir in terms of core I think a 1.x version that provides continuity with core is enough to remove it, but consolidating the various similar/extending contrib modules into a single contrib project, which could be the ban 2.x branch, sounds great.

goodboy’s picture

goodboy commented

Regarding of idea I've added the ban reason field to the latest release of advban module. This was the only concern I read with advban.

quietone’s picture

quietone commented

Asked in #core-development for someone to maintain the contrib module.

mstrelan’s picture

mstrelan commented

I don't use the ban module, but I'm motivated to assist in removing it from core. So I'd be happy to maintain a 1.x version, but would need to find others to maintain the proposed 2.x version.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
commented

I'm the maintainer of the CrowdSec module, which depends upon the Ban module, and we do have plans for moving that forward. So, I'm interested in maintaining the Ban module moving forward. Short term, I don't have much availability, but it looks like the process of managing the deprecation is already in good hands.

Just wondering, what's the plan about Drupal core's flood control as it depends upon the ban module as well. Are we deprecating flood control too?

catch’s picture

catch
he/him
Primary language English
commented

Flood control doesn't depend on the ban module - it's a core subsystem.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
commented

Oh, flood control only blocks further login attempts, it doesn't ban the IP. Thanks for the clarification.

quietone’s picture

quietone commented
Issue summary: View changes
quietone’s picture

quietone commented
Issue summary: View changes
quietone’s picture

quietone commented

@mstrelan, still interested in Ban in contrib? If so, is the contrib project created? I ask because the issue to deprecate Ban is needs review.

mstrelan’s picture

mstrelan commented

@quietone sure, if no one else wants to in the short term then I can. I tried to created the project but the short name "ban" is reserved. Any tips?

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented

The DA has prevented certain projects, including most core module names, from being created on d.o: https://bitbucket.org/drupalorg-infrastructure/drupal.org/src/6e4bceb300...

Create an issue at https://www.drupal.org/project/infrastructure linking back to here to get ban unbanned.

mstrelan’s picture

mstrelan commented

#3537047: Allow to create project for ban module in contrib

mstrelan’s picture

mstrelan commented

I now have maintainer access to the ban project in contrib. Is now the right time to create the subtree split?

mstrelan’s picture

mstrelan commented
Issue summary: View changes

OK we now have Ban 1.0.0.

FWIW I struggled a bit with knowing exactly what steps were needed for the contrib project, because core project names are reserved and there are weird namespace issues to know about. Steps should be updated something like this:

  • Create an issue in the infrastructure queue to get the project created - e.g. #3537047: Allow to create project for ban module in contrib
  • Tag a stable release, note that the project name will be duplicated - drupal/PROJECT-PROJECT
  • Once the release has been tested and core deprecations are complete, open an issue in the project_composer issue queue to fix the namespace

I think we can move over to #3499865: Deprecate the Ban module now.

catch’s picture

catch
he/him
Primary language English
commented

@mstrelan thanks for doing this.

I thought we had the steps for moving a module to contrib in a docs page somewhere, but can't find it. The problem is it happens on average about once or twice per year, but it might be worth trying to put somewhere, maybe next to the deprecation guide or similar?

mstrelan’s picture

mstrelan commented

It's linked at the top of the IS, but it only goes as far as creating the project with the subtree split, doesn't mention the namespacing issue. I can try update it tomorrow.

mstrelan’s picture

mstrelan commented
Issue summary: View changes

Opened #3539672: Ensure that Ban does not get special core treatment

quietone’s picture

quietone commented

All the steps should be at https://www.drupal.org/about/core/policies/core-change-policies/how-to-d... and that link is in the issue summary. Is that incomplete?

quietone’s picture

quietone commented

Ah, creating the infrastructure issue is in the template for the removal process. May just need to move things around.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

quietone’s picture

quietone commented
Issue summary: View changes

I updated the doc page, https://drupal.slack.com/archives/CGKLP028K/p1769125658588549

mstrelan’s picture

mstrelan commented
Status: Active » Reviewed & tested by the community

The last child issue is in, I think we can say this is done.

quietone’s picture

quietone commented
Version: main » 11.x-dev
Status: Reviewed & tested by the community » Fixed

Yes, this is all done. I have updated credit.

Thanks!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

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