Consumer Rights Wiki talk:Bugs/Archive 2

There are a couple of posts asking about search engine indexing of this wiki: Consumer Rights Wiki talk:Moderators' noticeboard#Should CRW be indexed by search engines? and Talk:Main Page#Suggestion: Implementing a /robots.txt page. 📎 JackFromWisconsin (talk | contribs) 02:20, 24 August 2025 (UTC)Reply

We are currently looking into this and I will update the thread as and when we have a solution or any further news. JakeL (talk) 00:38, 8 September 2025 (UTC)Reply

I was trying to edit the beginning of the article on Medical ventilator (to add a see also link to the medical equipment article).

The article has a StubNotice template at the beginning (on the same line as the beginning of the first paragraph).

When I try to save changes after making ANY change to the text on the same line as the stub notice template, it will not save (it gives me a message telling me about the procedure for requesting stubnotice removal). I am not trying to move or remove the stub notice, I didn't touch that. Even if all I try to do is put a newline or space after the template, or change words on the first line, it won't let me. This happens whether I use the visual editor or the source editor. I am using firefox running on linux.

I can save changes later on in that article, and I have edited other articles marked as stubs without issue.

The stubnotice documentation and talk page do not seem to document this behaviour, or tell me what to do. If this is desired behaviour, then the template should explain how to handle it.

Thank you. Drakeula (talk) 21:31, 24 September 2025 (UTC)Reply

Not a mod, but I think I can respond to this. You can’t and this is pretty much desired behaviour. The Abuse filter is the reason for it. It does attack more than just that area too as it thinks you’re changing the notice. AnotherConsumerRightsPerson (talk) 07:40, 28 September 2025 (UTC)Reply

I don't understand why this behavior would be desired. To me it seems like a bug, where the abuse filter is protecting more than it should.

Regardless, how can we improve the lead paragraph when we can not change it?

• Are we supposed to duplicate the immutable first paragraph, putting any revisions/improvements in a secondary copy of the first paragraph? Is there a standard template or way to document what is going on so it doesn't confuse readers when they see two first paragraphs?
• Do we need to propose edits to the first paragraph in some form on the talk page, then request an administrator to come and actually make the change? (If so, how/where do we make the request?)
• Are we expected to just ignore problems in the first paragraph, and revise the rest of it until the stub can be removed?

Thanks. Drakeula (talk) 01:37, 1 October 2025 (UTC)Reply

I wonder if this edit, where an administrator used the visual editor to delete a deletion tag after the stubnotice might be part of the problem. Prior to that edit, the stubnotice was on its own line. After that edit, the stubnotice is on the same line as the first paragraph.

https://consumerrights.wiki/index.php?title=Shortage_of_medical_ventilators_during_the_COVID_pandemic&diff=prev&oldid=25186

