Talk:MediaWiki Stakeholders' Group/Tasks/Feature wishlist/2015 assessment
MS Office File UploadEdit
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.
$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.
- 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?Edit
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.
Other and GCI studentsEdit
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 ExperienceEdit
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?
- 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 PassEdit
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|
|Media Management||6||uploads, licensing|
|Easier Installation||6||includes 'deployment'|
|Release Management||5||Consistent releases, integrate crucial extensions (Echo, VE, Flow, etc.), compatibility|
|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|
|Template Management||2||creating, sharing,|
Hierarchical File: NamespaceEdit
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.Edit
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)