Last modified: 2011-03-13 18:04:42 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T29925, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 27925 - Timestamp for file upload
Timestamp for file upload
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-07 23:04 UTC by Subfader
Modified: 2011-03-13 18:04 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Subfader 2011-03-07 23:04:52 UTC
{{REVISIONTIMESTAMP}} and the likes only return the timestamp for last page revision, but I want to request a timestamp the last file upload date (big difference.

I suggest {{FILEREVISION...}}.
Comment 1 Krinkle 2011-03-08 10:43:00 UTC
Although I think it's fairly simple to implement, there are many magic words that could be implemented with ease, but without a good use case it would just end up with a big mess.

Can you provide an example use case for this (fictitious is okay, but real one would be preferred)
Comment 2 Subfader 2011-03-08 11:34:19 UTC
I'd use it to enable 100% proper hotlinking use of my wiki images I created a feature to copy an image to a static destination where images are never renamed or deleted
As described in #27917 https://bugzilla.wikimedia.org/show_bug.cgi?id=27917

I'd like to add the tiemstamp of teh file revision (= upload date in the history table, not the last page edit date) to ensure that files are not overwritten.

Using {{REVISIONTIMESTAMP}} does work for this case since a file re-upload creates a new {{REVISIONTIMESTAMP}}. But it's not 100% correct when the page is edited after first upload and then copied to the static destination.
Comment 3 Krinkle 2011-03-08 11:42:48 UTC
(In reply to comment #2)
> I'd use it to enable 100% proper hotlinking use of my wiki images I created a
> feature to copy an image to a static destination where images are never renamed
> or deleted

This feature is not in the wiki itself, right ? Why do you need a {{FILEREVISIONTIMESTAMP}} in the wiki articles ?

Why do you even need a timestamp for that, and if you needed, how does knowing the timestamp of the latest revision in the wiki help that ?

As for hotlinking in general, see my comment in bug 27917.
Comment 4 Subfader 2011-03-08 12:38:15 UTC
(In reply to comment #3)
> This feature is not in the wiki itself, right ? Why do you need a
> {{FILEREVISIONTIMESTAMP}} in the wiki articles ?

I pass it as URL parameter to a script that copies files in a static destination.

> Why do you even need a timestamp for that, and if you needed, how does knowing
> the timestamp of the latest revision in the wiki help that ?
> 
> As for hotlinking in general, see my comment in bug 27917.

I add that timestamp URL parameter to the filename. If the file is re-uploaded it will create a new copy instead of overwriting the previously created one.

As said, {{REVISIONTIMESTAMP}} does that too but is not 100% correct.
Comment 5 Krinkle 2011-03-08 21:44:00 UTC
I get that you add that to the filename, so you need the timestamp in your image-copy script.

Why do you need it on-wiki ?

The only page where that magic word would return that timestamp is on the file-page itself, and there the image is already shown anyway.

And for what it's worth, re-uploading should only rarely occur. In general different version of a work should be uploaded as seperate files. re-uploading is only needed (atleast on the wikis I use) to fix bugs, correct typos, etc. those kind of things. In other words: useful to not have the image link to the exact version and instead auto-correct.

Anyone else following the bug stream: What do you think about this magic word ?
Comment 6 Subfader 2011-03-08 22:47:24 UTC
> The only page where that magic word would return that timestamp is on the
file-page itself, and there the image is already shown anyway.

That's exactly where it would be needed, yes.

> re-uploading is only needed (atleast on the wikis I use) to fix bugs, correct typos, etc. those kind of things. 

Sorry, I don't want to sound too harsh but this makes no sense. You don't seem to use images much. My images don't have bugs or typos. I won't discuss with you what re-uploading images is useful for. And what your wikis are used for is not the point here.
Comment 7 Bawolff (Brian Wolff) 2011-03-09 00:25:01 UTC
If the only use case is to do some fancy templating to work with some customization that one person did to their wiki, sounds like it should be implemented as an extension. If there is a more general use case for such a magicword that's not dependant on running some form of custom code, then it'd make more sense to implement in core. So as it stands, I think this is more suited to an extension.
Comment 8 Subfader 2011-03-09 09:45:30 UTC
I agree it may not be of general use tho. Somebody feel free to close this.
Comment 9 Bawolff (Brian Wolff) 2011-03-09 23:20:33 UTC
Ok. Closing as wontfix. If anyone does come up with a general use case, please feel free to re-open.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links