Page MenuHomePhabricator

Upload Wizard gives blank templates rather than deletion log details
Closed, ResolvedPublic

Description

When uploading a previously deleted photograph from Flickr, the upload wizard gives a standard warning about the duplicate but fails to provide any details that would help the user find the deleted file in the deletion log. Clearly links like "([[:$1]])" need to be correctly substituted for the wizard to be helpful.

Event Timeline

Fae created this task.Mar 4 2020, 10:32 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 4 2020, 10:32 AM
AlexisJazz rescinded a token.
AlexisJazz awarded a token.
AlexisJazz added a comment.EditedMar 4 2020, 12:54 PM

I think it's trying to use wikicode where it should use HTML?

https://commons.wikimedia.org/wiki/MediaWiki:File-deleted-duplicate

We should probably try writing that in HTML, or maybe remove it? When I change my language to German, it works fine:

"Eine mit dieser identische Datei (File:USFS Fire Station Ground Breaking (31674568713).jpg) wurde früher gelöscht. Sieh das Lösch-Logbuch ein, bevor du sie hochlädst."

I deleted https://commons.wikimedia.beta.wmflabs.org/wiki/MediaWiki:File-deleted-duplicate and now it works on betacommons. However, same as German, links to the deletion history and COM:REFUND are not provided.

This comment was removed by AlexisJazz.
Majora added a subscriber: Majora.Mar 6 2020, 9:23 PM

This problem was originally mentioned in T200173 which was never assigned to anyone. It has to do with the special characters (in this circumstance the pipes) in the file name that cause the rendering to fail.

It is unlikely that anyone interested in UploadWizard issues will see or find this task if code project tags are missing, hence adding UploadWizard.

MarkTraceur triaged this task as Low priority.Jun 22 2020, 4:35 PM
MarkTraceur added a subscriber: MarkTraceur.

As suggested by AlexisJazz, maybe this isn't a bug in UploadWizard and should therefore be marked as Resolved or Declined and tossed back to an interface editor on Commons to fix in the wikitext?

On the other hand, it seems the call to the message in mw.ApiUploadHandler.js calls mw.Message#parse, so it's likely that the issue is the lack of argument. Perhaps if we don't receive data about the filename, we can/should use a different warning message.

In any case, marking as low given this doesn't appear to be a world-breaking bug and there's not a lot of opportunity for us to work on UW these days.

As suggested by AlexisJazz, maybe this isn't a bug in UploadWizard and should therefore be marked as Resolved or Declined and tossed back to an interface editor on Commons to fix in the wikitext?

On the other hand, it seems the call to the message in mw.ApiUploadHandler.js calls mw.Message#parse, so it's likely that the issue is the lack of argument. Perhaps if we don't receive data about the filename, we can/should use a different warning message.

In any case, marking as low given this doesn't appear to be a world-breaking bug and there's not a lot of opportunity for us to work on UW these days.

No, I was wrong. The message doesn't get parsed at all. $1 is not replaced, HTML is not replaced and wikicode is not replaced. The message is always displayed unparsed. Unless the message hasn't been customized, in that case it is parsed.

AlexisJazz added a comment.EditedJun 23 2020, 12:54 PM

When {{urlencode:foo bar}} is part of the MediaWiki message, it will no longer parse.

Actually when any parser function is used like {{#expr: 1 + 1 }} it will not parse.

MarkTraceur renamed this task from Upload Wizard gives blank templates rather than deletion log details for Flickr uploads to Upload Wizard gives blank templates rather than deletion log details.Jul 6 2020, 3:56 PM
MarkTraceur added subscribers: Pigsonthewing, Tgr.

Have updated the task to reflect that, per the merged task, this has happened with uploads that are not upload-by-URL.

AlexisJazz added a comment.EditedJul 7 2020, 5:57 PM

The message does get parsed outside of UploadWizard though: test on beta Commons.
This may be something:

mediawiki.jqueryMsg: file-deleted-duplicate: Unknown operation "urlencode"

I think I have it.

@MarkTraceur You should add something like

urlencode: function ( urldata ) {
	return encodeURIComponent( urldata );
},

to mediawiki.jqueryMsg.js.

Checked in betalabs (I do not have sufficient user rights for testing deletion in production)

  • deleted a file
  • attempted to re-upload the same file
  • got the following error message which is different from the task's screenshot (the error message still needs some improvements).

Is there a different error message in production or the steps (delete/re-upload) should be different?

AlexisJazz added a comment.EditedJul 7 2020, 9:25 PM

Checked in betalabs (I do not have sufficient user rights for testing deletion in production)

  • deleted a file
  • attempted to re-upload the same file
  • got the following error message which is different from the task's screenshot (the error message still needs some improvements).

Is there a different error message in production or the steps (delete/re-upload) should be different?

Empty your cache and try again. 😁

Also, you did successfully reproduce the bug.

@Etonkovidova - The difference is that someone locally overwrote MediaWiki:File-deleted-duplicate on https://commons.wikimedia.beta.wmflabs.org/. You did successfully reproduce the bug though. In both cases, the message is failing to be parsed.

Interestingly, I can't reproduce this bug locally, however.

kaldari added a comment.EditedAug 16 2020, 3:29 AM

It seems that if the local message includes {{urlencode:$1}}, it breaks the parsing. I went ahead and removed that part of the message on Commons for now.

It looks like most parser functions, such as {{urlencode}}, are not supported on the client-side, so there's nothing else to do here.

kaldari closed this task as Resolved.Aug 17 2020, 5:58 PM
kaldari claimed this task.