Anyone want to put in another argument to override this check please? Sometimes these are on places like WP:IANB - and it would be useful to enqueue the request to the report and category. — xaosfluxTalk23:17, 1 November 2021 (UTC)[reply]
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
When an edit request is either answered or not answered AND the parameter used in the underlying wikitext for that particular request is |ans= and not |answered=, the texts in the two boxes currently say:
(when not answered:)
[...] To request that a page be protected or unprotected, make a protection request. When the request has been completed or denied, please add the |answered=yes parameter to deactivate the template.
(when answered:)
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
I think they should be changed to say:
(when answered:)
This edit request has been answered. Set the |ans= parameter to no to reactivate your request.
(when not answered:)
[...] To request that a page be protected or unprotected, make a protection request. When the request has been completed or denied, please add the |ans=yes parameter to deactivate the template.
I think that when the |answered= parameter is set to yes, the icon should represent the level of protection instead of just being the default "Information" icon. This would have a few advantages:
It makes it easier for future editors to see the level of protection of the page at the time the request was created, as it may differ from the current one.
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
It also reduces banner blindness. Any icon that's different from the default icons helps with banner blindness and will make custom-made information notices for a single page stand out more. That's why we have icons in the first place.
It wouldn't be confusing, since the small version is evidently less prominent compared to the full version. The text also helps. Together, the text and the icon clearly convey both what happened to the request, and the level of protection.
It reminds participants of ER discussions of the current protection level for the page, especially if the request was answered recently.
Because in the past it wasn't possible to detect the protection level. Once it was, the templates got partially merged, but not fully as IIRC there were still some corner cases. Anomie⚔15:00, 15 November 2025 (UTC)[reply]
There's no point, it's needless bureaucracy. When we merge templates, we leave redirects behind, so that old revisions of transcluding pages don't break, and we rarely invoke modules direct from articles - there's usually a wrapper template. {{TPER}}, {{FPER}}, {{EPER}}, {{SPER}} and {{IPER}} are all wrappers for Module:Protected edit request, so they're essentially merged already. In most cases, you can in fact use them interchangeably (even IPER); try going to the talk page of a fully-protected page such as Talk:Biryani, add two or three of these (different ones) and preview without saving - you'll see that there is no difference between the outputs. --Redrose64 🌹 (talk) 15:21, 15 November 2025 (UTC)[reply]
There's no point, it's needless bureaucracy There is, actually.For example, just the other day, I had used {{FPER}} to ask for an edit to a FP page. I posted the request on a semi-protected page and I specified the page in my comment, not in the template. And I didn't check the output because i knew I had used {{FPER}} so obviously it would show the FP banner, why wouldn’t it?Then a poor editor saw that the banner actually said "semiprotected" and marked it as done because "i could edit the page myself". Then an admin intervened, pinging the editor and telling them to be more careful, and then fixed the request for me. And then a different admin performed the requested change.If {{FPER}} had been a redirect, none of this mess would've happened and 2 fewer people would've been involved, because I would've used the more general {{ER}} template and I would've checked the output to make sure it detected the correct page. FaviFake (talk) 15:30, 15 November 2025 (UTC)[reply]
Is there really no reason to keep them separate? The only benefit of keeping 5 different wrappers is this:
If one or more of the pages are unprotected, or multiple pages with different protection levels are specified, the page is categorized in Category:Wikipedia edit requests possibly using incorrect templates. Otherwise, if the force parameter is not set, it is automatically categorized in the correct protection level.
So basically the only benefit is: IFF the pages have different protection levels or are unprotected and the user wishes to force their choice of protection using the |force=y parameter, then they would have to manually add |template. This sounds like a terrible reason to keep these codebases separate, so I do plan on going to TfD if it really is the only benefit. FaviFake (talk) 16:35, 17 November 2025 (UTC)[reply]
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
TfD created. These template should be modified to add this at the top of each one:{{subst:Tfm|Edit protected|Edit semi-protected|Edit template-protected|Edit extended-protected|Edit fully-protected|Edit interface-protected|heading=Edit protected}}
This template must be followed by a complete and specific description of the request, so that an editor unfamiliar with the subject matter could complete the requested edit immediately.
Edit requests to template-protected pages should only be used for edits that are either uncontroversial or supported by consensus. If the proposed edit might be controversial, discuss it on the protected page's talk page before using this template. Consider making changes first to the module's sandbox and test them thoroughly here before submitting an edit request. To request that a page be protected or unprotected, make a protection request. When the request has been completed or denied, please add the |answered=yes parameter to deactivate the template.