Wikipedia:Edit filter/Requested

• Task: To disallow the redirecting of public sandbox pages such as WP:SANDBOX, Draft:Sandbox and WT:SANDBOX.
• Reason: Seen multiple instances where other users redirect WP:SANDBOX to another page, which is a misuse of the sandbox. Having this abuse filter in place will definitely save some time having to revert.

--Prothe1st (leave me a message)-- 00:09, 4 February 2026 (UTC)

I was referred here by Wikipedia talk:Reliable sources/Perennial sources#Google Translate.

• Task: Warn editors against adding citations to Google Translate in article space.
• Reason: The original web page should be cited, not a machine-generated translation, and the language noted. Editors who only speak English can get their own translation if need be. {{cite web}} has fields for English translations of title and quotation, but no citation is needed for the translations, only for the original text.
• Diffs: Special:diff/1326327814, Special:diff/1326203741

-- Beland (talk) 19:06, 8 January 2026 (UTC)

Un-archiving; this request was never discussed. -- Beland (talk) 00:12, 11 February 2026 (UTC)

Bot archived it again. - Bᴏᴅʜı ***** Hᴀᴙᴩ** 17:22, 13 March 2026 (UTC)

• Task: What is the filter supposed to do? To what pages and editors does it apply?

This filter is intended to prevent the proliferation of duplicate headers like "Discussion" or "Survey" on high-traffic discussion pages (Village Pump pages, possibly also AN/ANI). Thanks to Ahecht for suggesting that this be raised here.

• Reason: Why is the filter needed?

Occasionally editors will start a discussion on one of the Village Pump subpages and create a subheader with a title like "Discussion" or "Survey", which inevitably creates navigation, linking, and editing problems when there end up being multiple identical subheaders on the page under different discussions. It should not be technically possible to create a generic subheader on these pages. If someone tries to create one, they should be prevented from saving until they change it a unique subject-specifics subheader (like "Discussion (section header)").

• Diffs: Diffs of sample edits/cases. If the diffs are revdelled, consider emailing their contents to the mailing list.

E.g., this edit adding "Discussion" and "Survey" sections at Wikipedia:Village pump (policy). BD2412 T 17:21, 12 February 2026 (UTC)

Another EFH/EFM is welcome to weigh in, but personally, I would like to see a wider consensus before a filter like this (especially if it was set to disallow, as suggested) is implemented. Firstly, the diff you linked is from over three months ago. Has this been an issue more recently? Also, would simply a header or edit notice suffice? The diff linked here is from an administrator who was certainly acting in good faith.

As the header at the top of this page mentions, filters are intended primarily to prevent abuse across a wide number of pages. Preventing good-faith formatting errors on a select few pages doesn't seem needed to me. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 02:43, 13 February 2026 (UTC)

The issue is perennial and arises from good faith edits all the time. I have also seen it recently, but usually when it starts to trip people up someone comes and adjusts the header. Of course, by then any incoming links will be derailed (and these pages have way too many incoming links to start fixing those after the fact). BD2412 T 02:49, 13 February 2026 (UTC)

I completely get that it's a problem; however, I am unsure whether or not an abusefilter is the best solution. I'll have to mull on it, or someone that actually knows what they're talking about can comment. :) - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 02:54, 13 February 2026 (UTC)

Can a filter just be a filter without being an "abuse" filter? We can pause people from saving edits without edit summaries, or from saving a redirect to a nonexistent page, without these particularly being considered abuses. BD2412 T 03:57, 13 February 2026 (UTC)

Abusefilter is the name of the extension and the technical name for a lot of stuff. The page here on the English Wikipedia is Edit Filter for just the reason you gave. It doesn't necessarily have to be for abuse.

I personally feel like this should be a fine use for an edit filter. The scope is clear and false positives not an issue. I don't think the difference between a warning and disallow should be big here since most good faith editor would presumably change the title if warned. Trialpears (talk) 12:28, 13 February 2026 (UTC)

I did a spot check on VPPR's contents over the last ~6 months. At any given point in time, there are about four sections where this might have triggered. Many of these are on the page for longer than 30 days, so I would expect such a filter to trigger maybe three times a month.

But: Most of these are RFCs, and I'd like to draw attention to a point made in WP:RFCOPEN:

