Wed, Mar 14
I've given the error handling some more thought and am not convinced we need to (attempt to) roll back the upload, should submitting captions fail.
Here's what could go wrong submitting captions:
Mon, Mar 12
The caption was not displayed on that screenshot since it's currently implemented as optional - that's how the description widget already worked.
I've just changed it now so it always show an input, even if not required - empty input will just be ignored.
Wed, Mar 7
Pam: does this look alright?
Tue, Mar 6
Well, the timing of this ticket & the recent changes to the license dropdown code is suspicious, but I don't think it's a regression.
The code that pulls the info from the message has not changes, and when I checked out the old code on my local machine, it worked just the same before.
I actually did change something: the filedesc header will always be added now, but up until recently, when !$wgUseCopyrightUpload && $license === '', there would be no filedesc header, just the comment (although it was very often added in there anyway - as evidenced by this ticket). So depending on input & config, there could be no filedesc header.
On Commons, uploads without license (that didn't already include the header in the comment) would not have that header up until recently.
Mon, Mar 5
As I understand it, Twitter currently:
I know incorrect rejections are irritating & a loss of time, but there's no ill will, just everyone trying their best to keep the backlog manageable.
It happens that we take a look at something and fail to realize exactly what happens and mislabel it as invalid...
Fri, Mar 2
I assume we can resolve this - please re-open if not!
Can we get more memory available and/or should we consider limiting upload sizes?
It appears we run out of memory when the STL loader parses the file: https://github.com/wikimedia/3d2png/blob/master/3d2png.js#L115
There is 1 other file with the same issue. That one is 244MB.
Wed, Feb 28
A few questions:
- What is the minimum & maximum length for caption input? (descriptions, right now, are expected to be between 5 and 10000 characters)
- Is a caption required? (a description, right now, is required)
- If required: are there cases where it may not be (descriptions right now are not required for certain campaigns)
- Metadata descriptions or Flickr descriptions are currently being pulled into the descriptions input - do we want to move any of those to captions?
Thumbnails for images should be displayed immediately (the browser just needs to re-use the upload file).
Thumbnails for STL files need to be generated and take a little longer - especially with a batch this large & on beta :)
Tue, Feb 27
Mon, Feb 26
Since allowing 3D uploads, we've added a "Patent permissions" radio button group just above the Licenses dropdown.
These get hidden by default until a user uploads an .stl file, in which case it'll get displayed.
I'm guessing that is why some non-3D uploads get that template...
There is a new revision (Feb. 5) since the last comment here.
- the full-sized file has lights on
- the main thumb and 1.5x & 2x srcset thumbs have lights on
- new thumbnails (in uncommon sizes) have lights on
- (!) all "Other resolutions" suggestions 135 × 240 pixels | 270 × 480 pixels | 337 × 600 pixels | 432 × 768 pixels | 576 × 1,024 pixels | 2,322 × 4,128 pixels: Lights off!
This was fixed with https://gerrit.wikimedia.org/r/#/c/410458/
Fri, Feb 23
Thu, Feb 22
Yeah, that was going to be part of wmf.22
This has been deployed.
Existing embeds may not work until the cache gets refreshed, but I believe I just purged all of them.
Wed, Feb 21
Tue, Feb 20
Mon, Feb 19
rMWe8ca20e84bae didn't cause the issue.
It's caused by a combination of things:
- Special:UploadWizard extends from Special:Upload (as no-JS fallback), without the relevant (core) JS
- Which eventually leads to incomplete Special:Upload JS being loaded
Feb 15 2018
- 3D uses a hook to adds some things to SpecialUpload (for patent)
- UploadWizard extends from SpecialUpload form, to provide a no-JS fallback
- UploadWizard overrides all other JS & config, but not the one added in from 3D
- UploadWizard pulls in the 3D code for Special:Upload
- Which in turn pulls in the special upload JS
- But that one is lacking the relevant config to make it work
It could be anything from being available immediately to taking a while to load/fail (generating/slow connection) to failing right away (rate limited, other issue).
It's not unlikely that a thumb is not immediately available right after upload, which is why we wanted to show a placeholder instead (T183310)
Feb 14 2018
Support for 3D (STL) files is live on Commons. Assigning to @Ramsey-WMF to wrap up.
Yeah, that'd also take care of that.
Should we enable 3D everywhere, so other wikis are able to display such files? (but don't enable uploads everywhere?)