Developer Wishlist/2017/Extensions

CodeEditor: Migrate from Ace to CodeMirror
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 :)

Support (T50826)

 * 1) Info-farmer (talk) 05:33, 6 February 2017 (UTC)
 * 2) Ladsgroup (talk) 10:03, 6 February 2017 (UTC)
 * 3) Osnard (talk) 13:00, 6 February 2017 (UTC)
 * 4) Amir E. Aharoni (talk) 14:07, 6 February 2017 (UTC)
 * 5) &mdash;  MusikAnimal  talk  22:50, 6 February 2017 (UTC)
 * 6) Santhosh.thottingal (talk) 03:46, 7 February 2017 (UTC)
 * 7) Sunfyre (talk) 07:33, 7 February 2017 (UTC)
 * 8) Nikerabbit (talk) 08:16, 7 February 2017 (UTC)
 * 9) Yamaha5 (talk) 09:28, 7 February 2017 (UTC)
 * 10) ebrahimtalk 11:29, 7 February 2017 (UTC)
 * 11) TitusiMW (talk) 18:59, 7 February 2017 (UTC)
 * 12) Smalyshev (WMF) (talk) 17:54, 10 February 2017 (UTC)

Remove all PHP entry points from all Wikimedia-deployed extensions and skins
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.

Support (T140850)

 * 1)  ·addshore·  talk to me! 12:24, 6 February 2017 (UTC)
 * 2) Felipe (talk) 13:56, 6 February 2017 (UTC)
 * 3) Jdforrester (WMF) (talk) 16:26, 6 February 2017 (UTC)
 * 4) BDavis (WMF) (talk) 17:45, 6 February 2017 (UTC)
 * 5) SamanthaNguyen (talk) 22:14, 6 February 2017 (UTC)
 * 6)  Ricordi  samoa  11:33, 8 February 2017 (UTC)
 * 7) Calexit (talk) 21:43, 9 February 2017 (UTC)

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.

Support (T156788)

 * 1) Info-farmer (talk) 05:34, 6 February 2017 (UTC)
 * 2) ThurnerRupert (talk) 12:25, 6 February 2017 (UTC)
 * 3) Osnard (talk) 12:59, 6 February 2017 (UTC)
 * 4) BDavis (WMF) (talk) 17:44, 6 February 2017 (UTC)
 * 5) &#91;&#91;kgh&#93;&#93; (talk) 23:17, 6 February 2017 (UTC)
 * 6) Samuele2002 (talk) 23:21, 6 February 2017 (UTC)
 * 7) Info-Screen (talk) 05:55, 7 February 2017 (UTC)
 * 8) TitusiMW (talk) 19:00, 7 February 2017 (UTC)
 * 9) FFS Talk 10:41, 8 February 2017 (UTC)
 * 10) Cindy.cicalese (talk) 14:20, 8 February 2017 (UTC)
 * 11) Calexit (talk) 21:42, 9 February 2017 (UTC)
 * 12) Edward Chernenko (talk) 22:49, 9 February 2017 (UTC)
 * 13) RichardHeigl (talk) 23:08, 9 February 2017 (UTC)
 * 14) Sam Wilson 01:57, 10 February 2017 (UTC)

Problem
MediaWiki has a LTS release, which receives security updates. Unfortunately most extensions are being developed in current  or maybe latest   branch. That means that downloading an extension from  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.

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)

Support (T156640)

 * 1)  ·addshore·  talk to me! 12:23, 6 February 2017 (UTC)
 * 2) ThurnerRupert (talk) 12:27, 6 February 2017 (UTC)
 * 3) &#91;&#91;kgh&#93;&#93; (talk) 23:18, 6 February 2017 (UTC)
 * 4) Info-Screen (talk) 05:56, 7 February 2017 (UTC)
 * 5) Samuele2002 (talk) 23:28, 7 February 2017 (UTC)
 * 6) FFS Talk 10:46, 8 February 2017 (UTC)
 * 7) Cindy.cicalese (talk) 14:21, 8 February 2017 (UTC)
 * 8) Calexit (talk) 21:31, 9 February 2017 (UTC)
 * 9) Edward Chernenko (talk) 22:47, 9 February 2017 (UTC)
 * 10) RichardHeigl (talk) 23:07, 9 February 2017 (UTC)

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, 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  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

 * 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

Support (T156233)

 * 1) Consulnico (talk) 09:44, 6 February 2017 (UTC)
 * 2) &#91;&#91;kgh&#93;&#93; (talk) 23:18, 6 February 2017 (UTC)
 * 3) Samuele2002 (talk) 23:20, 6 February 2017 (UTC)
 * 4) Edward Chernenko (talk) 22:49, 9 February 2017 (UTC)

Implement addition of un-redirected pages to Special:NewPages and Special:NewPagesFeed
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!

Support (T92621)

 * 1) Iazyges (talk) 05:22, 6 February 2017 (UTC)
 * 2) --Шухрат Саъдиев (talk) 11:41, 6 February 2017 (UTC)
 * 3) Swpb (talk) 15:32, 6 February 2017 (UTC)
 * 4) Samuele2002 (talk) 23:28, 7 February 2017 (UTC)