• In some situations, such as when you expect an extremely high number of comments (e.g., 100+ comments) or there is no obviously relevant talk page, you may instead place an RfC discussion on a subpage of an appropriate, relevant page, such as: a subpage of the article's talk page, of a project page (or its talk page), of one of the Village pumps, or of this page. For example: Wikipedia:Pending changes/Request for Comment 2012, Wikipedia:Village pump (proposals)/RfC: Ending the system of portals, and Wikipedia:Requests for comment/Categorization of persons.

If someone is setting up ===Discussion=== subsections, then that's a sign that they probably shouldn't be posting their RFC at VPPR in the first place. Maybe the warning should instead tell them to give their discussion its own page, with instructions such as these:

• If you are expecting a normal-size discussion, you should not need "Discussion" or "Survey" section headings.
• If you are expecting a larger discussion than average, please do not post it on this page. Follow the directions in WP:RFCOPEN to create and appropriately advertise a stand-alone page.
• This page requires unique section headings. If you are adding a ===Break=== or ===Discussion=== heading, please make sure it does not duplicate any existing section headings (e.g., use ===Discussion about cake===).

WhatamIdoing (talk) 19:33, 16 February 2026 (UTC)

• • @WhatamIdoing: I agree with most of these points. As to the final one, even if there is no current conflicting ===Discussion=== heading or the like, they should always preemptively be made with some kind of qualifier, in case they end up getting archived to an archive with earlier existing headings. BD2412 T 21:28, 16 February 2026 (UTC)

    There will always be some chance of duplication, which is why MediaWiki was changed a while ago to automatically issue unique section headings. The second ===Discussion=== heading is automatically going to be #Discussion_2 in the URL, etc. WhatamIdoing (talk) 21:34, 16 February 2026 (UTC)

    I do think that it would still be better all-around if rather than an otherwise meaningless number, section headers indicated something about the section content. BD2412 T 23:32, 16 February 2026 (UTC)

    In an ideal world, section headings would communicate useful information. But we don't require that in practice. WhatamIdoing (talk) 00:04, 17 February 2026 (UTC)

• Task: The filter is supposed to warn editors who make an edit that adds a clickable link (almost certainly via a reference) to Archive.is, or any mirror (the two I am aware of are archive.today and archive.ph). It will warn editors with the text "Warning - You have added a link to Archive.today, or one of it's mirrors. That website is currently running malicious code on the computers of people who visit it. For more information, see our info page. If you can replace archive.today with an equivalent source, please do so. If you cannot, you can click "Save Changes" again to save your edit." or something similar. This filter should apply in all namespaces, although I expect it to be much rarer and somewhat less important outside of article space. This filter applies to all editors. This filter does not disallow edits, it simply warns, and probably logs.
• Reason: Archive.is currently runs code on visitor machines to DDoS a third party website when it is accessed. We are currently holding a RFC to determine what the long term response should be. Within the discussion section of that RFC, I proposed some stopgaps, among them an edit filter to warn on new additions of links to Archive.is. This proposal has attracted significant support, both explicit and implicit, and has zero opposition currently after explicitly calling for it.
• Diffs: The description "adding a clickable link to archive.is, or a mirror" is controlling. An example of an addition is here: If more examples are helpful I can provide them - there's no shortage . Note: Archive.org is a different site and not included. Tazerdadog (talk) 18:52, 16 February 2026 (UTC)

  Hello, I'm here from the relevant RfC.

  Some editors there may find your proposed wording to be non-neutral (at least some would seem to believe that "malicious code" is disingenous). It might be better to be more specific, that it's a DDoS. I think there is, so far, a supermajority of editors who agree that a DDoS is what is happening (although I might be too involved to say for sure).

  For the edit filter manager who may or may not decide to do this: please verify for yourself that the DDoS code is still live before you implement the filter, as a last minute check. MEN KISSING (she/they) T - C - Email me! 22:25, 16 February 2026 (UTC)

  A DDoS is what's happening, and DDoSing is malicious. The word malicious appears in that article three times, in fact. The problem with "it's a DDoS" is that ordinary people don't necessarily know all of the abbreviations or names for various malicious actions. What they care about is the fact that it's malicious. The exact category of malicious behavior doesn't matter to ordinary people. If you think "malicious code" is disingenuous ("lacking in candor; giving a false appearance of simple frankness; calculating") – though there's no world in which that code could be considered benevolent, so words like casuistry and hair-splitting tend to spring to mind – then we could try cyberattack, which is (a) what a DDoS is and (b) something that non-technical people would probably understand. WhatamIdoing (talk) 23:04, 16 February 2026 (UTC)

  This should be trivial to check for before flipping the switch on the filter. -- zzuuzz ^(talk) 23:05, 16 February 2026 (UTC)

  For the record, I've verified the malware is still there as of now. -- zzuuzz ^(talk) 01:33, 17 February 2026 (UTC)

  For the record, I am one of the editors who agrees that "hosting malware" is accurate, both in letter and in spirit, and I do not think "malicious code" is at all disingenuous. I am just pointing out that there exist participants in the RfC who seem to disagree, and would likely take issue with that wording. Neutrality in the edit filter notice is non-negotiable in these circumstances, given the RfC is far from finished.

  Saying "cyberattack" leaves out the important detail that it is based on code being run on the reader's device. I think it would be best to say it's a DDoS attack, and then clarify what that means. Maybe something like: "Archive.is is enacting a DDoS (Distributed Denial of Service) attack via this URL against a website they are in dispute with. Readers who click on the link and encounter a CAPTCHA page will load a script which repeatedly spams the targeted website with network requests." MEN KISSING (she/they) T - C - Email me! 23:29, 16 February 2026 (UTC)

  TLDR is one of the iron laws of the internet. To be effective, warnings should be a single (short-ish) sentence, or two at the most. WhatamIdoing (talk) 23:34, 16 February 2026 (UTC)

