While trying to understand T273249, I followed all code
paths and found one that can result in mFinalExtension being
null: when a file is stashed, it gets a temporary name
without an extension.
This patch fixes a bunch of usages where this null might
cause type errors.
Bug: T273249
Change-Id: Ie8bd84d4637aec5a65ae8b220d9266d36873acc0
Follows-up 3d84030478. It is unclear what null should do, but
it is a fact that it used to behave similar to an empty string
within MimeAnalyzer so keep that for now, until we figure out
what to do with it.
Bug: T273249
Change-Id: Ic174253dbe019794f88bdc0f9bbe1e688dda4894
This method returns null when $mime is 'unknown/unknown' and the file
extension is unknown to MediaWiki. The inline documentation and @return
annotation omitted this.
I don't think this was an intentional design choice, but it's the
existing behavior and I'm not sure it's safe to change.
Since it is the existing behavior, document it and add a test case, to
ensure that any changes to this behavior are intentional.
Bug: T253483
Change-Id: Ie6615a4bd9ae77e9ab59cfe76edb237cace693b1
* FSFile should not be responsible for handling this much logic.
* Make more MediaHandler classes aware of the fact that an object
other than File might be passed in. Use the FSFile instead of a
useless empty stdClass object.
* Also added more fields to FSFile::placeholderProps to make it
more complete.
Change-Id: I9fe764b2a7261af507c6555e6a57273cf7d00d36
