Last modified: 2014-09-24 01:27:16 UTC
The following file types should be added to the line application/zip in mime.types: odg odt odp ods otg ott otp ots Even the documentation contains examples using them for uploads: http://www.mediawiki.org/wiki/Manual:$wgFileExtensions
WONTFIX. Every sysadmin can decide for him/herself which uploads to $wgFileExtensions. MediaWiki by default uses a very conservative set for security reasons.
Sorry, you misunderstood me! I was in NO way suggesting to have them added to $wgFileExtensions. It is very reasonable to not add them there. The suggestion was solely to add them to mime.types, so if the sysadmin chooses to add them to $wgFileExtensions it will actually work. I don't see the reason for having the Openoffice.org type 1.x mime types listed in mime.types, while not having the OASIS mime types?
Please provide a patch.
Created attachment 5815 [details] oasis support in mime.types Here is a patch against current trunk/phase3
Applied in r47288.
This looks bogus; if added they should list their actual types (eg application/vnd.oasis.opendocument.text) not application/zip.
Fixed in r47398.
(In reply to comment #6) > This looks bogus; if added they should list their actual types (eg > application/vnd.oasis.opendocument.text) not application/zip. > What to do about oo.o 1.x format, sxc stc sxd std sxi sti sxm stm sxw stw ? According to /usr/share/file/magic (in redhat or ubuntu), it seem to be, application/vnd.sun.xml.xxx. It should also be changed accordingly? # OpenOffice formats (for OpenOffice 1.x / StarOffice 6/7) >>>50 string vnd.sun.xml. OpenOffice.org 1.x >>>>62 string writer Writer >>>>>68 byte !0x2e document >>>>>68 string .template template >>>>>68 string .global global document >>>>62 string calc Calc >>>>>66 byte !0x2e spreadsheet >>>>>66 string .template template >>>>62 string draw Draw >>>>>66 byte !0x2e document >>>>>66 string .template template >>>>62 string impress Impress >>>>>69 byte !0x2e presentation >>>>>69 string .template template >>>>62 string math Math document # OpenDocument formats (for OpenOffice 2.x / StarOffice >= 8) # http://lists.oasis-open.org/archives/office/200505/msg00006.html >>>50 string vnd.oasis.opendocument. OpenDocument >>>>73 string text >>>>>77 byte !0x2d Text >>>>>77 string -template Text Template >>>>>77 string -web HTML Document Template >>>>>77 string -master Master Document >>>>73 string graphics Drawing >>>>>81 string -template Template >>>>73 string presentation Presentation >>>>>85 string -template Template >>>>73 string spreadsheet Spreadsheet >>>>>84 string -template Template >>>>73 string chart Chart >>>>>78 string -template Template >>>>73 string formula Formula >>>>>80 string -template Template >>>>73 string database Database >>>>73 string image Image
/etc/mime.types in Ubuntu contains the following entries, application/vnd.sun.xml.calc sxc application/vnd.sun.xml.calc.template stc application/vnd.sun.xml.draw sxd application/vnd.sun.xml.draw.template std application/vnd.sun.xml.impress sxi application/vnd.sun.xml.impress.template sti application/vnd.sun.xml.math sxm application/vnd.sun.xml.writer sxw application/vnd.sun.xml.writer.global sxg application/vnd.sun.xml.writer.template stw
However, the command "file -bi" on Redhat or Linux, does return application/x-zip for those openoffice files. So, there should be an option for sysadmin to put additional custom mime.types entries. Letting sysadmin to edit the file "includes/mime.types" is not a good idea, since it will decrease the maintainability, especially when upgrading the MediaWiki software. The custom mime.types entries should be placed in a separate file. The file name may be specified in a variable, $wgCustomMimeTypes, for example.
Since "file -bi" on some Linux distribution does return application/x-zip for the zip archive, then the x-zip should also be associated with the zip archive (in addition to application/zip) in includes/mime.types, application/zip zip jar xpi application/x-zip zip jar xpi
Patch looks wrong; our mime.types map already correctly lists the OpenDocument formats with their own types, and we have detection specifically for such files. If adding the old legacy formats (as in comment 9) these should also be added with their own mime types, and detection should be added in MimeMagic::detectZipType(). (Do the old formats use the same system for embedding the mime type in the zip file header?)
(In reply to comment #12) > If adding the old legacy formats (as in comment 9) these should also be added > with their own mime types, and detection should be added in > MimeMagic::detectZipType(). (Do the old formats use the same system for > embedding the mime type in the zip file header?) > According to the magic file from redhat, the legacy formats use the same system for embedding the mime type in zip file header.
Brion reviewed the patch, so adding the "reviewed" keyword.
Hmm, blocks a bug blocked by bug 2089, I'm slightly confused but a link is needed.