Seems premature given the RfC has not closed yet? Hemiauchenia (talk) 22:27, 16 February 2026 (UTC)

This is my feeling too, especially as it's unarguable there is no overwhelming consensus for any of the three options. If the RFC closes with consensus for option B, then an edit filter may be appropriate (it would presumably not be relevant if the consensus is for option A?). Thryduulf (talk) 22:51, 16 February 2026 (UTC)

I concur, I'd like to see some authority for such a filter. I see the RfC has a small bit where it says "quite a few people have seemed to be supportive". In fact, I'd prefer to see a more explicit (sectioned) discussion of the filter. We should be able to rustle up a draft filter which would log-only for the time being. We have deleted disabled filter 559 from last time, but might as well start again. There are complications to consider such as bots and people reverting page-blanking. -- zzuuzz ^(talk) 23:05, 16 February 2026 (UTC)

I think it would be a good idea to start a log-only filter. That would give us a chance to identify any errors and omissions. WhatamIdoing (talk) 23:15, 16 February 2026 (UTC)

1402 (hist · log). -- zzuuzz ^(talk) 23:40, 16 February 2026 (UTC)

I have a suggestion: we should use 559 (hist · log) instead of 1402 (hist · log) (given that 1402 is probably a duplicate of 559), in an attempt to reduce the condition count and for said filter to run faster:

action == "edit" &
!("bot" in user_groups) &
(
    link := "\barchive\.(?:is|ph|today)\b";
    added_lines irlike link &
    !(removed_lines irlike link) &
    !(summary irlike "revert|\brv[vt]?\b|und(?:id|o)")
)

Codename Noreste (talk • contribs) 04:53, 17 February 2026 (UTC)

There's room for optimisation. We might still want to check if it's a link (though probably without using added_links). We can probably also narrow the namespace scope at some point. One thing the current filter format does is to check domain switching, which is probably worth an initial look. Incidentally, this is something that User:GreenC bot is currently doing. I get the impression there are some tools still adding links to archive.today. The second filter hit references #IABot in the edit summary, and I'd find it surprising if everyone was able to find the archiveurl= parameter on their own. -- zzuuzz ^(talk) 10:08, 17 February 2026 (UTC)

If I'm reading that code correctly, we're excluding bots in this filter. The random diff I found is actually from a bot, and was the first addition I found. Do we have a sense of what fraction of new link additions are from bots? If it's significant, that might address a large portion of our issue quickly. Tazerdadog (talk) 16:37, 17 February 2026 (UTC)

I've (probably temporarily) removed bots from the filter, so we can get an idea. Talk-page archiving bots are one consideration here - they can override the spam blacklist, but can't get around a filter (and its warning). User:GreenC's bot will hit this filter as it stands. There are probably other situations with bots. -- zzuuzz ^(talk) 18:30, 17 February 2026 (UTC)

And the first two bot hits are a talk page archiving bot, and IABot (again) Special:Diff/1338868795. I'll just ping User:Cyberpower678 into this thread. -- zzuuzz ^(talk) 18:44, 17 February 2026 (UTC)

And I'll just pong you. :p —CYBERPOWER (Around) 18:51, 17 February 2026 (UTC)

