Tools like MassMessage add jobs to the job queue for later processing outside of the main MediaWiki process. MediaWiki used to track the job queue itself, but this is no longer the case (T157088). To increase stability and to allow multiple datacenters to handle the job queue, the job queue is now handled by Kafka: https://wikitech.wikimedia.org/wiki/Kafka_Job_Queue. Once MediaWiki sends the job to Kafka, it doesn't know about the job anymore, and the EventBus job queue isn't designed to send information back to MediaWiki about job execution. Job execution is tracked in Grafana, though. You can see the current state of the MassMessage queue in https://grafana.wikimedia.org/d/000000400/jobqueue-eventbus?orgId=1&var-site=eqiad&var-type=All&viewPanel=15 by filtering for "MassMessageJob_0".

Autoconfirmed on Commons and most other wikis have no minimum edit requirement -- just a 4-day-old account. Only a few wikis (arwiki, eswiki, ewswikivoyage, itwiki, nowiki, wikidatawiki, zhwiki, zh_classicalwiki, zhwikinews) have a required edit count greater than 10.

R2123 banners/Powered-by-Toolforge-button.svg / https://tools-static.wmflabs.org/toolforge/banners/Powered-by-Toolforge-button.svg exists, so we could at least use that instead. Using the SVG, making it a little bit bigger (120px wide maybe?) and providing a tooltip would be preferable over removing it entirely in my view.

According to Grafana, eqiad and codfw each get an average of 0.8 queries for new SVGs per second, with spikes up to 4 qps. More than 75% of those requests are handled using 575ms of CPU time on average. For context, there are 8.4 requests per second to eqiad and codfw for filetypes handled by imagemagick, including SVGs, which use 2-4s of CPU time.

Currently, (after the rollback), 500/500 of the most recent uploads to Commons are appearing correctly

And now we have the inverse situation too: https://commons.wikimedia.org/wiki/File:DJEFF_Official.jpg was deleted, but the file metadata still appears. It's like the file description page was deleted but not the image. https://quarry.wmflabs.org/query/49941 shows that the data in the database is correct, so the issue must be in the cache somewhere.

18 out of the last 500 files uploaded to Commons (3.6%) are affected.

Not a bug.

$ identify 20200317143113!Unitycircle-complex.gif | wc -l                 
1001

500 * 495 * 1001 = 247,747,500 px

$ units
Currency exchange rates from FloatRates (USD base) on 2020-10-03 
3677 units, 109 prefixes, 114 nonlinear units

Confirming that 500/500 of the most recent uploads are working correctly. Additionally, the files identified previously are also all working correctly now.

Using the script from T253405#6161498, I found 38 files out of the last 500 uploads (7.6%) that were not working:

• https://commons.wikimedia.org/wiki/File:FLOREY.jpg
• https://commons.wikimedia.org/wiki/File:Johnny-dole-and-the-scabs.jpg
• https://commons.wikimedia.org/wiki/File:FARRER.jpg
• https://commons.wikimedia.org/wiki/File:MARTIN-fatchen.jpg
• https://commons.wikimedia.org/wiki/File:MARDOCHEE_BUHENDWA.jpg
• https://commons.wikimedia.org/wiki/File:FATCHEN.jpg
• https://commons.wikimedia.org/wiki/File:Photo_stacked.jpg
• https://commons.wikimedia.org/wiki/File:DAWKINS.jpg
• https://commons.wikimedia.org/wiki/File:Cvl_com_arma_de_nescau.jpg
• https://commons.wikimedia.org/wiki/File:CLUNIS-ROSS.jpg
• https://commons.wikimedia.org/wiki/File:COOMBS.jpg
• https://commons.wikimedia.org/wiki/File:BEADELL.jpg
• https://commons.wikimedia.org/wiki/File:CRAIGMORE.jpg

In T267668#6619716, @ColinFine wrote:

I don't know if this is helpful, but when I tried editing [[Allan Shivers]] on en-wiki, which is showing the problem, I noticed that the image appears in "Show Preview", but on saving it goes back to showing a redlink with URL https://en.wikipedia.org/wiki/Special:Upload?wpDestFile=Allan_Shivers_(1956).png