If the abuse filter intentionally protects everything on the stubnotice line, then the problem may be in the visual editor, which should ensure that it preserves the newline at the end of a protected line. (At the very least, it should warn an administrator when they are suddenly protecting a bunch of text that wasn't protected before.) Drakeula (talk) 02:06, 1 October 2025 (UTC)Reply

I personally don’t like the current ‘stub notice can only be removed by mods’ anyway, and there are loads of article maintenance templates which don’t have this for some reason. Proposing edits in talk page is actually done on Wikipedia in the form of edit requests, where a mod will look at it there, but the thing is it won’t alert mods here to the request by just posting about it. The point about it protects the entire line seems valid to me and makes complete sense from my own experience, so I do think that is the most likely scenario. AnotherConsumerRightsPerson (talk) 15:22, 1 October 2025 (UTC)Reply

This is by design so that editors do not remove the notice until its been removed by staff for completeness. Once work on an article is completed you can post an appeal in the noticeboard or discord #appeals staff do actively check these so that peer edits can be approved and notices removed. This is both by policy and system design; it is not a bug. If you have thoughts on how we can improve this process feel free to bring it up in the dashboard - Atsumari (talk) 15:46, 12 October 2025 (UTC)Reply

If this is desired behavior -- why? What purpose does it serve making it so the entire first paragraph of an article is immutable?

Note that the issue is the protection of the rest of the line, not the protection of the notice itself.

@Atsumari Sorry, I don't know where/what the dashboard is, please give me a link. In the meantime, I will post suggestions for improvement here. Thank you.

How to improve it:

• Fix the code, so that only the stubnotice template is protected, not the rest of the line.
• Fix the code when submitting a change so that it always adds a newline immediately after a stubnotice (or other protected template) if there isn't one there.
• When a moderator submits a change with anything on the same line as a protected template, (either by adding to it, or by deleting the newline at the end of the line) the software should issue a warning, telling them what this will do to everybody else and asking them to confirm that they really want to do that. (Make the warning simple, clear, blatant, something you have to type a response to so people will read it and not autoclick.)

Temporary workarounds:

Add cautionary notices to the stubnotice template and its documentation.

• The documentation should explain this behavior, tell moderators what the intended use of protecting the rest of the line is, and warn moderators about the problems it can cause.
• If the visual editor is part of the problem (as I suspect it may be, given the edit which caused the problem in this article), then the documentation should warn moderators to be especially careful when using it around stubnotices.
• The template text should explain what is going on, so an editor encountering the problem for the first time knows what is happening, and what to do about it. (How to get help to fix this case.) Drakeula (talk) 19:46, 18 October 2025 (UTC)Reply

Just found that the template:incomplete has same problem. Drakeula (talk) 05:17, 19 October 2025 (UTC)Reply

That part about the first paragraph being un-editable is not intended but the fact that users cannot edit the stub notice (or other notices) is created so someone cant just arbitrariliy edit their post removing the notices without staff review and formal appeal of the action by the user. As for where the dashboard is Consumer Rights Wiki talk:Moderators' noticeboard here is a link to it. As for the rest of your concerns I will flag down one of the tech folks or Keith for you to provide a more detailed explaination or look into exactly why everything in a first paragraph is being locked down as if someone adds a stub notices it should be at the top and above all text so there should be a seperation between the article text and the stub notice. This might also just be a policy thing we need to discuss as the stub notice is working as intended but the text after it being locked is not. - Atsumari (talk) 08:24, 1 November 2025 (UTC)Reply

Usernames allow a wide range of characters. When |author= is used, the warning should not exist. The numberic warning should still exist on |last= and |first=. Many pages in Category:CS1 maint: numeric names: authors list are false positives. 2A00:23C8:2384:101:B34:3E7B:6AF4:18CF 16:56, 9 November 2025 (UTC)Reply

Hello, there are some pages that were created by the maintenance script that are all a subpage of Broken. You can find them by going down here. AnotherConsumerRightsPerson (talk) 07:43, 2 January 2026 (UTC)Reply

These pages don't even seem to be deletable. AnotherConsumerRightsPerson (talk) 06:18, 15 January 2026 (UTC)Reply

Now fixed! JakeL (talk) 00:41, 6 March 2026 (UTC)Reply

#7FB6FF for links and #004080 for background are too close to each other. It is improvement over prevous conmination, but still not super accessible for color blind people. Blue and black themes are quite hard to make because both are dark colors. You can ping me here or in Discord if you want to discuss accessibility. Banana (talk) 22:40, 4 February 2026 (UTC)Reply

Icons like Alerts, Notices, Watchlist and Personal settings are switching to black when device is in dark theme. Tested in chrome and firefox, on Linux (ubuntu 24.04 LTS + KDE) and Mac. Banana (talk) 22:44, 4 February 2026 (UTC)Reply

#6a60b0 for link text on #1b223d has contrast of 2.91 which is way off for color blind people. Banana (talk) 22:50, 4 February 2026 (UTC)Reply

Good example is Previous discussions block in this page. It has too low width or margins, so flex layout wraps first entry in list around it. Banana (talk) 22:53, 4 February 2026 (UTC)Reply

w/Special:Preferences has same header functions as other pages header, but has other styling Banana (talk) 22:59, 4 February 2026 (UTC)Reply

This will reduce amount of clicks to some articles and make user experience little touch better Banana (talk) 23:00, 4 February 2026 (UTC)Reply

Tested in chrome and firefox, both Linux (ubuntu 24.04 lts + KDE) and Mac. Width radio buttons don't change anything in any page I opened to check it out. Banana (talk) 23:04, 4 February 2026 (UTC)Reply

/Sandbox/Welcome is looking same and does absolutely same stuff as /Sandbox Banana (talk) 23:22, 4 February 2026 (UTC)Reply

If you click on hide option, It creates just another button in static header, which is super confusing for those who have not a lot of technical knowledge Banana (talk) 23:31, 4 February 2026 (UTC)Reply

Same with tools being pinned to vector-menu-content-list Banana (talk) 23:38, 4 February 2026 (UTC)Reply

This value is fallbacked as key name because it points to non existing entry Banana (talk) 23:33, 4 February 2026 (UTC)Reply

Hello, LibreWolf and Tor both cannot use the new CRW extension as it needs "the new firefox". I clicked the download file option as well, but it doesn't work either for both. Might just be a Mozilla being almost as bad as Google sort of issue but this doesn't happen to any other extensions, so i doubt it. AnotherConsumerRightsPerson (talk) 17:41, 4 March 2026 (UTC)Reply

I'll pass this on, though to my knowledge there's no official support for either browser Keith (talk) 17:44, 4 March 2026 (UTC)Reply

They're both Firefox-based, and even extensions specifically made for Firefox and only firefox work with firefox-based browsers. This one is a very unusual exception. AnotherConsumerRightsPerson (talk) 18:04, 4 March 2026 (UTC)Reply

Have had a chat with Jake, and seems it's (mostly) a config issue on our end, with the minimum Firefox version being specified somewhere or other. If you want to get to the extension straight away, you can get it directly from the extension github: https://github.com/FULU-Foundation/CRW-Extension

Otherwise, it's something we'll aim to resolve in the next release. Keith (talk) 18:09, 4 March 2026 (UTC)Reply

You can download the extension, edit the strict_min_version in manifest/firefox.json (line 51) https://github.com/FULU-Foundation/CRW-Extension/blob/main/manifest/firefox.json#L51 to a lower Firefox version, then build and install it locally https://github.com/FULU-Foundation/CRW-Extension?tab=readme-ov-file#clone-and-build-the-extension as a temporary workaround. We'll be lowering the minimum version requirement in a future release. JakeL (talk) 18:17, 4 March 2026 (UTC)Reply

Thanks, will do that! AnotherConsumerRightsPerson (talk) 18:19, 4 March 2026 (UTC)Reply

WOW. I am in awe at how good the extension is now. This has completely changed since the previous version, I'm so glad I went into the effort of installing it. AnotherConsumerRightsPerson (talk) 18:48, 4 March 2026 (UTC)Reply

Thanks for the kind words, glad you're enjoying it! JakeL (talk) 18:50, 4 March 2026 (UTC)Reply

Multiple users have accidentally created pages with incorrect titles (e.g., including a year or typos). Including myself, please allow users to edit title names, because [Year] Doesn't always show up in the search and it's annoying that we cannot fix titles

A Clippy (talk) 09:31, 5 March 2026 (UTC)Reply

Hi, this is possible, you just need to be confirmed. I'll make you confirmed and tell you how to do it. AnotherConsumerRightsPerson (talk) 17:27, 5 March 2026 (UTC)Reply

What you need to do is click on the 'Tools' button on the right above the article if you have it, and from there even if you don't have it on the right a 'move' button should appear. Click that and move the page. AnotherConsumerRightsPerson (talk) 17:28, 5 March 2026 (UTC)Reply

Thank you! A Clippy (talk) 06:23, 8 March 2026 (UTC)Reply

The editcontentmodel user right (see [1]) is currently bestowed (I believe mistakenly) to new users, which you can check via Special:ListGroupRights. This allows any logged-in user to change the content model of any page on the wiki between CSS, Javascript, JSON, plaintext, sanitized CSS, and wikitext, using Special:ChangeContentModel. On the English Wikipedia, this is a user right only granted to administrators and other such trusted user groups, I expect because it can massively reformat an entire page, and because I'm not sure if it checks for permission to edit the target page.

I'm not a security expert, but maybe there's a chance there's a security problem as well involving placing malicious code in any namespace? Though, I don't think there would be a way to run the code. I'm more worried about potential vandalism.

There's only been three uses of this tool (one use being a test by myself) on this wiki, so I'm sure you guys aren't going to be missing out on much by restricting usage of this tool to only trusted users. MEN KISSING (talk) 09:27, 13 March 2026 (UTC)Reply

This is enabled by default in MediaWiki, presumably because wikis are intended to be permissive and collaborative by nature. Thanks for noticing though! I will be pushing an update shortly to restrict it appropriately. JakeL (talk) 18:52, 13 March 2026 (UTC)Reply

I see the permission is now limited to admins and interface admins, good work!

Can I request that my sandbox, where I tested the ChangeContentModel tool, be changed from plaintext back to wikitext? I'm not able to do it myself anymore. MEN KISSING (talk) 19:46, 13 March 2026 (UTC)Reply

All done! JakeL (talk) 20:21, 13 March 2026 (UTC)Reply

Hello!

So i have consumer rights wiki installed in firefox, but there is a problem where when i click "Hide until new incidents" on ex. www.google.com, it still gets shown on other subdomains like mail.google.com and i need to click the button for every subdomain.

I think it would be great if there was an option to use whole domain blocking (whole example.com) and subdomain snoozing (only xyz.example.com) Kitki30 (talk) 10:15, 7 April 2026 (UTC)Reply

Thanks for your report. This was already fixed a couple of weeks ago to use root level blocking and will be available in the next release. JakeL (talk) 11:17, 7 April 2026 (UTC)Reply