I don't think that we should include bots (except for the purpose of making a list of bot ops to potentially talk to). There's not point in any bot getting this message, and we don't want to interfere with (e.g.,) an anti-vandalism bot over this. WhatamIdoing (talk) 21:23, 17 February 2026 (UTC)

Also, I think we can restrict this to the mainspace and other content namespaces. I'm not sure if others would agree with me, but I don't think it's terrible for people to post links in discussions. WhatamIdoing (talk) 21:24, 17 February 2026 (UTC)

The idea here was to get a stopgap in place while we wait for the RFC to conclude. If option B winds up being the close, presumably the filter would be set to disallow instead of warn. The points on bots and reversions are well-taken. I'd like to encourage working on that now, even if we're stuck in log only, in anticipation of a potential option b close if nothing else. I'll go fire up that section unless someone else wants to or has something to add before I do. Tazerdadog (talk) 16:43, 17 February 2026 (UTC)

The filter should be directing readers to participate in the RfC. At this point, our mission should be notification of the RfC. Unlike the last the RfC that got overturned after the wider community figured out what happened and got consensus to over turn it. If you want this RfC to stick, you need as much participation as possible. Every CS1|2 template that contains a link should be emitting a red/yellow message linking the RfC, just like we do for template deletion discussions. -- GreenC 20:59, 17 February 2026 (UTC)

Right now, the filter should be silently logging it and not bothering anyone while we figure out whether it's working the way we want it to. WhatamIdoing (talk) 21:31, 17 February 2026 (UTC)

We're not yet at the point where we can say if we (the community) want to do something, let alone what that something is. The point of the RFC is to determine that, and despite the wishes of some commenters that is not something that can be presumed. More eyes on the RFC is a good thing, but I don't think an edit filter is the best way to do that - that would (I presume) be a modification to the citation templates CS1/2 and {{webarchive}} templates (and others?) to emit a message similar to a TfD notice. Thryduulf (talk) 21:43, 17 February 2026 (UTC)

I would caution against linking directly to the RfC, as I feel it would be inappropriate notice per WP:CANVASS. The RfC is already linked in the essay that explains the situation. MEN KISSING (she/they) T - C - Email me! 03:25, 18 February 2026 (UTC)

Why do you think letting the people potentially most impacted by the outcome of the RFC, i.e. those who currently add links to archive.today, would be inappropriate? Thryduulf (talk) 03:45, 18 February 2026 (UTC)

I would think we currently have a proportionate amount of participation from editors who actively use archive.today, versus ones who do not. Notifying every single editor who actively uses archive.today would skew that proportion. The RfC has a lot of participation so far (gosh have mercy on the editor(s) tasked with closing it), and I don't think a lack of participation from people who are affected by this change is something that we should be concerned with.

Then again, all of this is coming from an editor who is fairly involved in the RfC and strongly opinionated on the matter. The same could be said for GreenC, though.

I like zzuuzz's suggestion of starting a section at the RfC where we discuss the edit filter, a section we could close earlier than the wider RfC is slated to. We could include an option for whether to include a direct link to the RfC in the edit filter. MEN KISSING (she/they) T - C - Email me! 04:53, 18 February 2026 (UTC)

It looks like we have 200 editors and 650 comments on that page. The typical RFC has maybe 5–15 editors commenting. I consequently don't think that wider participation needs to be a special goal. WhatamIdoing (talk) 08:55, 18 February 2026 (UTC)

I've switched the filter to be closer to the format mentioned above by Codename Noreste, as this is probably closer to any potential implentation. This removes the check for domain switching. Aside from GreenC's bot, there's a couple of other examples of people fixing existing links. These don't seem too numerous or relevant for the purpose of this filter, but you may decide otherwise. I've put in added_links for the time being, though this is notoriously slow. Review welcome. -- zzuuzz ^(talk) 10:26, 19 February 2026 (UTC)

Also note, this filter won't currently match someone adding an archive link to a paragraph already containing one. I believe the solution is to remove the removed_lines check and use rcount(link, added_links) > rcount(link, removed_links) (with a '(?i)') instead. This will be more thorough, but with even more performance cost. -- zzuuzz ^(talk) 10:40, 19 February 2026 (UTC)

So, so expensive (more than 20.00 ms!!!) :O Codename Noreste (talk • contribs) 15:43, 19 February 2026 (UTC)

