@brianteeman As I value your wide knowledge on UX: Could you check the 3 "RFC" items in the Summary of Changes of this PR and let me know your opinion? Thanks in advance.

No idea what the other update packages (tar.gz, tar.bz2) are good for.

They are just alternate archive formats

@brianteeman I know what these file types are, please don't treat me as if I was an idiot.

But as the Joomla Update Component cannot unpack them, they are useless, that's what I meant.

Update: And in opposite to the extensions installer we don't have an "Update from folder" here where they could be used.

Meanwhile I have 4 "RFC" items in the description. Feedback is welcome.

RFC 1: Should I add a configuration option to the Joomla Update Component for switching off this new MIME type check on hosts where there is some problem with MIME type detection, and extend the language strings shown in case of error or wrong MIME type by corresponding hint that this might be a false alarm on some hosts and can be switched off in the options?

I personally would say yes so we don't break updates for broken hosts.

RFC 2: Should the same check also added for files downloaded by the "Live Update" function of the Joomla Update Component?

Feel free to do that there should not be an issue as this is something we control ourself.

RFC 3: Shall such check(s) also be added to the Extensions Installer?

I would say yes with a dedicated option to switch it off. We should check whether the other file formats are actually supported there.

RFC 4: Currently all these exceptions raised in the function modified by this PRs use language strings from com_installer. These strings are currently not translated. How shall I fix it: Load the com_installer language file, or copy the strings to the com_joomlaupdate language file and rename them from COM_INSTALLER_MSG_... to COM_JOOMLAUPDATE_MSG_...?

Please use dedicated strings from com_joomlaupdate as this component should not depend on com_installer.

@brianteeman Sorry, was not offended. Regarding those other file types, I think about implementing support for them so they can be unpacked, the tar part of it is the arts, not the gz or bz2, those are easy ;-)

Option to switch the MIME type check off (see "RFC 1" in the description) will be added later to this PR when I get more feedback that it's a good idea. I personally think so, but maybe many others disagree.

The error message is very geeky. Does it really need to say anything more than "wrong file"

@brianteeman Maybe "The file type is not suitable for a Joomla update package." and "The file type could not be determined."?

And what do you think about "RFC 1" to add an option to switch off that check?

@brianteeman I've updated the language stings, also the names. Are they better now? And what do you think about "RFC 1" to add an option to switch off that check?

@HLeithner What do you think: Should I add an option to switch the new check off, like it can be seen with the diff shown by the followint link? richard67/joomla-cms@staging-add-upload-file-mime-type-check-to-joomlaupdate...richard67:staging-add-upload-file-mime-type-check-to-joomlaupdate-2

I'm not sure if this over engineering is really needed, wouldn't a simple <input type="file" accept=".zip"> be enough? I mean if someone by pass this restriction our second step will fail with an error anyway.

For fixing the untranslated language strings mentioned with "RFC 4" see PR #29899 .

I'm not sure if this over engineering is really needed, wouldn't a simple <input type="file" accept=".zip"> be enough? I mean if someone by pass this restriction our second step will fail with an error anyway.

@HLeithner Not really, there is not a useful error shown, ses issue #29764 and also here the actual result without the PR. Or which second step do you mean?

Actually if you set the accept attribute you can't select the wrong file type.

Actually if you set the accept attribute you can't select the wrong file type.

@HLeithner Again wrong. Read the description of this PR and check with Firefox: You get a pre-selected filter which you can de-select, see the screenshots in the description.

@HLeithner Sorry, I made a mistake in my previous comment: You should read the description of PR #29877 , not of this one here. It clearly tells that it is up to the browsers what they do with the "accept" attribute, and most browsers allow to bypass it.

Yes I already noticed this, my simple message is please don't break the updater because of a cosmetic thing.

all of this seems like a LOT of work to address a fairly non-existent problem. Definitely more important things to work on

@HLeithner It is not a cosmetic thing only, and for not breaking it I suggested to add the option to switch the new file type check off, and I asked you to check it. Is that not sufficient to make sure it doesn't break anything?

@brianteeman It seems to me you did read only half of the description and the referred issues.

Nope I have followed it all

Looking at getMimeType() you have a very good chance to break broken hosting setups, if you just want to get a error message popup then please do it at this dialog and not introducing a new option for our failure to do the check 100% failsafe.

I have no problem to close this PR if it is not wanted for staging. I just was asked to make that for 3.10-dev, and I thought it doesn't make sense to have it there and in 4 only. And I think if it is rejected for staging, it should also not be done in 3.10 or 4.

If someone makes a decision I am happy with it.

I only don't want to be torn apart between different opinions.

our failure to do the check 100% failsafe.

is there a 100% failsafe solution? The only thing i can think of would be not aborting but adding an warning when the mine is not matched I'm not sure whether that makes sense at the end.

If you use the exact same solution like in the update process that fails then it's at least the same problem but now it's checks the type by 2 functions that may fail or doesn't exists at all and would return false.

To make it short I don't want to have this in j3.9 and as brian said there are much more important issues in j4 to fix.

To make it short I don't want to have this in j3.9

@HLeithner I am absolutely ok with that and happy there is a decision.

@zero-24 I hope you will understand that if you want something like this PR in 3.10, I don't want to make the PR, especially not if it turns out that later it will also not be wanted in J4, because that would be very inconsistent at the end. I am ok with it if you want to make such PR, and you may use my code. I'll wait a bit with deleting the branch but will close this PR for now.

I'm not disappointed or so, all is fine. I wanna fix things and not build personal monuments.

:(

@zero-24 If George wants that for J4, too, someone could make a PR in for 3.10, but if George doesn't want it it would not make sense to do that in my opinion.