Likely related to https://lists.wikimedia.org/pipermail/cloud/2020-November/001287.html

Sounds like T253405: Some (recent?) uploads to Commons are not available on other wikis again. Looks like @jijiki's been doing some memcached work today relating to T244340, so that seems like a likely culprit. The files eventually appearing after some time is also consistent with a caching problem.

Preventing moves into the a JsonConfig namespace would be a good idea. It doesn't look very difficult to add to the onMovePageIsValidMove hook. I'll look at putting a patch in for that.

That API request worked, but as you noted the diff for the revision doesn't work: https://commons.wikimedia.org/w/index.php?title=Data:ItWikiCon/2020/WebsiteVisitsByDurationAll.tab&diff=510923143&oldid=510815940

[b8efc824-7968-42b9-8be1-0e2e00fdeebb] 2020-11-07 14:45:47: Fatal exception of type "MWException"

To be clear: is this a problem with the Commons file moving gadget, https://commons.wikimedia.org/wiki/MediaWiki:Gadget-AjaxQuickDelete.js, or is it a problem with MediaWiki? You can bypass AjaxQuickDelete by opening the move link in a new tab. Problems with AjaxQuickDelete are not handled here, and should be reported to the gadget maintainers at https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-AjaxQuickDelete.js or COM:VPT

I think it would be useful to have a page or section outlining the de facto requirements for connecting to the flagship Wikimedia sites. https://wikitech.wikimedia.org/wiki/HTTPS/Browser_Recommendations is part of that, but since it's user-facing it doesn't really tell the whole story. That sort of technical documentation would be useful for developers and tech ambassadors to know what our current configuration is/should be without having to trawl rOPUP.
We're also in the unique position of being a heavily-trafficked website that also cares deeply about user privacy, so I think being clear and transparent about what we think is adequate security at the moment is important.

In any case, the TOUs are Legal's responsibility. I've dropped legal@ a note as well.

As the WMF-Legal project tag was added to this task, some general information to avoid wrong expectations:
Please note that public tasks in Wikimedia Phabricator are in general not a place where to expect feedback from the Legal Team of the Wikimedia Foundation due to the scope of the team and/or nature of legal topics. See the project tag description.
Please see https://meta.wikimedia.org/wiki/Legal for when and how to contact the Legal Team. Thanks!

I'm not sure that a change to the actual text needs to be made. It's pretty general as it is, and says several times not to expect support for third-party uses. It may be helpful to add a note at the top (or at the top of the "Using maps in third-party services" section) saying that third-party access is no longer generally available. Leaving the rest of the information about third-party services is important for the allow-listed sites and in case the Foundation decides to allow broader third-party access in the future.

The only extension in https://www.mediawiki.org/wiki/Category:PageContentSave_extensions that is on WMF sites is TemplateData. The hook calls rETDA includes/TemplateDataHooks.php:46, which then intentionally parses the page early.

/**
 * @param WikiPage &$page
 * @param User &$user
 * @param Content &$content
 * @param string &$summary
 * @param bool $minor
 * @param bool|null $watchthis
 * @param string $sectionanchor
 * @param int &$flags
 * @param Status &$status
 * @return bool
 */