I've tried a few different formulations, using a check for adding a new link to a paragraph already containing a link. They're all 'so, so expensive'. I'll let it run a bit as it is to get a more accurate idea, but may revert to a check for a new link only where one didn't already exist (in added_lines). Removing (or whatever) archive.today is going to be a long and multi-pronged effort, so that may be considered good enough for the filter's contribution (IMO). Unless there's any ideas. Depending on the RfC. Note, I've also extended the TLD (domain) list, based on what I can gather. -- zzuuzz ^(talk) 18:50, 19 February 2026 (UTC)

OK, I've figured out the performance issues. We're currently checking for newly added links, whether pre-existing links are there or not. We're only testing for 'normal' links, i.e. the type most people are going to use, without subdomains. Checking for subdomains is a task that can fall to someone with their performance-oriented-regex-lookaround head on. I see some people are linking to AT via another archive like this example. These are apparently distinguished by including a port number, which we're not currently checking, so they currently won't hit the filter. That's a choice to be made (and another lookaround job). -- zzuuzz ^(talk) 22:57, 19 February 2026 (UTC)

• Noting that the RfC has been closed. The closing statement is reproduced here for convenience:

There is consensus to immediately deprecate archive.today, and, as soon as practicable, add it to the spam blacklist (or create an edit filter that blocks adding new links), and to forthwith remove all links to it. There is a strong consensus that Wikipedia should not direct its readers towards a website that hijacks users' computers to run a DDoS attack (see WP:ELNO#3). Additionally, evidence has been presented that archive.today's operators have altered the content of archived pages, rendering it unreliable. Those in favor of maintaining the status quo rested their arguments primarily on the utility of archive.today for verifiability. However, an analysis of existing links has shown that most of its uses can be replaced. Several editors started to work out implementation details during this RfC and the community should figure out how to efficiently remove links to archive.today. voorts (talk/contributions) 02:04, 20 February 2026 (UTC) Tazerdadog (talk) 03:16, 20 February 2026 (UTC)

Hi all. I've made some updates to 1402 (hist · log) following the RFC consensus, did some testing, and it is now active as a disallow filter. I wasn't part of the earlier discussion, so apologies for jumping in late. voorts reached out to get this added to the spam blacklist so I started working on finishing up the abuse filter (since the spam blacklist is not the best solution for this). In addition to the existing exceptions that Zzuuzz had in place, the filter:

• is restricted to content namespaces (0, 4, 10, 12, 14, and 118)
• exempts sysops and bots (just in case)
• only blocks links to specific archives, not standalone mentions of the domains
• exempts WP:EFFPR and the Archive.today article itself
• excludes CSS, JS, and JSON (just in case)

I also added a custom message at MediaWiki:Abusefilter-disallowed-archivetoday. I think we will eventually want to add user space due to user space drafts which may be moved to other namespaces, but I wanted to hold off on that for now. Daniel Quinlan (talk) 03:39, 20 February 2026 (UTC)

There is a discussion about this filter at Wikipedia talk:Archive.today guidance#This is horribly implemented. An editor got munched on by the filter when trying to perform a merge, and then separately another editor was able to restore archive.today links using a tool whitelisted by the edit summary. The potential false negative diff is here: Special:Diff/1339699868. Is a condition like "adds x bytes or x percent to the page" to try to soften the initial issue the merge ran into technically feasable and/or wise? Was the intent of the filter to whitelist edits like that diff, or is that exception designed to do something else? Pinging @Daniel Quinlan: Tazerdadog (talk) 01:59, 22 February 2026 (UTC)

Thanks for the ping. I responded about the false negative on the other thread. Daniel Quinlan (talk) 03:02, 22 February 2026 (UTC)

The French Wikipedia decided to block archive.closed.social as well, it looks like a Chinese language instance of the same site (as a subdomain of a Mastodon group?) - might be worth doing that here too since it's a malicious website and people may feel motivated to find "workarounds" to the block. Unfortunately I don't have permission to see their actual abuse filter. That said, I only saw it being used on one page on the English Wikipedia (a file). 🔥Komonzia (message) 00:49, 25 February 2026 (UTC)

Added to the filter, thanks. They blocked it via fr:Spécial:Configuration_communautaire/BlockedDomain instead of using the abuse filter. (I didn't add archive.ec since it hasn't worked for a decade.) Daniel Quinlan (talk) 01:54, 25 February 2026 (UTC)

Some time ago I requested a filter, which to the best of my knowledge was implemented (possibly to one of the general-purpose ones). It should catch stuff like this too. JayCubby 02:14, 22 February 2026 (UTC)

