Developer Wishlist/2017/Extensions

From mediawiki.org
Developer Wishlist 2017
Extensions

6 proposals, 48 editors, 75 votes

The voting phase has concluded. Thanks for participating!

You can view the results or discuss how to follow up.


CodeEditor: Migrate from Ace to CodeMirror

Tracked in Phabricator
Task T50826

Has more features, is lighter (?) and has much better support for Unicode / BiDi text rendering (see http://codemirror.net/demo/bidi.html).

Plus Brion likes it :)

Endorsements (T50826)

Support (T50826)

  1. Info-farmer (talk) 05:33, 6 February 2017 (UTC)[reply]
  2. Ladsgroup (talk) 10:03, 6 February 2017 (UTC)[reply]
  3. Osnard (talk) 13:00, 6 February 2017 (UTC)[reply]
  4. Amir E. Aharoni (talk) 14:07, 6 February 2017 (UTC)[reply]
  5. — MusikAnimal talk 22:50, 6 February 2017 (UTC)[reply]
  6. Santhosh.thottingal (talk) 03:46, 7 February 2017 (UTC)[reply]
  7. Sunfyre (talk) 07:33, 7 February 2017 (UTC)[reply]
  8. Nikerabbit (talk) 08:16, 7 February 2017 (UTC)[reply]
  9. Yamaha5 (talk) 09:28, 7 February 2017 (UTC)[reply]
  10. ebrahimtalk 11:29, 7 February 2017 (UTC)[reply]
  11. TitusiMW (talk) 18:59, 7 February 2017 (UTC)[reply]
  12. Smalyshev (WMF) (talk) 17:54, 10 February 2017 (UTC)[reply]
  13. Helder 18:26, 12 February 2017 (UTC)[reply]
  14. Maybe the syntax-highlight would also be helpful in diffs? 47.222.203.135 18:38, 13 February 2017 (UTC)[reply]
  15. Just Unicode support seems enough of a reason. :) This falls under "on-wiki development", right? Nemo 18:20, 14 February 2017 (UTC)[reply]
  16. Framawiki (talk) 18:37, 14 February 2017 (UTC)[reply]
  17. Quiddity (WMF) (talk) 20:18, 14 February 2017 (UTC)[reply]

Remove all PHP entry points from all Wikimedia-deployed extensions and skins

Tracked in Phabricator
Task T140850

Once all Wikimedia-deployed extensions and skins have been switched over to extension registration, and Wikimedia production has switched over to using them, we should remove the backwards-compatibility shims that very often imply support which doesn't exist for older versions of MediaWiki.

Endorsements (T140850)

Support (T140850)

  1. ·addshore· talk to me! 12:24, 6 February 2017 (UTC)[reply]
  2. Felipe (talk) 13:56, 6 February 2017 (UTC)[reply]
  3. Jdforrester (WMF) (talk) 16:26, 6 February 2017 (UTC)[reply]
  4. BDavis (WMF) (talk) 17:45, 6 February 2017 (UTC)[reply]
  5. SamanthaNguyen (talk) 22:14, 6 February 2017 (UTC)[reply]
  6. Ricordisamoa 11:33, 8 February 2017 (UTC)[reply]
  7. Calexit (talk) 21:43, 9 February 2017 (UTC)[reply]
  8. James Martindale (talk) 17:10, 13 February 2017 (UTC)[reply]
  9. BrentLaabs (talk) 01:09, 14 February 2017 (UTC)[reply]
  10. Quiddity (WMF) (talk) 20:19, 14 February 2017 (UTC)[reply]

Improve support for read access restriction / access control

Tracked in Phabricator
Task T156788

Problem

There are a lot of extension using the userCan hook for access control. Yet there are still parts of the core where userCan is not considered. This is true in particular for read access. For example, afaik, QueryPages do not consider read access. Quite often, this is as simple as adding a userCan hook call. I'm not proposing to make Mediawiki read access bullet proof, but to fix the most obvious read access holes.

Who would benefit

Extension developers who need to implement access control for their mediawikis

Proposed solution

