Open main menu

lensowiki β

Help:Administration

Revision as of 05:34, 19 July 2006 by Wadmin (talk | contribs) (1 revision(s))

  Administrators are wiki users who have "sysop rights". The wiki software has few features whose use is restricted, but they are quite important.

Administrator tools

Protection

Administrators can edit protected pages and protect and unprotect pages. Protection of a page means that a non-admin cannot modify it.

Procedure

  • To protect a page, click the protect tab. In the monobook skin, the shortcut alt+= can alternatively be used. This will lead to a confirmation screen with two menus and a checkbox. In the menu, the administrator can choose to protect the page from editing by unregistered users or all users. Similarly, the page can be protected from moves by either unregistered users or all users (the system automatically adds the same level of protection to moves as it does to edits, but the protection level can be changed by checking the "Unlock move permissions" checkbox). Enter the reason for page protection in the box and press "confirm." This will be logged.
  • To unprotect a page, click the unprotect tab. This will bring up the exact page as above, only this time the two menus will already be selected. Unprotection only involves selecting "(default)" under the "Edits" menu and pressing confirm. A reason for unprotection should be given as well. This action will likewise be logged.

Notes

  • MediaWiki namespace: Only sysops can edit pages in the protected MediaWiki namespace, which contains the interface messages (such as the blocked text, tab text, et cetera).
  • Editing: To edit a previously protected page as an administrator, just click the edit tab. The only difference now is that there is a warning at the top of the page indicating that the page has been protected, but it can be edited like any other non-protected page.
  • Images: Protecting an image is mostly the same as protecting a page (see above). When the protect tab is clicked on the image description page, both the page and the image are protected. The image description page will be protected, and non-sysops will not be able to revert the image to an earlier version, or upload a new version over it.

Deletion

Administrators can delete pages and their history, and can view and restore deleted pages and their history. They can also delete images, which can be undeleted as normal.

Procedure

  • To delete a page, click the delete link on the page that is to be deleted. If an administrator is using the monobook skin, the shortcut alt+d can alternatively be used. This will bring up a new page asking for a confirmation that the page should be deleted, as well as an explanation of the deletion. A message should be typed into the input box to explain the deletion to other users. After the page has been deleted, it might have an existing talk page which should be deleted as well. Any links that point to the deleted page should be removed or corrected—whichever is the most appropriate action.

  • Pages can be undeleted for as long as they are in the archive. This archive is occasionally lost in database crashes. If a page has not been recreated since it was deleted, there will be a message on the page indicating how many deleted revisions there are. Clicking on this (or the undelete tab) will bring up a page displaying all the deleted revisions which can each be looked at separately. To undelete a page, click the restore button which appears on the confirmation page; this will restore all deleted revisions by default. Undeletion occurs as soon as the button is clicked, and will be logged just like deletions; if some revisions are not restored, the log will record how many were restored.

    If a page already exists but an administrator wants to restore previous revisions, the administrator must go to the page history. There will be a link to undelete as described above.

Notes

  • Delete revisions: To only delete a few revisions from the history, delete the article normally, then begin the undeletion procedure. Before clicking the "Restore" button, check the revisions you want to restore—all others will remain deleted. To delete one version of an image, click the (del) link beside that version under the "File history" heading. The most recent version cannot be deleted without deleting all previous versions.
  • Merge edit histories: the edit histories of two articles may be merged into one. To merge histories, delete the page where all the histories are supposed to be restored. Move the other page to the page just deleted, and then restore all the deleted revisions. This cannot be manually undone, and it is very difficult to split edit histories.
  • Split an edit history: To split an edit history, manually delete all revisions, then restore those belonging to one article (which may be difficult to recognize). Move the undeleted page to a new title to split off those revisions. Restore the revisions belonging to the deleted page (now a redirect), then revert to a the penultimate revision (before the redirect).

Rollback

Any user can revert a page by going back through the page's history. Administrators have a rollback button to expedite the process. To revert the edits of one user to the last version by the previous editor, click rollback on the page history, the user contribution list, or on the diff page. The reversion will be marked as a minor edit and given an automatic edit summary based on the contents of MediaWiki:Revertpage.

Sysops can hide vandalism from the Recent Changes page. To do this, add &bot=1 to the end of the url used to access a user's contributions. For example, ...index.php?title=Special:Contributions&target=Username&bot=1. When the rollback links on the contributions list are clicked, both the revert and the original edit that you are reverting will be hidden from the default Recentchanges display. This mechanism uses the marker originally added to keep massive bot edits from flooding recentchanges, hence the "bot". These changes will be hidden from recent changes unless you click the "bots" link to set hidebots=0. The edits are not hidden from contribs, history, watchlist, etc. The edits remain in the database and are not removed, but they no longer flood Recentchanges. The aim of this feature is to reduce the annoyance factor of a flood vandal with relatively little effort.

Block and unblock

Sysops can block and unblock IP addresses. IP blocks expire after 24 hours.

Procedure

  • To block a user (either an IP address or a registered user), click the block link that appears next to the user on recent changes. Alternately, click the block user link on the sidebar when visiting the user's userpage or talk page. This brings up Special:Blockip, where the name of the user is already filled in. Select a duration from the menu, or fill in a custom value using units described by the tar manual. Indicate the reason for blocking the user, and click the Block this user button. All blocks are logged and the user will appear in the list of blocked IP addresses and usernames until the block expires.
  • To unblock a user, find the user in Special:Ipblocklist, find the user to unblock, and click the unblock link. Alternately, manually visit the URL ...index.php?title=Special:Ipblocklist&action=unblock. This will have a confirmation page where the reason for the unblock can be filled in. This action will be logged and the user will be immediately unblocked. If a range is blocked, then unblock must cover the whole range. It isn't possible to unblock a specific IP from that range.

Notes

  • Username blocking is not enabled by default. It can be switched on by setting $wgSysopUserBans=true; in LocalSettings.php. Unless this is done, you will get an error message telling you the 'IP Address does not exist.' Note: set this code at the bottom of the script; it does not work placed right at the top. Nonexistent usernames can also be blocked, so be certain you have the correct username.
  • To block ranges of IP addresses, see m:Range blocks.

Database queries

Sysops can run read-only queries on the database.

Making sysops

Users with "bureaucrat" status can turn other users into sysops (but not remove sysop status). Bureaucrats are created by developers.

(Note that the following applies to version 1.5; I don't know about earlier versions.) The configuration script which runs when you first access your newly installed MediaWiki creates the first account, and automatically gives it "bureaucrat" and "sysop" status. To grant "bureaucrat" status after installation, a developer, or someone with developer skills, needs to directly manipulate the database records within MySQL.

Signed-in privileges

Users with ordinary access, including visitors who haven't "signed in", can still do many things, including the most important: editing pages and helping with maintenance tasks. But only signed-up users can upload files or rename pages.

See also

Retrieved from "http://www.lensovet.net/~sysadmin/w/index.php?title=Help:Administration&oldid=1416"