importScript() is only for local pages. This is by design and how it has always been. To reference scripts or gadget from other wikis, use mw.loader.load() with the full canonical title=...&action=..&ctype=... URL.
Fri, Aug 5
Change 820702 abandoned by Samtar:
[mediawiki/core@master] ImagePage: Add category to files exceeding $wgMaxAnimatedGifArea
Flawed - I want tracking categories I think, not addCategoryLinks
Oh well, we can just leave them disabled, I don't think anyone is going to work on this further.
Change 201905 abandoned by Umherirrender:
[mediawiki/core@master] Unify hooks and performance improvements for change tags
Old patch set, linked bug already resolved
@Esanders would it be accurate for me to think the reason that the first section on this page (== New font stack breakdown ==) does not get the Topic Container counters/metadata because the signature ( Edokter (talk) — 12:36, 12 April 2014 (UTC)) appears within an H4, in this case ====Helvetica====?
We've enabled the Public Logs datasource in Grafana and forwarded scap.announce logs to it.
The errors seem to stop - https://logstash.wikimedia.org/goto/6e75427fdc39f0ae9c241418bc7de928. Last timestamp - Aug 4, 2022 @ 19:39:16.373; will check in a couple of days before closing the ticket.
Having this issue in a fresh 1.38.1, see https://wikivideos.org/wiki/Main_Page?veaction=edit
I also had it in 1.37 (updated to 1.38.1 hoping it would fix itself but didn't).
The issue doesn't occur on two 1.35 wikis I have on the same server (https://sophivorus.com and https://mediawiki.solutions)
I'm running PHP 7.4.12 and identical setup everywhere, AFAICT.
Page creation works fine, the issue happens only when editing existing pages.
Looking at https://wikivideos.org/info.php it's pretty clear I have php-bz2 php-zip php-bcmath php-gmp php-pspell php-tidy
But php-pear is disabled. It feels very unlikely this be the cause since my 1.35 wikis work fine without it but I'll report back when I manage to enable it.
Also I can't switch to PHP 8.1 to test if this fixes the issue, I'm afraid.
Old proof-of-concept patch: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/662129
If phone and app are in dark mode, text in certain sections is unreadable. This bug is most easily seen in track lists for albums. The spreadsheet format for track lists often use a format where every other row is white, however the text is normally white in dark mode. The text in the white sections of these rows is not changed from the standard white, so it is not readable (it is white text on a white background)
In T314381 we routed k8s logs into a new partition. Preliminary analysis indicates that k8s logs occupied ~95% of the syslog partition and contributed to >6hour forcemerge operations.
We've decided that we want to get a short report of the findings up on Mediawiki, which I'll time box and work on next week.
I'm sure we've said it before, but these designs are really nice 😄
The key in https://phabricator.wikimedia.org/P32283 matches the key in Gerrit, and thanks for checking it. Per comments on T313299 now I just need to have an email or slack message from @diego that all this is legit and then I can ago ahead.
k8s logs are now split into their own partition.
@Urbanecm_WMF - I checked on cswiki betalabs - there is no limit on accepted message's length for "Introduction message" on Special:EnrollAsMentor. Another issue with the entered message is on enwiki betalabs - filed as T314691: [betalabs] Mentorship pages issues.
The new test run completed and the perf is roughly similar. As for the logstash warning, looking at a 3-month window, I see identical warnings from May and June test runs.
I should add that we of course can hack something into ResizingDragBar.js. I didn't dabble with that idea much though so maybe there's something we can try there... I'll look when I get the time. For now, we're only asking Vector maintainers for a quick solution should one exist (don't worry about having to touch WikiEditor!).
@Urbanecm_WMF - can you confirm the fix in the production? testwiki wmf.23 has structured mentorship enabled as mentioned in https://phabricator.wikimedia.org/T314050#8122421 and the issue is still there (tracked in T314362: Ensure MentorWeightManager is not used with structured mentor list).
hmmmmm, from the above patchdemo I'm testing with https://patchdemo.wmflabs.org/wikis/c9aeeffe22/wiki/File:IZjdaFG6Wb.gif — the category exists but is still a red link, and the file isn't included in the category 😟
Logs are flowing into the k8s partition.
+1. @Proc has explained via IRC about the complexity of the bot and reminded me of past efforts to get all of it running on Toolforge that ultimately failed. This project might be a good candidate for beta testing of the buildpack system when it's ready.
Last call to the deprecated API was on 2022-07-19 per https://logstash.wikimedia.org/goto/7ce698170eeb7ea1debb1bad729c852c. This corresponds with a new deployment of Striker for T306469 which included @Reedy's patch.
Support. I have a template used on talk pages that has a date in it (~~~~~) and it is receiving a [ reply ] button. Having some way to suppress this would be useful. Even if it is as simple as adding a class somewhere.
This has been fixed as a side effect of moving to pipelinelib and updating dependencies.
Merged and deployed lemme know if that fixed it - sorry didn't get the chance to test it live as I no longer have a TS account. Let me know if you have a tool account and I add you as a deployer. Once the PR is merged deploying is usually just ssh'ing and running a shell script that does all the git and kubernetes steps.
I would not expect the banner to be in the parsed output since action=parse is meant to parse the content (wikitext) of the page, and the banner is not present in the wikitext.
I'm still unsure as to why something that's supposed to be part of the interface shows up on parsed HTML
This is also true of section edit links
I have a question-- is this state for a human audio file? And also, when there is no file, wouldn't our IPA rendering kick in and populate it after the CommonsDelinker will remove it?
https://openstack-browser.toolforge.org/server/security-checker1.packagist-mirror.eqiad1.wikimedia.cloud should probably be deleted too.
$ curl -I https://php-security-checker.wmcloud.org HTTP/2 301 server: nginx/1.18.0 date: Fri, 05 Aug 2022 21:36:39 GMT content-type: text/html content-length: 185 location: https://php-security-checker.toolforge.org/ strict-transport-security: max-age=31622400 x-clacks-overhead: GNU Terry Pratchett permissions-policy: interest-cohort=()
The use case being you have just edited a page and the banner should be shown. An editor like VE which updates the page dynamically does so by fetching the new page contents from action=parse, so this needs to return the full rendering of the page, including this banner.