I'm fairly certain that's in a private filter somewhere, probably 189. Children Will Listen (🐄 talk, 🫘 contribs) 03:10, 1 March 2026 (UTC)

• Task: Prevent disruption of the wiki interface via use of Zalgo text in edit summaries. This works by blocking edits with summaries containing six or more consecutive Combining Diacritical Marks. Legitimate use of these particular diacritics should not extend beyond around two at most per letter in normal (non-English) writing and around four at most per letter in vary particular IPA use cases. This isn't anywhere near a comprehensive protection, but it raises the bar for disruption from copy-pasting off of zalgo.org to understanding at least some aspects of Unicode.
• Reason: Zalgo text can be abused to cause edit summaries to extend far beyond their vertical location, disrupting edit history/contributions page/diffs among other things.
• Diffs: Special:Contributions/WiseInsomiac0wl as an example

!contains_any(user_groups, "extendedconfirmed", "sysop", "bot") &
summary rlike "[\N{U+0300}-\N{U+036F}]{6,}"

— chrs [talk] 03:32, 5 March 2026 (UTC)

I'm looking into this. Daniel Quinlan (talk) 06:15, 7 March 2026 (UTC)

 Done. I added this to filter 135 since it targets repeated characters. I also broadened 135 to match on more content namespaces and somewhat more users than before (based on the prefilters used by filter 614). The Zalgo detection will match in any namespace because it should be very accurate. I considered excluding Zalgo text, but it attracts disruptive edits and already has a short example. Daniel Quinlan (talk) 06:55, 7 March 2026 (UTC)

• Task: Warn users about adding A-series CSD tags to non-articles
  
• Reason: Wikipedia talk:Speedy deletion/Archive 94#Issue regarding the A-series criteria
  
• Diffs: Examples at Wikipedia talk:Speedy deletion/Archive 94#Issue regarding the A-series criteria and also see WT:SD#Speedy Deletion: Template:Country data Kokand Khanate

- BᴏᴅʜıHᴀᴙᴩ 03:47, 10 February 2026 (UTC)

Un-archived - Bᴏᴅʜı ***** Hᴀᴙᴩ** 22:30, 12 March 2026 (UTC)

• Task: Block any edit that adds the string "07907538452". Perhaps a regular expression with "[^0-9]*" between each pair of digits to prevent them from separating the digits with spaces or punctuation.
• Reason: A spammer (see Wikipedia:Sockpuppet investigations/State Bank Indian) adds this number, preceded by the word "Call" or "Contact", to financial-related articles.
• Diffs:

Largoplazo (talk) 12:10, 13 March 2026 (UTC)

I just noticed that a couple of these users have done the same thing at Simple English and Maithili Wikipedias so maybe this should be a global filter. — Preceding unsigned comment added by Largoplazo (talk • contribs) 12:33, 13 March 2026 (UTC)

Y Done. Daniel Quinlan (talk) 21:26, 16 March 2026 (UTC)

• Task: Disallow new users from creating articles over redirects
• Reason: This is quite often done to bypass AFC. Also often times done after requesting the redirect at AFC/R.
• Diffs:

NightWolf1223 <Howl at me•My hunts> 23:21, 14 March 2026 (UTC)

This was previously proposed at Wikipedia:Village pump (proposals)/Archive 206 § Proposal: extend ACPERM to IP editors overwriting redirects and Wikipedia:Village pump (idea lab)/Archive 65 § Redirect pages should not be accessible to editing by IPs or non-autoconfirmed users. My concerns still stand. We shouldn't be enticing users with an "edit" link, then telling them "nope, nevermind" after they've spent hours building a page. Suffusion of Yellow (talk) 23:42, 14 March 2026 (UTC)

We could have a default gadget remove the edit link from redirects if the user isn't logged in or autoconfirmed. Children Will Listen (🐄 talk, 🫘 contribs) 00:09, 15 March 2026 (UTC)

I'm aware the feasibility of this is inversely proportional to its complexity, but how about opening up the editing page to "Draft:" + {redirect title} and presenting a notice that, as a new user, their work will be posted in draft space? Some combination of that and autoconfirmed-protecting redirects automatically. Largoplazo (talk) 00:21, 15 March 2026 (UTC)

N Denied. This is a better topic for WP:VPI at this point, and it seems unlikely that a filter will be the best way to implement this. Daniel Quinlan (talk) 20:38, 16 March 2026 (UTC)