Fri, Jul 12
Thu, Jul 11
Calling out the different language in the yellow box seems to fix the UX issue of "why is there some foreign text here"
Sun, Jun 30
Sat, Jun 29
We have a hack in on enwiki (MediaWiki:Monobook.css) so once the train rolls feel free to ping me to renormalize that.
Fri, Jun 28
Note, user reports they were unable to create this tickets as phab was prompting for logon (with aforementioned 2FA...)
Thu, Jun 27
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)
Wed, Jun 26
@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)?
Mar 13 2019
Emailed T&S asking for any update.
Mar 4 2019
Cancelling this, was updated in fc9efe67d599
I didn't protect as a security issue since it is failing safer.
Mar 3 2019
Mar 1 2019
@Urbanecm - also it only is used when the only reason for account creation fail is rate limit (see examples here: https://en.wikipedia.org/wiki/Special:Log/OutreachDashboardBot)
@Urbanecm the outreach dashboard creates all accounts via enwiki (which then due to SUL get autocreated anywhere when logged in) - and this exemption is allowed via a service account between the dashbaord and enwiki (https://en.wikipedia.org/wiki/User:OutreachDashboardBot).
For what it's worth, we have recently put in an process for account creation via outreachdashboard.wmflabs.org , the throttle is bypassed if the creation is made via an event on the dashboard. This certainly doesn't solve the core complaint, but may help with anyone running an event.
Feb 22 2019
I'd like to see this information in AF variables, no opinion as to the best way to accomplish it (including if a different variable should be used). A related item may be for edits that are protected by other means as well (such as a namespace protection, or a page type protection).