Extension:WhiteList/Future Development

'''This is a proposal for a significant revision of Extension:WhiteList. Please comment on these changes and feel free to propose your own ideas on the Future Development talk page. Also, please let one of the developers know if you are interested in helping to implement and/or review these changes by posting to the talk page. --Msul01 22:46, 11 November 2008 (UTC)

Overview

 * Eliminate long waits when accessing pages by caching WhiteList hits
 * Improve database response time using database table indexing
 * Eliminate use of Show/Hide ('Dynamic Navigation Bars' / 'NavFrame') on 'My Pages' list (it does not work for several users)
 * Substantial usability enhancements
 * Substantial code complexity reduction
 * Maintain capitalization order of all WhiteList variables and interface pages to be with a capital 'W' and a capital 'L'.

Restricted User Interface ('My Pages')
Listing the pages which an user may access is unacceptably slow in the current implementation. 'My Pages' takes 1-2 minutes to load for users with just a few wildcard entries, and can take much longer for users with complex WhiteLists.

The WhiteList cache will reduce time to render the 'My Pages' page to less than a second for most users. Articles will be sorted by title and namespace, rather than being grouped by wildcard. Articles matching multiple wildcards will no longer be listed multiple times. A symbol will be displayed next to pages which the user can edit (there is currently no indication of read/write permissions). Access Verification One major complaint about the current WhiteList implementation is that, for many users, it can take 10 or more seconds after clicking on a link for the link target to be displayed. This delay is due to the inefficient method of checking the target article's title against multiple wildcard WhiteList entries.

The WhiteList cache will reduce time required to check access to less than a second for most users. This will greatly improve usability of the system, and reduce frustration of restricted users which spend a great deal of time waiting for pages to load.

Manager Interface ('WhiteList Access Editor')
The list of wildcard matches can be generated by querying the wiki_whitelist_cache table for entries which correspond to the wiki_whitelist id. This will eliminate the long page rendering time observed when several wildcard entries are in the WhiteList.

Replace deprecated Manual:NavFrame CSS with supported Wikipedia:Help:Collapsing. (Note: Need to verify that support for collapsible tables is in default MW distribution.) For example:

Alternatively, remove show/hide functionality completely (or use a variable to control this functionality):

One more alternative:

Cache Maintenance
New functionality will be required to create and maintain the new WhiteList cache. Functions will automatically update the cache when an article is created, deleted, or moved. The cache will also be updated when WhiteList entries are modified by a manager. These updates are very fast and are run infrequently. If these updates do take longer than expected, they can be created as background tasks using the Mediawiki job queue.

Sysop Interface
Sysops have an additional option to allow rebuilding the WhiteList cache for one user or for all users. This allows quick recover from any unexpected problems with the caching mechanism. Optimally, such a rebuild would happen in the background by using the Mediawiki job queue functionality.

The sysop interface will also allow modification of the global WhiteLists and blacklists. This functionality will replace the current special namespace checks, except that a special check will still be required to allow editing of a user's own user page.

To-do
This extension is still actively being worked on, so there may be a number of improvements yet to come. These are updates that are not yet scheduled for a release. We would like to add these features/enhancements, but at a later date.
 * Extension should automatically create/update table structure
 * Allow exclusion of specific pages. when a wildcard is used it can pull in all of the pages needed for WhiteList acess. However, that whildcard match may also pull in one or two (or a dozen) of extra pages. The easiest way to resolve this is to allow the WhiteList access using the wildcard match, but then also allow for what effectively are per-restricted-user blacklist pages.
 * Highlight the expiry dates that have expired in red
 * When a wildcard is used to enable access to a set of pages, it may pull in one too many pages. Currently, there is no easy way to work around that. One possibility is to allow managers to also define BlackListed pages which would take precedence over whitelisted pages. This way, the manager could define a generic wildcard pattern and then also specify the couple of pages that must be explicitly blacklisted.
 * restricted users cannot upload a new image even if that image is should already be whitelisted.
 * see Extension_talk:WhiteList
 * improve support for transcluded sections
 * Support restriction of anonymous users
 * Support restriction of images