We can use this list as a basis: https://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions . It needs to be updated to the current state of MediaWiki. Then the open questions / issues can be addressed in the code. Ideally, at the end we have a positive list of which pages / actions consider read access.

Endorsements (T156788)

  1. The current situation is highly dysfunctional even in Wikimedia: the Wikimedia Foundation in particular is unable to manage its internal knowledge, in part because of fragmented or inadequate systems being used for lack of trust in MediaWiki as a way to hold private information. See also m:Wikimedia Foundation elections/Board elections/2013/Questions/2#Dozens WMF private wikis and "no place to work together" and m:Grants:IdeaLab/A place to work together. Because this is something that third-party users care a lot about, it would be a big win ; the Wikimedia Foundation could easily get funding from the biggest MediaWiki users maybe (think of asking 5000 $ from a few dozens companies which uses MediaWiki, have over 100 employees and would like ACL to improve internal knowledge management; they'd probably find it very good value for money). Nemo 18:26, 14 February 2017 (UTC)[reply]

Support (T156788)

  1. Info-farmer (talk) 05:34, 6 February 2017 (UTC)[reply]
  2. ThurnerRupert (talk) 12:25, 6 February 2017 (UTC)[reply]
  3. Osnard (talk) 12:59, 6 February 2017 (UTC)[reply]
  4. BDavis (WMF) (talk) 17:44, 6 February 2017 (UTC)[reply]
  5. [[kgh]] (talk) 23:17, 6 February 2017 (UTC)[reply]
  6. Samuele2002 (talk) 23:21, 6 February 2017 (UTC)[reply]
  7. Info-Screen (talk) 05:55, 7 February 2017 (UTC)[reply]
  8. TitusiMW (talk) 19:00, 7 February 2017 (UTC)[reply]
  9. FFS Talk 10:41, 8 February 2017 (UTC)[reply]
  10. Cindy.cicalese (talk) 14:20, 8 February 2017 (UTC)[reply]
  11. Calexit (talk) 21:42, 9 February 2017 (UTC)[reply]
  12. Edward Chernenko (talk) 22:49, 9 February 2017 (UTC)[reply]
  13. RichardHeigl (talk) 23:08, 9 February 2017 (UTC)[reply]
  14. Sam Wilson 01:57, 10 February 2017 (UTC)[reply]
  15. Mglaser (talk) 10:30, 13 February 2017 (UTC)[reply]
  16. Ljonka (talk) 11:04, 14 February 2017 (UTC)[reply]
  17. Nemo 18:26, 14 February 2017 (UTC)[reply]
  18. Quiddity (WMF) (talk) 20:19, 14 February 2017 (UTC)[reply]

Improve LTS support of extensions

Tracked in Phabricator
Task T156640

Problem

MediaWiki has a LTS release, which receives security updates. Unfortunately most extensions are being developed in current master or maybe latest wmf* branch. That means that downloading an extension from REL1_27 branch (e.g. by using Special:ExtensionDistributor) leaves the user with an outdated and potentially insecure codebase.

Who would benefit

Everyone who wants to use LTS version of MediaWiki and also be sure extensions that work with this version don't have security issues or severe bugs

Proposed solution

At least the greater WMF extensions like "WikiEditor", "VisualEditor/Parsoid", "FlaggedRevs", "CategoryTree", ... should get bugfix and security cherry-picks/backports from the current development into REL1_27.

Of course most voluntary, WMF-independent extension developers won't have time/will to do something like this, but maybe we can find a way to help them or at least make them more aware of the LTS release.

Endorsements (T156640)

  1. To have to vote and say this's what's expected from a steward of the ecosystem is the mind boggling part Calexit (talk) 21:35, 9 February 2017 (UTC)[reply]

