unexpected token "match"

Yea, see http://maettig.com/2020-09-21-prepare-for-php-8. Functions named match might be one of the bigger PHP 7→8 problems we have. I started renaming some already. Here is the rest: https://codesearch.wmcloud.org/search/?q=function%20match%5Cb&files=%5C.php%24. This doesn't cover Wikia codebases, unfortunately.

Good to hear that! However, from this point on it's up to the Commons community to do this and make use of https://commons.wikimedia.org/wiki/MediaWiki:Fileimporter-post-import-revision-annotation.

I did a bit of investigation for this task. In the TemplateData extension, in TemplateDataHooks.php, there is a line $parser->getOutput()->setProperty( 'templatedata', … ) that stores a TemplateData blob in the page properties table. This code is executed after all templates are expanded, i.e. this will work with the German {{templatedata}} template.

When an existing parameter is added (and filled) to a template using the VE template dialog
When an existing parameter is edited using the VE template dialog
When a parameter which was not auto added (optional params) is added to a template
When an unnamed parameter is added to a template

It seems we need to talk about some of the terminology here.

• "Unnamed" refers to template parameters that don't have a name, but a number. For example, in {{Messagebox|Hello}} the text "Hello" is the value of the first parameter, but the parameter doesn't have a name, i.e. is "unnamed". That's the same as {{Messagebox|1=Hello}}, i.e. "unnamed" parameters are automatically numbered, but specifying that number is optional when the template is used.
  • For what this ticket here is about, there is nothing special about unnamed parameters. I don't see a need to track them separately.
• "Optional parameters" are all parameters that are not required, i.e. parameters I can remove.
• I'm not sure what "existing" refers to. "Existing" in which context?

@Lena_WMDE?

Thanks for letting me know. I had a look and was indeed able to reproduce the issue. It looks like the code that open the dropdown menu when e.g. the field is focused gets triggered in to many situations. I uploaded an alternative bugfix.

For reference, dev tools like Gerrit allow the user to decide how much context (number of lines above and below a change) they want to see.

I think what was written in the comment T198372#4380653 still applies. With T194132 we list only the first reason why a file can not be imported. But we neither list all of the templates and categories, nor can we distinguish between direct and indirect template usages. I.e. the task asking for "which template" is still unresolved, as far as I'm aware of.

Thanks for looking into this!

1. It's true, users can edit the configuration pages. However, there is a bit of protection as users need to be autoconfirmed to do this, see T202071#6520637.
2. For what FileImporter cares about there is no difference between templates and categories. I believe the question is about T256205: Add configurable template to imported file info. There is a brief description of the feature at https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Move_files_to_Commons#How_it_works. The message https://commons.wikimedia.org/wiki/MediaWiki:Fileimporter-post-import-revision-annotation is currently empty, but can be used to either add a category or template to every imported file on Commons. One advantage of a template is that you can change it without touching the message in the MediaWiki: namespace.

For reference, this is how it looks like when I merge code in PHPStorm.

Here is an example as I had it in mind (from de:Module:TemplUtl).

@Lydia_Pintscher, is it correct when we assume the following products are owned by the Wikidata team(s) and PMs? The relevant question for this ticket here is if anybody is or want's to actively watch the error channels for these projects? And if so, which team should that be?

• ArticlePlaceholder
• Cognate
• MediaWiki-extensions-InterwikiSorting

It looks like there is another FileImporter-related error happening in XMPReader:

#0 [internal function]: Wikimedia\XMPReader\Reader->char(resource, string)
#1 /srv/mediawiki/php-1.36.0-wmf.16/vendor/wikimedia/xmp-reader/src/Reader.php(373): xml_parse(resource, string, boolean)
#2 /srv/mediawiki/php-1.36.0-wmf.16/includes/media/BitmapMetadataHandler.php(214): Wikimedia\XMPReader\Reader->parse(string)
#3 /srv/mediawiki/php-1.36.0-wmf.16/includes/media/PNGHandler.php(39): BitmapMetadataHandler::PNG(string)
#4 /srv/mediawiki/php-1.36.0-wmf.16/includes/utils/MWFileProps.php(87): PNGHandler->getMetadata(FSFile, string)
#5 /srv/mediawiki/php-1.36.0-wmf.16/includes/filerepo/file/LocalFile.php(1393): MWFileProps->getPropsFromPath(string, string)
#6 /srv/mediawiki/php-1.36.0-wmf.16/includes/import/ImportableUploadRevisionImporter.php(127): LocalFile->upload(string, string, string, integer, boolean, string, User, array, boolean)
#7 /srv/mediawiki/php-1.36.0-wmf.16/extensions/FileImporter/src/Operations/FileRevisionFromRemoteUrl.php(197): ImportableUploadRevisionImporter->import(WikiRevision)
…

Similar to above:

• In BitmapMetadataHandler::PNG() is a parse() call. We could wrap this in a try-catch and just not extract metadata if they can't be parsed, but not mark the entire file as "broken" just because of this.
• There is a third one in BitmapMetadataHandler::GIF().

Yes, that's it for sure. I suggest to close this ticket here as a duplicate. Thanks for looking into this!