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:

$wgTrustedMediaFormats[] = "application/vnd.openxmlformats-officedocument.wordprocessingml.document";
$wgTrustedMediaFormats[] = "application/vnd.openxmlformats-officedocument.presentationml.presentation";
$wgTrustedMediaFormats[] = "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet";

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)

Could you clarify how this is not sufficiently secure? Are you talking just about the .doc, .xls, and .ppt file uploads, which I stated were a security issue? Or are you also stating that .docx, .xlsx, .pptx, etc are also a security issue? --Jamesmontalvo3 (talk) 16:32, 12 May 2015 (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 bugzilla:70672 which breaks skinning and with bugzilla: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 --[[kgh]] (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)

Survey Responses First Pass

I took a few minutes to go through the 2015 MediaWiki User Survey and mush together the responses we received to the question, "What would you like to see most improved in MediaWiki the software?"

Here's what I have. Note: This wont add up to a 1-to-1 for the 137 responses we received. There were multiple suggestions per response and some blank responses. It's also probably a little subjective. When respondents said 'a better editor' I lumped that into VisualEditor/WYSIWYG.

I would encourage you to look at the raw data yourself if you have questions. Feedback and thoughts are welcome.

Summarized Wish	Count of Mentions	Notes
VisualEditor	17	easier to install, easier/less technical debt, stable releases
Skins	14	UI, developing and customizing
Access Controls	12	per page, lockdown
Upgrade Process	11	Extensions don't break, compatibility, 'one-click'
Extension Management	10	Extension discovery, installation and configuration
Auto-updates	9	Extensions mainly, one-click or automatic
Performance	7
Media Management	6	uploads, licensing
Easier Installation	6	includes 'deployment'
Release Management	5	Consistent releases, integrate crucial extensions (Echo, VE, Flow, etc.), compatibility
Anti-Spam Tools	4
Watchlist	4	auto-subscribe, subscribe others
Better/Clearer Breaking Changes	3	à la skins, hit counter, etc
Farm Support	3	Maybe just documentation?
Wiki Administration	3	WordPress-like, less hacking around in LocalSettings.php
Multi-Language Suppoert	3	Auto-discovery, defaults
Collaboration Tools	3	Talk, threads, contribution 'gamification'
Mobile Support	3	editing, reading
Documentation	2
Template Management	2	creating, sharing,
Software Stability	1
Security	1

Ckoerner (talk) 16:32, 27 August 2015 (UTC)

Hierarchical File: Namespace

It would be useful to be able to share part of the uploaded Files to Mediawiki e.g. via DropBox/Git or other file based approaches. This way e.g. a Category (or someother organizing item) could have it's own uploaded file section. Mediawiki has the image directory organized in some technical useful way these days. For endusers it would be great to have a "view" into this that is more hierarchical filesystem structure friendly way.

Example After uploading 4 files "Pictures of Presidents of the United States" there should be the option to have a directory "Pictures_of_Presidents_of_the_United_States" that contains just these pictures. Seppl2013 (talk) 16:19, 28 October 2015 (UTC)

I think I'm a little confused. How is this different than what happens when you tag media with a Category? As an example: https://commons.wikimedia.org/wiki/Category:Cymatium_lotorium

Is the idea that files uploaded from external storage (Dropbox, Git) would some how be automatically categorized? I don't know if it makes you feel any better, but WordPress, another open-source system, has had the same 'problem' for years. All media is in one giant folder - as it appears to people using the software - with a taxonomy to sort files. Ckoerner (talk) 16:13, 18 November 2015 (UTC)

Another solution to the lack of template bundling.

A solution to the lack of template bundling has been proposed at Meta:Community Wishlist Survey 2019/Miscellaneous/Shared Multilingual Templates and Modules available to all wikis, please support it. --Rob Kam (talk) 09:15, 21 November 2018 (UTC)