Talk:MediaWiki Stakeholders' Group/Tasks/Feature wishlist/2015 assessment

MS Office File Upload
An anonymous editor added to the feature wishlist "Upload of Office documents (docx etc.). Security issue. Needs changes in MW core". I just want to clarify that it is possible to upload MS Office documents, though as the anonymous editor indicates there may be security issues. In my usage environment the following is sufficiently secure.

First add the file extensions ('docx', 'xlsx', 'pptx') to $wgFileExtensions. Then modify $wgTrustedMediaFormats with the following to remove the "this file type may contain malicious code" warning:

Lastly, make sure your $wgMimeTypeBlacklist variable doesn't contain "application/x-opc+zip". This setting will prevent upload of docx files. The setting was added into the blacklist, then removed at some point...so just make sure whatever you're running doesn't have it.

You may have to do additional things to make this work for .doc, .xls and .ppt files, and it may include setting $wgAllowJavaUploads to true, which would be security issue on public wikis. Personally I've decided to not support .doc, .xls or .ppt because it forces all users to upgrade documents to a newer format. The benefit of this is that MediaWiki doesn't let you upload a new version of a document with a different file extension. So if someone uploads a .doc, and I go modify it and save as .docx, I cannot upload a new version of the document. Having one file type makes it simpler.

--Jamesmontalvo3 (talk) 13:06, 10 October 2014 (UTC)
 * Note that this would not be sufficiently secure in an environment where untrusted users can upload. Jackmcbarn (talk) 13:55, 10 October 2014 (UTC)

How to deal with (un)planned breaking changes?
From time to time there are breaking changes that more or less dramatically impact on third party users of MediaWiki. Sometimes these changes come with some time advance notice (like this public/private issue for SMW last year) sometimes they come at short notice such as the recent 70672 which breaks skinning and with 71621 trying to fix it being stuck in "hell".

Probably we should establish some process there third party users may notify breaking issues/situations occurring, which are assessed in some way and reacting to it according to the assessment. This is not exactly a feature wish but a process wish, so I am putting it onto this talk page until we figure out if and where to put it.

Cheers --&#91;&#91;kgh&#93;&#93; (talk) 14:32, 20 October 2014 (UTC)

Other and GCI students
Other lists should be aggregated by someone™. It's currently a list of threads each proposing one separate thing, whichi useful but hard to read; there needs to be an aggregation where we can say that 25 % of requests are for a certain kind of thing, 35 % about another etc. --Nemo 09:17, 26 January 2015 (UTC)

First Run Experience
Can we talk a little about the first run/install action experience? I see mentions of extensions requiring often complex template/image dependencies to work optimally. There's also the already mentioned issue with an 'out-of-the-box' MediaWiki install being incredibly prone to spam accounts/content.

These are not great first-run experiences for wiki admins. Perhaps we could update the default install for third-parties to include tools to assist?

Ckoerner (talk) 20:55, 6 February 2015 (UTC)


 * There is a bug report which asks for the installer to let you configure QuestyCaptcha. At Suggestions for extensions to be integrated I propose to integrate ConfirmAccount.
 * Some things are harder, like short urls or thumb handler and so on, all supposedly trivial but very hard for the PHP application to guess correctly in all servers/contexts. I agree this stuff is incredibily important, more than big things. --Nemo 21:13, 6 February 2015 (UTC)