Support (T156640)

  1. ·addshore· talk to me! 12:23, 6 February 2017 (UTC)[reply]
  2. ThurnerRupert (talk) 12:27, 6 February 2017 (UTC)[reply]
  3. [[kgh]] (talk) 23:18, 6 February 2017 (UTC)[reply]
  4. Info-Screen (talk) 05:56, 7 February 2017 (UTC)[reply]
  5. Samuele2002 (talk) 23:28, 7 February 2017 (UTC)[reply]
  6. FFS Talk 10:46, 8 February 2017 (UTC)[reply]
  7. Cindy.cicalese (talk) 14:21, 8 February 2017 (UTC)[reply]
  8. Calexit (talk) 21:31, 9 February 2017 (UTC)[reply]
  9. Edward Chernenko (talk) 22:47, 9 February 2017 (UTC)[reply]
  10. RichardHeigl (talk) 23:07, 9 February 2017 (UTC)[reply]
  11. Ciencia Al Poder (talk) 12:04, 12 February 2017 (UTC)[reply]
  12. Mglaser (talk) 10:30, 13 February 2017 (UTC)[reply]
  13. Osnard (talk) 11:43, 13 February 2017 (UTC)[reply]
  14. Nemo 18:26, 14 February 2017 (UTC)[reply]

Make it easier to manage/deliver files created by extensions

Tracked in Phabricator
Task T156233

Problem

There are some extensions (e.g. Extension:Math) that create files dynamically and then deliver those files to the user. Most extensions just create their files somewhere in $wgUploadDirectory, assuming that the location is accessible from the web. On private wikis this might not be true. Instead of direct delivery by the webserver the img_auth.php might be invoked. Unfortunately the current implementation sometimes makes it difficult or impossible to deliver files that are not part of the local filerepo.

Who would benefit

Any extension developer that wants to create files (images, pdfs, JNLP, xml, flat files, ...) dynamically and deliver them by a script entry point.

Proposed solution

  • img_auth.php could be improved (see also T153174: img_auth.php: Improve extendability)
  • A complete new entry point could be created
  • Some mechanism besides filerepo/filebackend could be created that allows better management (save/cache, delete/invalidate, find) of files created by extensions


Endorsements (T156233)

Support (T156233)

  1. Consulnico (talk) 09:44, 6 February 2017 (UTC)[reply]
  2. [[kgh]] (talk) 23:18, 6 February 2017 (UTC)[reply]
  3. Samuele2002 (talk) 23:20, 6 February 2017 (UTC)[reply]
  4. Edward Chernenko (talk) 22:49, 9 February 2017 (UTC)[reply]
  5. Ciencia Al Poder (talk) 12:02, 12 February 2017 (UTC)[reply]
  6. Mglaser (talk) 10:31, 13 February 2017 (UTC)[reply]
  7. Osnard (talk) 11:43, 13 February 2017 (UTC)[reply]
  8. 47.222.203.135 18:38, 13 February 2017 (UTC)[reply]
  9. Ljonka (talk) 11:04, 14 February 2017 (UTC)[reply]
  10. B20180 (talk) 13:51, 14 February 2017 (UTC)[reply]

Implement addition of un-redirected pages to Special:NewPages and Special:NewPagesFeed

Tracked in Phabricator
Task T92621

Cause pages which are converted from redirects to content pages to appear on the New Pages feeds.

Per consensus here, en-wiki's Samwalton9 activated the relevant abuse filter on March 7th. After monitoring the filter log for a week, we are satisfied that the behavior is ready to be implemented on Special:NewPages and Special:NewPagesFeed, with two caveats:

  1. Edits that revert a redirect to a prior state with content should not appear on these patrol pages.
  2. Pages where a redirect has been restored should disappear from the patrol pages, by analogy with new pages that have been deleted.

It's our understanding that this behavior can be implemented in the PageCuration extension. Thanks!

Endorsements (T92621)

Support (T92621)

  1. Iazyges (talk) 05:22, 6 February 2017 (UTC)[reply]
  2. --Шухрат Саъдиев (talk) 11:41, 6 February 2017 (UTC)[reply]
  3. Swpb (talk) 15:32, 6 February 2017 (UTC)[reply]
  4. Samuele2002 (talk) 23:28, 7 February 2017 (UTC)[reply]
  5. DGG (talk) 18:16, 13 February 2017 (UTC)[reply]
  6. TonyBallioni (talk) 03:11, 14 February 2017 (UTC)[reply]
Retrieved from "https://www.mediawiki.org/w/index.php?title=Developer_Wishlist/2017/Extensions&oldid=2397344"