public static function onPageContentSave( WikiPage &$page, &$user, &$content, &$summary, $minor,
	$watchthis, $sectionanchor, &$flags, &$status
) {
	// The PageContentSave hook provides raw $text, but not $parser because at this stage
	// the page is not actually parsed yet. Which means we can't know whether self::render()
	// got a valid tag or not. Looking at $text directly is not a solution either as
	// it may not be in the current page (it can be transcluded).
	// Since there is no later hook that allows aborting the save and showing an error,
	// we will have to trigger the parser ourselves.
	// Fortunately this causes no overhead since the below (copied from WikiPage::doEditContent,
	// right after this hook is ran) has guards that lazy-init and return early if called again
	// later by the real WikiPage.

Example category: https://commons.wikimedia.org/wiki/Category:Artworks_with_mismatching_structured_data_P6243_property. This category is set by {{artwork}} when |wikidata= is set but it does not equal P6243 (digital representation of) in SDC.

While VideoJS doesn't have native support for spherical video, there is a plugin that adds support: https://github.com/videojs/videojs-vr. The examples at https://videojs-vr.netlify.app/ work well, it has an active maintainer, and it's what Brightcove's current player uses.

We're getting a few OTRS tickets about this, a note in Tech News or on wikitech-l would have been appreciated.

I looked through my IRC logs and found the most recent complaint: a 7.5 MiB API upload with the error

Request from - via cp3058.esams.wmnet, ATS/8.0.7
Error: 502, Server Hangup at 2020-06-24 18:23:02 GMT

That user was connected to IRC over a Hurricane Electric IPv6 Tunnel Broker, and was eventually able to upload the image after multiple retries.

For dynamic media like videos and 3D files, two different pieces of software are required. One is the thumbnailer, which turns the dynamic media into a static image. That's currently done by rTDTP 3d2png. The second is the client-side dynamic viewer, which allows users to view and interact with the dynamic content. That's currently implemented by Extension:3D as a part of MediaViewer. Both depend on https://threejs.org to do the actual heavy lifting of rendering 3D files with WebGL. Using the same library in both applications is important to reduce the visual difference between the static and dynamic versions and so that editors have a stable platform to work with.

Could not reproduce. Please provide at least the following information:

• Operating system
• Python environment and version (import sys; print(sys.version))
• Pywikibot version (import pywikibot; print(pywikibot.__version__))
• Relevant code or command used, including the chunk size configuration
• Complete logs of upload attempt (VERBOSE-level or lower preferred)
• Hash of the file that could not be uploaded

It would also be very useful if you could provide the request and response headers for the failed chunk upload, including the exact size of the chunk. Information about if the file appears in Special:UploadStash would also be helpful.

@Unlight123: The Wikimedia Foundation recently made the decision to restrict the usage of maps.wikimedia.org to Wikimedia sites and closely-affiliated websites. The ukc.gov.ua website does not appear to be closely affiliated to the Wikimedia projects, and is accordingly no longer able to use the maps.wikimedia.org service. While this is unfortunate, access to maps.wikimedia.org from ukc.gov.ua is unlikely to be restored. The operator of that website should choose a different tile server.

I have seen a few similar complaints in the past, always on a moderately-sized file (nowhere near 100MiB) and with someone on a slower connection. I've never been able to reproduce the issue with software throttling (it either works or I time out before the upload does). As a workaround, you should be able to use https://commons.wikimedia.org/wiki/User_talk:Rillke/bigChunkedUpload.js to upload new versions as chunked uploads. Because the chunks are smaller, they are less susceptible to network issues and timeout problems.

This limit only applies to new thumbnails that have not been previously generated and cached. Thumbnails that have already been generated are served from the cache or file storage and are not affected by the same limits. This means that refreshing the page will often generate most of the remaining thumbnails.

It appears to be working correctly to me.

T154237: SVG image wikisyntax can't use "lang=zh-hant" has indicated that this update may introduce a regression in the handling of some languages in <switch>-translated SVGs.

Tested on beta commons, patch works as intended. Should be deployed to Commons via the train on Wednesday.

Debian font packages used by MediaWiki and Thumbor are installed from rOPUP modules/mediawiki/manifests/packages/fonts.pp.
Installing those packages in a fresh local Docker container nets the following results:

The filename mentioned is for https://archive.org/details/worksrobertging21ingegoog.

GET https://commons.wikimedia.beta.wmflabs.org/wiki/Special:UploadStash/thumb/17u5na7o73s0.tjfqsy.7675.svg/120px-17u5na7o73s0.tjfqsy.7675.svg.png?0.3363587637054679=

Fixed in librsvg 2.44.10.

not fixed in current (2.50.1) librsvg.

Fixed in librsvg 2.50.1 or earlier, not fixed in 2.44.10