Working With MediaWiki

“Essays” category; and you would add to that template the “__APPROVEDREVS__” behavior switch, so that it was added automatically to every such page.
    Approved Revs also defines a new special page, Special:ApprovedRevs, that provides several lists of pages: all pages that have an approved revision, all the ones that don’t, and all the ones whose approved revision is not their latest.
    You can read more about about Approved Revs on its homepage:
https://www.mediawiki.org/wiki/Extension:Approved_Revs

15  MediaWiki administration
    Administering a MediaWiki wiki is generally not that hard, once you’ve done the initial setup. It involves both actions done via the web interface, and actions done on the back end, like editing LocalSettings.php and installing extensions. Usually there are just one or a handful of people with access to the back end, and the same or a slightly larger group of people with administrative access on the wiki itself.
    This entire book is geared in large part toward MediaWiki administrators, so in a sense most of this book could be fit under the topic of “MediaWiki administration”. But this chapter is meant to hold some of the tools and actions that are relevant only to administrators, that didn’t fit in elsewhere.

Configuration settings
    There are many settings for core MediaWiki that can be modified in LocalSettings.php — essentially, all the variables that start with “$wg”. Some are covered in this book, though it’s a very small percentage of the total set. You can see the full listing here, grouped by functionality type:
https://www.mediawiki.org/wiki/Manual:Configuration_settings
    Here are some of the more useful ones, that aren’t mentioned elsewhere in the book:
$wgCategoryPagingLimit — sets the maximum number of pages listed in every category page; default is 200
$wgReadOnly — sets the entire wiki to be read-only, with the specified string given as the reason; useful for temporary site maintenance

Debugging
    MediaWiki is software, and software unfortunately can go wrong. The issue may be file directory permissions, database user permissions, missing files, missing database tables, bad settings in LocalSettings.php, incompatible versions, or even (perish the thought) bugs in the code. (Which, by the way, are much more likely to happen in extensions than in core MediaWiki.)
    Generally, the source of the most confusion in MediaWiki comes when users see ablank page in the browser at any point while on the wiki. This happens if there’s an error, and if PHP is configured to show a blank page, instead of the error message, when that happens. It’s almost always better to see the error on the screen; so if that happens, the best solution is to add the following line, either to LocalSettings.php or to PHP’s own php.ini file:
ini_set( 'display_errors', 1 );
    If it’s being added to LocalSettings.php, it should be near the top of the file, right under the “    If you want to do any kind of debugging, and you’re using version 1.19 or later of MediaWiki, by far the best tool to use is the MediaWiki debug toolbar. It puts all the necessary information (SQL calls, warnings, debug displays) in one easily-accessible place at the bottom of the browser. For those of us used to having done MediaWiki debugging the old-fashioned way, it’s a remarkably useful tool. You can enable it by adding the following to LocalSettings.php:
$wgDebugToolbar = true;
    However, you may not want everyone to see the debugging toolbar, during the time it’s enabled (if you enable it, everyone will see it). Or it may not be available, if you’re using a version of MediaWiki before 1.19. In either case, there are other options. If you see an error message that contains the text "(SQL query hidden)", and you want to see the SQL that was called, you can see it by adding the following to LocalSettings.php:
$wgShowSQLErrors = true;
    And if the error that’s happening seems to be complex, you can turn on MediaWiki’s own debug logging, and then examine the contents of that file. To turn it on, add the following to LocalSettings.php:
$wgDebugLogFile = "/full/path/to/your/debug/log/file";
    This file needs to be writable by your web server.
    Often, the easiest solution, as with a lot of software, is just to do a web search on the text of the error message — it could well be that others have come across, and maybe diagnosed, this problem. If you believe that the problem is coming