Fri, Sep 6
Aug 15 2019
Is any work continuing on this? With issues like T230521 coming up again having more established users (e.g. "extendedconfirmed") not get hit with the default limit would be useful.
@Urbanecm thank you for the initial response. For the first part, trying to determine if this is being proactively managed by WMF staff or volunteers - as employees are more expected to respond than volunteers. Recently when such a mitigation was deployed (T212667) the temporary measure persisted for 6+ months (you were one of the volunteers asking up on why it was not being acted on if I read right!).
Is there some sort of shadow task (such as how T212667 was previously used)?
Aug 7 2019
I'm not sure what to do for the next step in troubleshooting, was able to replicate this with another account easily:
Here is the computed rule for it:
Is the specific element that we're seeing the problem with. It is not present at all in the source when it is not displayed.
@Krinkle ok that is executing, so there must be something else going on. The specific symtom we're seeing is that the "page notice" edit links introduced in https://test.wikipedia.org/wiki/MediaWiki:Editnotice-0 via https://test.wikipedia.org/wiki/Template:Editnotice are not appearing for some users. With my normal account (xaosflux) I see them, while other sysop accounts are not (e.g. SilkTork, Xaosflux2)
Aug 3 2019
Well if it can hold reader-facing content (such as https://en.wikipedia.org/w/index.php?title=Gadget:Invention,_Travel,_%26_Adventure&redirect=no ) it shouldn't require employees to update it.
Jul 28 2019
@Nardog there are really 2 issues here:
- the places this message is invoked do not parse wikitext in to links
- You want the message to be different
Jul 27 2019
Wikilinks are not supported there either - looks like the html links used to work - regression? I've deleted the enwiki page to use the mw default without links for now.
Jul 23 2019
Additional on-wiki discussion regarding symptoms and troubleshooting: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=907516694#The_notification_button
Jul 12 2019
Jul 11 2019
Calling out the different language in the yellow box seems to fix the UX issue of "why is there some foreign text here"
Jun 30 2019
Jun 29 2019
We have a hack in on enwiki (MediaWiki:Monobook.css) so once the train rolls feel free to ping me to renormalize that.
Jun 28 2019
Note, user reports they were unable to create this tickets as phab was prompting for logon (with aforementioned 2FA...)
Jun 27 2019
Serious note on the alignment problems @Catrope please see (https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=903776666#Excessive_width_on_monobook) where some suggested local fixes have been getting worked on. I haven't tested and am not ready to move these to site css's - especially if this has an 'upstream' fix coming.
Please let us know if there should be distinct phab tickets open for each of the skin's issues
The more I look the more problem I can see with these in various skins, in CologneBlue they are overlapping the vertical area
In the modern skin the notification icons are even worse, especially the 'inbox' one:
All of the clicks are off there, going from right to left, the "notices" clickable area seems to start right at the inbox icon, but continues until halfway through the bell icon; then the 'alerts' one begins and continues for about double the width of the bell icon to the left (overlapping the username display)
Jun 26 2019
@Aklapper something "might get out of sync" vs something is actually presenting worse then it was before feels like a loss to me. Unless monobook is going to officially be discontinued, it (along with all skins) should be part of QA tests to prevent these sorts of problems.
@Aklapper compared to the user experience of presenting that there may or may not be some content just off the screen on every page, that is a major UX loss
I don't recall there being an actual user experience issue presenting before though - was there an actual previous user interface problem? (Ticket number?)
Perhaps @Catrope or @MarcoAurelio can explain it better? My understanding is that a recent change broke the notifications, and rather then rolling it back an additional change was put on top that caused this new issue.
Note, enwiki has a local workaround (https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=903562164#Excessive_width_on_monobook) in case anyone wonders why this isn't broken there now
Mention: link to T226503 - which is noted as causing this new problem.
The forced width on monobook isn't really a "fix" now then, it is a new problem. T226597 opened on that. Why wasn't the breaking action on this reverted instead of causing new headaches?
Jun 21 2019
Possibly related to T30299 ? I'd like to see the underlying explanation for today's problem if it was caused on the front end somewhere. Can a commons admin look for any deleted history / logs?
Jun 20 2019
Jun 11 2019
Even browsing to such a page (e.g. https://test.wikipedia.org/wiki/User:Test_/test1) results in a mediawiki error, dump below:
Jun 9 2019
@DannyS712 that would be a simple config request, but the point of this request was to avoid adding editcontentmodel to more people
@Vogone we currently support many workflows to create pages in non-wikitext (e.g. creating css pages, js pages) and I'm looking at expanding just this one workflow, do you see an issue with the concept?
May 31 2019
OK, no worries!
May 30 2019
@DannyS712, would "editcontentmodel" *OR* "massmessage" work even better here (I haven't thought about this in a while) - since we don't know how some downstream projects may configure their roles.
May 18 2019
List users does it as well, for example: https://en.wikipedia.org/wiki/Special:ListUsers?username=DoRD&group=checkuser&wpsubmit=&wpFormIdentifier=mw-listusers-form&limit=1
May 16 2019
Apr 25 2019
@Pppery note, mediawiki in general supports most anything in display title if you enable displaytitle, if you do then you can also optionally lock it down - this ticket is only about locking it down. Individual WMF projects can certainly pick to enable or not enable lockdown. Perhaps a tangential task would be for something like a parameter to enforce in , or exempt in certain namespaces (if you'd want to go that route please open a different task though).
@Izno by default this isn't applied, only for projects that configure $wgRestrictDisplayTitle to be true
Apr 22 2019
Well it should be to "a permission" that certainly stewards could have, though the meta-wiki oversighters may be able to handle these a well (need a community discussion first since this went live prior to getting one made)
Apr 19 2019
I'm sure some of these tags are wrong, but this is just being ignored after recently being broken and I'm trying to get someone's attention.
Apr 17 2019
Just wondering - is anyone working on this? Has anyone been able to validate what the breaking change was?
Apr 16 2019
@MarcoAurelio I think this has been resolved, see example:
Regarding the URI PATH component there seems to be a legit use case for allowing arbitrary pages here such as "Hey friend, when you are ready create that page here: https://w.wiki/32m"
Apr 14 2019
In case anyone was looking for anything on this, note that accounts created via outreachdashboard.wmflabs.org have effectively been made throttle exempt
Apr 13 2019
Notes from enwiki discussion:
As was noted in T220885 some special pages (e.g. https://test.wikipedia.org/wiki/Special:RecentChanges) are still using the separators.
Notes from T220885
The following separators appear to be missing throughout the output:
Apr 10 2019
If this becomes a 'This accounts meets the minimum standards for Account security' checker, then perhaps it should also have an expanded output if run on 'self' - declaring what components you are missing so you know what you need to remediate?
@Volker_E almost all of the feedback is that there is much wasted horizontal space. The collapsing may be nice as well, but why the insistence on making this such a long vertical form when there is screen real estate available?
Apr 9 2019
@Dinoguy1000 we certainly can trim the enwiki css if it's useless - is there an example that can demonstrate this issue to verify?
Apr 8 2019
@Jdlrobson for mobile touch friendly - sure, use it when someone is in mobile mode - not in keyboard and mouse mode.
All that wasted horizontal area, combined with the much longer vertical usage seems to be the main complaint here, not so much the box decorations, if space is limited sure let it scroll to multiple lines, but when there is plenty of space to the right, use it. I'm certainly not looking forward this this same design layout coming to watchlists either.
Note, I'm not the one who said it was 50%, it appears to be about a third of the content area.
Yes, it was the "prior" but moving to OOUI forms certainly could have been used while maintaining the layout right?
Regarding the "form experience" - yuck. See also https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Hideous_history_page.
The example in the description showed all elements side by side, now there are huge gaps and the vertical layout makes this take up about a third of the screen.
Apr 6 2019
Apr 2 2019
I was able to reproduce this with a normal protected page, but then I it appeared to fix after a page purge - is consistently breaking with pages that are cascade protected though.
Reported on enwiki by Jmar67 in https://en.wikipedia.org/w/index.php?title=Talk:Main_Page&oldid=890569090#Editable_entries
Mar 29 2019
Mar 19 2019
Thanks for the update @jrbs so for those of us that give out int-admin locally, we'll just keep saying "you better do this" and leave it up to WMF to enforces the 2FA rules.
Breaking the redirect on the remote shared repository page (such as in https://commons.wikimedia.org/w/index.php?title=File:Lee_Dixon.jpg&oldid=343164913 ) restores the local projects access.
Mar 15 2019
@jrbs this specific task is only about the "allowing the community to check that an account really has enabled 2FA before granting it additional rights within the regular community process" part - so from a T&S point of view can it proceed (while not stopping any other types of improvement processes)?