Deprecate Ban module

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

@quietone thank you, makes sense

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.

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!

@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.

Regarding of idea 📌 [Policy] Deprecate Ban module in Drupal 10 and move it to contrib for Drupal 11 Active I've added the ban reason field to the latest release of advban → module. This was the only concern I read with advban.

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

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.

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?

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

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

@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.

@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?

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.

📌 Allow to create project for ban module in contrib Active

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

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. 📌 Allow to create project for ban module in contrib Active
• 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 📌 Deprecate the Ban module Active now.

@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?

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.

Opened 📌 Ensure that Ban does not get special core treatment Postponed

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?

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