User Details
- User Since
- Oct 27 2014, 6:03 PM (491 w, 3 d)
- Availability
- Available
- IRC Nick
- edsanders
- LDAP User
- Esanders
- MediaWiki User
- ESanders (WMF) [ Global Accounts ]
Today
Above patch removing the black background in favour of the default:
...as does MobileFrontend for the CTA drawer, used for redlinks, and actions while logged
Yesterday
Tue, Mar 26
Mon, Mar 25
Same cause as T360863?
The problem is caused because we pass dtenable=1 to the API, which enables all DT features, including visual enhancements. In the past this wasn't a problem because we toggled buttons/links using CSS, but now we only generate the "correct" one.
This happens with [ reply ] links, but not the new reply buttons.
This happens with [ reply ] links, but not the new reply buttons.
As we are tightly integrated into VE, the only sensible option here is OOUI.
The code that probably caused the regression was introduced to fix T242784. I've verified the above doesn't cause an regression with that issue:
Toolbars-in-toolbars is no longer a thing (sorry Xzibit), which should make things a bit easier.
For reference, the Android app also uses light drawers, with and additional dark overlay for the content area:
Fri, Mar 22
I built a fresh install of 1.41 on PatchDemo and DT works fine: https://patchdemo.wmflabs.org/wikis/f26870e830/w/index.php?title=Talk:DiscussionTools&mobileaction=toggle_view_desktop
Thu, Mar 21
I can no longer reproduce this. Feel free to mark as resolved.
Wed, Mar 20
Note also that while most sites are blocked by domain, filters are regular expressions which run on the whole URL, and it is not trivial to work out which part of the URL triggered the block, for example:
https://en.wikipedia.org/wiki/MediaWiki_talk:Spam-blacklist seems to be the main discussion page for both blacklists and would make for a sensible default at most wikis. There's the global blacklist as well, but presumably local contributors will be able to direct people to the right place if the blocked domain is globally blocked.
Tue, Mar 19
See also T139747
Also the bot last uploaded content in June 2020: https://commons.wikimedia.org/wiki/Special:Contributions/LanguageScreenshotBot
There are tasks to get this job running again, and the script for generating screenshots work locally.
Mon, Mar 18
The above patch uses the same variable as used in the other popup/dropdown menus (@font-size-dropdown). Presumably this will get migrated to the small/standard/large CSS variables when that switch happens.
Sat, Mar 16
given our plans for changing the font size,
Fri, Mar 15
Thu, Mar 14
See this commit message for why @Catrope left in "undelete" (and therefore "delete"): https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Flow/+/415514
After:
Also the font size should be 14px (for now): https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1011166
To make tests more resilient in general we should:
- Avoid looking for specific i18n messages
- Add some CSS classes judiciously to make our selectors less fragile, e.g. by helping us avoid nth child selectors
There's a rule in CodeMirror (written by myself 5 years ago) that gives the toolbar a z-index of 7, so this is only broken when CodeMirror is not installed.
Wed, Mar 13
This doesn't appear to happen consistently for me locally:
We don't have these transaction types anymore.
The same applies to ToggleButton (codex) vs ToggleButtonWidget (OOUI)
Tue, Mar 12
We want to avoid enabling VE on namespaces which contain discussions, such as the page you linked to (VE does not handle the indentation used in discussions very well). Are most pages in the Wikipedia: namespace on your wiki non-discussion content?
Sun, Mar 10
The easier fix here is to avoid level 2 headings unless you are starting a new discussion , e.g. by using level 3 instead
Thu, Mar 7
I also note that Citoid expands the shortened URL to youtube.com, which is allowed - but we do our validation on the inputted URL.
The error message you get in the save dialog is a lot more verbose, and includes information about not using URL shorteners:
Wed, Mar 6
Will we prioritize making permalinks more discoverable at this time?
The code checks if the prefix is ctype_alpha in PHP. The check for generating the links doesn't include the ctype_alpha check.
Tue, Mar 5
It'd be pretty easy to hook into the same code that's highlighting permalinked comments and log to that schema from there, if we want to track usage, too.
This was a Codex regression, as the icon went from having padding to having margin.
Note that this doesn't measure if the permalink is used. We could perhaps track on-wiki usage by looking for #c- or #h- in wikitext diffs, but not off-wiki use:
https://en.wikipedia.org/w/index.php?search=insource%3A%2F%5C%23c%5C-%2F&title=Special%3ASearch&profile=advanced&fulltext=1&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns100=1&ns101=1&ns118=1&ns119=1&ns710=1&ns711=1&ns828=1&ns829=1
Given the age of those issues we shouldn't expect them to be fixed any time soon.
Anything that generates block level HTML should be disallowed in a signature, if not automatically by our signature validator, then by policy.
Mon, Mar 4
The initial API has been implemented, it returns "blocked" or "allowed" for a given URL based on MediaWiki:Spam-blacklist and MediaWiki:BlockedExternalDomains.json.
See also T262093.
I think T262093 would help with the infobox issue.
Sat, Mar 2
Fri, Mar 1
I'm not sure this needs a tech news announcement, but if you want:
Usability improvements to the "Add a citation" workflow: Moved the "Insert" button to the popup header.
Thu, Feb 29
The highlighter is for formatting SQL syntax only, not an interactive SQL command prompt. Such a request could be made upstream.