In the previous two chapters, you learned how to edit pages with wikitext, as well as how to upload images. There is a lot more that you can do with a page (or to a page). Some of the concepts have been touched on in previous chapters, but this chapter focuses on two closely related topics: what MediaWiki calls actions, and MediaWiki's approach to version control.
You've already been exposed to actions in previous chapters. Viewing a page is an action, for example, as is editing a page, moving a page, or deleting a page. Beyond that, you can perform actions such as protecting pages, reverting to earlier revisions, comparing changes, and so on.
Technically speaking, an action is invoked by passing a parameter in the URL of an HTTP GET request to MediaWiki's index.php file. There are also some activities that fall under the same conceptual category of actions that I have included in this chapter that rely on Special Pages to implement, such as importing and exporting pages. While technically not actions, these topics fit best in the context of this chapter, which is why they are discussed here.
Before we get to the actions themselves, there is some background information to review. First, you will get a very brief overview of some aspects of the HTTP protocol that you should know in order to help you understand the semantics of actions. This is followed by a more detailed look at how pages are implemented in MediaWiki, including a look at the underlying database tables and how different revisions of pages are managed. With this background information in place, you will then learn about the actions themselves, as well as how MediaWiki handles permissions and limits actions to specific user groups.
For eleven years, while I was working at a newspaper, every day there was a distinct moment when work on the content for that day's newspaper stopped and the printing and distribution of the newspaper began. This is the moment when a newspaper is published, when ink is pressed against paper. It's also the last step of a very long process of newsgathering, writing, and editing (a process that was once described by a colleague as the most remarkable series of coincidences that have to occur every day to get the paper out).
Sometimes newspaper people refer to this moment as "putting the paper to bed." There was (and is) a sense of permanence to it. For every story that appeared in the paper, the writing and editing process was completed once the paper was put to bed. While references to earlier stories or corrections to stories may appear in future editions, the story as published on that day will stay that way forever, a permanent record of the state of the world on that particular day.
Editing and content management in the world of printing presses is discrete and clearly delineated, like black ink on white paper; a wiki, more than any other kind of website, smudges those edges, leaving smears of gray. In the world of printing presses, stories are drafted, edited, and revised in an iterative process that culminates in publication. In the wiki world, there is no such thing as a draft. Every modification to the content of a page is immediately published once the changes are submitted by the author.
In MediaWiki, a page is a series of revisions. The current revision does have greater import than previous revisions, and it is the closest thing to the idea of a published, finished work, but the next revision and all the earlier revisions are always just a few clicks away. In theory, with each revision, the article should be better (except for the occasional act of vandalism), but each revision is still provisional, preserving its privileged status only until the next revision is made that replaces it.
Because MediaWiki defers all editorial oversight until after a change has been made, the ability to track, monitor, and roll back changes is of utmost importance. In order to understand how MediaWiki manages pages, you need to understand how MediaWiki manages revisions.
Content—in this case, a page—consists of a collection of revisions and variants. The term variant isn't an official MediaWiki designation, but it is one that can be used when discussing content management issues in a more precise way. One revision replaces a previous revision. A variant is another form of the same document, either in a different context or format (such as wikitext versus HTML) or in another language. Any given page can be displayed in the following variants:
In a different skin, with different navigational elements
As HTML without any navigational elements at all
As raw wikitext
In a different language
All of these different variants of a page (with the exception of the last one) can be triggered by using an action in MediaWiki.
A page is broadly divided into a content area and a navigation area (see Figure 6-1). The content area displays the content that is unique to a given page—the content that is written for an article, or was written by users. The navigation area contains a variety of different kinds of information, such as the site logo, copyright information, and links to other parts of the site. The actual layout and structure of the overall page is determined by the skin, which is composed of PHP code and stylesheets. By default, users can select which skin to use, but the name of the default skin is "monotone" (which is also the skin in use in all the screen shots used in this book so far).
Note
In Chapter 8, you will learn how to customize the skin for your requirements.
While the skin determines the layout of the page, it does not control the text that is displayed. Bear in mind that MediaWiki is designed to be a multilingual site, which means that all the content in the navigation area of the page is dependent upon the language in use at the site. The default language of a site is determined in LocalSettings.php, but it can be overridden in user preferences. All the screen shots thus far have been in English, but they could easily be changed to French, German, or even Hebrew, by modifying your preferences. This chapter does not go into much detail about language localization.
When you visit a page, you are actually viewing the current revision of the page. While the default behavior is to view the current revision, the default behavior can be overridden, making it possible for any user to view any version of a page as long as the user knows the revision ID of that page. This enables the user to view the history of the page, to roll back changes to previous versions, to find out who made what changes to a page at any given time, and so on. The following URL causes the revision of the Main Page with the ID of 1 to be displayed, rather than the current revision:
http://127.0.0.1/mysql/index.php/Main_Page?action=view&oldid=1
The version tracking of MediaWiki is not as sophisticated as what you find in a version control system like Subversion. The primary difference is that MediaWiki keeps a complete copy of each version, even when there are only minor differences between the two versions. Version control systems, on the other hand, only keep a record of the differences between two versions of a document, which saves a lot of space (and network traffic). Old versions of pages can be compressed when archived, but that is still not quite as good as version control (arguably, it doesn't really matter, as storage space is cheap, but it does seem inelegant, at least).
For a typical page, three different tables track its current state: page, revision, and text. (If you chose to use a prefix when installing MediaWiki, then the tables will be named prefix_page, prefix_revision, etc.) There is one record per page in the page table.
The following code shows the SQL used to generate the page table in MySQL, and includes the comments provided by MediaWiki developers.
The table is indexed on the page_namespace and page_title fields.
The table also tracks whether the page is a redirect, and whether it is new (which is defined as a page with only one edit), what the restrictions are for the page, and when the page was last touched. A random number is also stored in the table that is used by the Special:Random page to randomly display a page to a user. The page also maintains the page_latest field, which points to the rev_id field of the revision table, which serves as the id of the current revision. Finally, the length of the current text of the page is stored.
-- Core of the wiki: each page has an entry here which identifies -- it by title and contains some essential metadata. -- CREATE TABLE /*$wgDBprefix*/page ( -- Unique identifier number. The page_id will be preserved across -- edits and rename operations, but not deletions and recreations. page_id int(8) unsigned NOT NULL auto_increment, -- A page name is broken into a namespace and a title. -- The namespace keys are UI-language-independent constants, -- defined in includes/Defines.php page_namespace int NOT NULL, -- The rest of the title, as text. -- Spaces are transformed into underscores in title storage. page_title varchar(255) binary NOT NULL, -- Comma-separated set of permission keys indicating who -- can move or edit the page. page_restrictions tinyblob NOT NULL,
-- Number of times this page has been viewed. page_counter bigint(20) unsigned NOT NULL default '0', -- 1 indicates the article is a redirect. page_is_redirect tinyint(1) unsigned NOT NULL default '0', -- 1 indicates this is a new entry, with only one edit. -- Not all pages with one edit are new pages. page_is_new tinyint(1) unsigned NOT NULL default '0', -- Random value between 0 and 1, used for Special:Randompage page_random real unsigned NOT NULL, -- This timestamp is updated whenever the page changes in -- a way requiring it to be re-rendered, invalidating caches. -- Aside from editing this includes permission changes, -- creation or deletion of linked pages, and alteration -- of contained templates. page_touched char(14) binary NOT NULL default '', -- Handy key to revision.rev_id of the current revision. -- This may be 0 during page creation, but that shouldn't -- happen outside of a transaction... hopefully. page_latest int(8) unsigned NOT NULL, -- Uncompressed length in bytes of the page's current source text. page_len int(8) unsigned NOT NULL, ) TYPE=InnoDB;
The revision table links the page record in the page table with the different revisions in the text table. Each page has a page_id and a revision_id.
The revision table's function is primarily to serve as a link between a page record and a text record. Each page can have many revisions, but each revision is linked to only one text record. In addition to the rev_page field, which holds the page ID, and the rev_text_id field, which holds the ID of the text record, the revision table also tracks the username and ID of the person responsible for the revision, any comments the user made while making the revision, and a timestamp. If the user has designated this revision as a minor one, then that fact is tracked in the rev_minor_edit field.
-- Every edit of a page creates also a revision row. -- This stores metadata about the revision, and a reference -- to the text storage backend. -- CREATE TABLE /*$wgDBprefix*/revision ( rev_id int(8) unsigned NOT NULL auto_increment, -- Key to page_id. This should _never_ be invalid. rev_page int(8) unsigned NOT NULL, -- Key to text.old_id, where the actual bulk text is stored.
-- It's possible for multiple revisions to use the same text, -- for instance revisions where only metadata is altered -- or a rollback to a previous version. rev_text_id int(8) unsigned NOT NULL, -- Text comment summarizing the change. -- This text is shown in the history and other changes lists, -- rendered in a subset of wiki markup by Linker::formatComment() rev_comment tinyblob NOT NULL, -- Key to user.user_id of the user who made this edit. -- Stores 0 for anonymous edits and for some mass imports. rev_user int(5) unsigned NOT NULL default '0', -- Text username or IP address of the editor. rev_user_text varchar(255) binary NOT NULL default '', -- Timestamp rev_timestamp char(14) binary NOT NULL default '', -- Records whether the user marked the 'minor edit' checkbox. -- Many automated edits are marked as minor. rev_minor_edit tinyint(1) unsigned NOT NULL default '0', -- Not yet used; reserved for future changes to the deletion system. rev_deleted tinyint(1) unsigned NOT NULL default '0', PRIMARY KEY rev_page_id (rev_page, rev_id), ) TYPE=InnoDB;
MediaWiki never deletes the text to a page on its own, so the text table contains all the different versions of the page that are in existence. The text table stores the raw wikitext, so when a page is viewed, that wikitext is rendered into HTML (or pulled from the cache). Different revision records can point to the same text record (in the event of rollbacks to a previous version, for example). When a page is rolled back to a previous version, a new revision record is created so that the entire history is preserved.
The fields in this table are prefixed with old as a legacy from early versions of MediaWiki. There are only three fields in the table: old_id, old_text, and old_flags, which mark as old the text ID, the actual text of the revision, and some flags about the nature of the content of the text field, respectively.
-- -- Holds text of individual page revisions. -- -- Field names are a holdover from the 'old' revisions table in -- MediaWiki 1.4 and earlier: an upgrade will transform that -- table into the 'text' table to minimize unnecessary churning -- and downtime. If upgrading, the other fields will be left unused. -- CREATE TABLE /*$wgDBprefix*/text ( -- Unique text storage key number. -- Note that the 'oldid' parameter used in URLs does *not*
-- refer to this number anymore, but to rev_id. -- -- revision.rev_text_id is a key to this column old_id int(8) unsigned NOT NULL auto_increment, -- Depending on the contents of the old_flags field, the text -- may be convenient plain text, or it may be funkily encoded. old_text mediumblob NOT NULL, -- Comma-separated list of flags: -- gzip: text is compressed with PHP's gzdeflate() function. -- utf8: text was stored as UTF-8. -- If $wgLegacyEncoding option is on, rows *without* this flag -- will be converted to UTF-8 transparently at load time. -- object: text field contained a serialized PHP object. -- The object either contains multiple versions compressed -- together to achieve a better compression ratio, or it refers -- to another row where the text can be found. old_flags tinyblob NOT NULL, ) TYPE=InnoDB;
In the previous chapter, when you edited a page, the text stayed the same regardless of what happened, unless it was edited again, or a page that it linked to was changed in some way. Images are a special case. Like every other page, information about the image is stored in the page, revision, and text tables. Unlike other pages, though, there is also an image table that contains information pertinent to the image file.
There are also pagelink and imagelink tables, that track which pages link to each other so that when a page changes (e.g., is deleted, etc.), all the other pages that link to it can be updated.
Most of the user interaction with MediaWiki is mediated by the index.php page. Whenever the index.php page is called, MediaWiki performs an action. The type of action is determined by parameters that are passed as part of the URL in the query string. If no parameters are passed, then the default action is view.
Many of the actions are oriented toward viewing different aspects of the page, such as the page metadata, or the raw wikitext, and so on. The rest refer to actions that are done to a page, such as editing, moving, and deleting the page.
As a user of the site, you do not necessarily need to bother yourself much with actions, other than knowing what basic things you can do to or with a page, as well as knowing how the actions are restricted to certain user groups. If you plan on doing any customization of MediaWiki, then more detailed knowledge of how the different actions are triggered is essential.
Every action is paired with a set of permissions that determines which user groups are allowed to perform the action. Out of the box, MediaWiki is set up so that anonymous users can read, create, and edit pages, as well as create their own accounts and their own talk page. As a wiki operator, you may not want anonymous users to be able to perform such operations, and you can control that by changing the settings in LocalSettings.php.
Every user must belong to one of five explicit groups:
The * group refers to all anonymous visitors to the site—basically, readers who have not logged in.
The user group represents all logged in accounts.
The bureaucrat is a special group that affords members the privilege of setting other people's privileges.
The sysop group is the primary administrative group, which is given the most powers to manipulate pages, including the capability to move pages, delete them, roll back edits, and so forth.
The bot group is designated to represent scripts that automate tasks in MediaWiki. The script logs into MediaWiki as a user in the bot group. Because most of the reason for using a bot is to make wholesale changes, it's helpful to be able to know whether a change was made by a bot or a human being. In addition, bot actions are not logged.
The following code snippet is the PHP array used by MediaWiki to track privileges. The first element in the array identifies the group, and the second element identifies what action the group member is allowed to take:
$wgGroupPermissions = array(); // Implicit group for all visitors $wgGroupPermissions['*' ]['createaccount'] = true; $wgGroupPermissions['*' ]['read'] = true; $wgGroupPermissions['*' ]['edit'] = true; $wgGroupPermissions['*' ]['createpage'] = true; $wgGroupPermissions['*' ]['createtalk'] = true; // Implicit group for all logged-in accounts $wgGroupPermissions['user' ]['move'] = true; $wgGroupPermissions['user' ]['read'] = true; $wgGroupPermissions['user' ]['edit'] = true; $wgGroupPermissions['user' ]['createpage'] = true; $wgGroupPermissions['user' ]['createtalk'] = true; $wgGroupPermissions['user' ]['upload'] = true; $wgGroupPermissions['user' ]['reupload'] = true; $wgGroupPermissions['user' ]['reupload-shared'] = true; $wgGroupPermissions['user' ]['minoredit'] = true; // Implicit group for accounts that pass $wgAutoConfirmAge $wgGroupPermissions['autoconfirmed']['autoconfirmed'] = true; // Implicit group for accounts with confirmed email addresses // This has little use when email address confirmation is off $wgGroupPermissions['emailconfirmed']['emailconfirmed'] = true; // Users with bot privilege can have their edits hidden
// from various log pages by default $wgGroupPermissions['bot' ]['bot'] = true; $wgGroupPermissions['bot' ]['autoconfirmed'] = true; $wgGroupPermissions['bot' ]['nominornewtalk'] = true; // Most extra permission abilities go to this group $wgGroupPermissions['sysop']['block'] = true; $wgGroupPermissions['sysop']['createaccount'] = true; $wgGroupPermissions['sysop']['delete'] = true; $wgGroupPermissions['sysop']['deletedhistory'] = true; // can view deleted history entries, but not see or restore the text $wgGroupPermissions['sysop']['editinterface'] = true; $wgGroupPermissions['sysop']['import'] = true; $wgGroupPermissions['sysop']['importupload'] = true; $wgGroupPermissions['sysop']['move'] = true; $wgGroupPermissions['sysop']['patrol'] = true; $wgGroupPermissions['sysop']['autopatrol'] = true; $wgGroupPermissions['sysop']['protect'] = true; $wgGroupPermissions['sysop']['proxyunbannable'] = true; $wgGroupPermissions['sysop']['rollback'] = true; $wgGroupPermissions['sysop']['trackback'] = true; $wgGroupPermissions['sysop']['upload'] = true; $wgGroupPermissions['sysop']['reupload'] = true; $wgGroupPermissions['sysop']['reupload-shared'] = true; $wgGroupPermissions['sysop']['unwatchedpages'] = true; $wgGroupPermissions['sysop']['autoconfirmed'] = true; $wgGroupPermissions['sysop']['upload_by_url'] = true; $wgGroupPermissions['sysop']['ipblock-exempt'] = true; // Permission to change users' group assignments $wgGroupPermissions['bureaucrat']['userrights'] = true;
As you can see from the preceding code, the sysop has the broadest level of discretion in terms of what he or she can do. If your wiki is available on the Internet, and not behind a company firewall, you should disable edits by the general public, unless you are prepared to monitor the pages intensively to identify spam. It's easily done. If you want only registered users to be able to edit pages, then you merely need to insert the following line in LocalSettings.php:
$wgGroupPermissions['*' ]['edit'] = false;
Another common permissions setting is to disable anonymous users' ability to create their own account, by entering the following line in LocalSettings.php:
$wgGroupPermissions['*' ]['createaccount'] = false;
If the wiki is on a local intranet, then the IT department may want to create user accounts, or have users use existing usernames and passwords (MediaWiki supports LDAP and ActiveDirectory). This is both a convenience item and a security item. If users are able to create their own accounts, then it makes it difficult to have a solid audit trail of changes made to the site. In many cases, you need to be able to definitively associate a user ID with a real person, and the only way to do that is to place controls on account creation.
In addition to the explicit permissions, there are two other groups, autoconfirmed and emailconfirmed.
The autoconfirmed permission refers to a security measure MediaWiki has in place to track new users and limit, to some degree, spammers. When a user creates an account, the user has limited privileges until a period of time specified by the $wgAutoConfirmAge value in LocalSettings.php. The default value is 0, which means that no time is required. The following code snippet comes from DefaultSettings.php:
/** * Number of seconds an account is required to age before * it's given the implicit 'autoconfirm' group membership. * This can be used to limit privileges of new accounts. * * Accounts created by earlier versions of the software * may not have a recorded creation date, and will always * be considered to pass the age test. * * When left at 0, all registered accounts will pass. */ $wgAutoConfirmAge = 0; //$wgAutoConfirmAge = 600; // ten minutes //$wgAutoConfirmAge = 3600*24; // one day
As this example shows, the duration is tracked in terms of seconds.
When MediaWiki was originally configured, you had the option of requiring e-mail confirmation. The emailconfirmed permission tracks whether a user has confirmed his or her e-mail address after registering.
These permission settings are from MediaWiki 1.9.3. In MediaWiki 1.10, which was released during the production of this book, additional permission settings are available. Be sure to check the latest documentation to know what's available.
View is the default action. As such, it does not necessarily appear in the URL request for the page. Recall that the URL can take two forms, so this chapter will show you two different examples of how the action view is triggered when viewing a page. The basic URL looks like the following:
http://127.0.0.1/mysql/index.php?title=Main_Page&action=view
If you are using Apache, you can have pretty URLs that drop the question mark after the index.php portion of the URL. As you will see in the following example, if you are using pretty URLs, then you have to treat the action = view portion of the URL as the very first part of the query string and prepend a ?. Web servers treat everything after the question mark as part of the query string; and even though Apache allows you to eliminate the ? for the first parameter, you still need it for those that follow.
http://127.0.0.1/wiki/index.php/Main_Page?action=view
From here on out, the examples use the plain version of the URL, as it works in all cases. You will see that the pattern action = {action word} is repeated throughout the examples.
By default, the view action displays the current revision of a page, but you also have the option of requesting a specific revision of a page. This most commonly comes into play when viewing the history of the page—MediaWiki enables you to compare different revisions of any given page, and in order to do that MediaWiki needs to be able to generate links to particular revisions. The following example shows a link to a page with a revision ID of 76:
http://127.0.0.1/mysql/index.php?title=Main_Page&action=view&oldid=76
Note that because the default action is view, you can drop that parameter and use the following equivalent URL:
http://127.0.0.1/mysql/index.php?title=Main_Page&oldid=76
View shows the page rendered along with the user interface of the wiki's skin. Sometimes you want to be able to view the raw wikitext before it is converted to HTML, and it is for that reason that the raw action exists. To view the raw wikitext of your wiki's main page, you can use the following URL:
http://127.0.0.1/wiki/index.php?title=Main_Page&action=raw
If you paste this URL into your browser, then instead of getting the complete page, you get only the wikitext, as shown in the following sample:
<big>'''MediaWiki has been successfully installed.'''</big> Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software. == Getting started == * [http://www.mediawiki.org/wiki/Help:Configuration_settings Configuration settings list] * [http://www.mediawiki.org/wiki/Help:FAQ MediaWiki FAQ] * [http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]
Sometimes you want to see how the wikitext text is rendered, but you are not that interested in having all the extra navigation and logos that surround the main content area displayed. In order to do that, you need to use the render action:
http://127.0.0.1/wiki/index.php?title=Main_Page&action=render
Figure 6-2 shows how just the content itself is rendered as HTML, and not every item on the typical page.
Editing a page is a two-step process. First, you go to the edit page, where a text field is displayed in which you can edit the wikitext. Then, once you have edited the page, you can submit the edits, which then become the current revision for that page.
On the surface, the editing action is simple enough, but some interesting things take place in the background that you need to know. First, to get to the edit page itself, you click on a URL that takes the following form:
http://127.0.0.1/mysql/index.php?title=Main_Page&action=edit
This will display the edit page. Once you are finished editing, you can submit the page, but MediaWiki needs to ensure that malicious users can't just submit edits to any page willy-nilly, so when the editing form is presented to the user, it contains a hidden field, #wpEditToken, which in the following example is set to the value of 70c50ff7beee7423276b639a3877c227. This token is then resubmitted when the user submits the edits to the page, so MediaWiki knows that it is a legitimate edit. When the changes are submitted, they are posted to the following URL (which is displayed as a relative URL, as that is how it is coded on the page:
/mysql/index.php?title=Main_Page&action=submit
The value for the token is POSTed, which is how form data is sent to a Web server. This means that it is not displayed in the URL as it is with typical GET requests. In practice, this means that some of the values used by MediaWiki are passed in the URL, while others are passed as form data.
The following is an example of the edit form generated by MediaWiki. Toward the end of the code, you can see the token:
<form id="editform" name="editform" method="post" action="/mysql/index.php?
title=Main_Page&action=submit" enctype="multipart/form-data">
<input type='hidden' value="" name="wpSection"><input type='hidden' value="20070604194308" name="wpStarttime">
<input type='hidden' value="20070601194849" name="wpEdittime">
<input type='hidden' value="" name="wpScrolltop" id="wpScrolltop">
<textarea tabindex='1' accesskey="," name="wpTextbox1" id="wpTextbox1"
rows='25' cols='80'>
Text to edit goes here
</textarea>
<div id="editpage-copywarn">
Copyright info goes here
</div><span id='wpSummaryLabel'><label for='wpSummary'>Summary:
</label></span>
<div class='editOptions'>
<input tabindex='2' type='text' value="" name='wpSummary' id='wpSummary'
maxlength='200' size='60'><br>
<input tabindex='3' type='checkbox' value='1' name='wpMinoredit'
accesskey='i' id='wpMinoredit'> <label for='wpMinoredit' title='Mark this as a
minor edit [alt-i]'>This is a minor edit</label> <input tabindex='4'
type='checkbox' name='wpWatchthis' accesskey="w" id='wpWatchthis'>
<label for='wpWatchthis' title="Add this page to your watchlist [alt-w]">
Watch this page</label>
<div class='editButtons'>
<input id="wpSave" name="wpSave" type="submit" tabindex="5"
value="Save page" accesskey="s" title="Save your changes [alt-s]">
<input id="wpPreview" name="wpPreview" type="submit" tabindex="6"
value="Show preview" accesskey="p" title="Preview your changes,
please use this before saving! [alt-p]"> <input id="wpDiff"
name="wpDiff" type="submit" tabindex="7" value="Show changes"
accesskey="v" title="Show which changes you made to the text. [alt-v]">
<span class='editHelp'><a href="/mysql/index.php/Main_Page"
title="Main Page">Cancel</a> | <a target="helpwindow"
href="/mysql/index.php/Help:Editing">Editing help</a>
(opens in new window)</span>
</div><!-- editButtons -->
</div><!-- editOptions -->
<div class="mw-editTools"></div>
<div class='templatesUsed'></div><input type='hidden'
value="70c50ff7beee7423276b639a3877c227" name="wpEditToken">
<input name="wpAutoSummary" type="hidden"
value="d41d8cd98f00b204e9800998ecf8427e">
</form>Manipulating previous versions is an important part of MediaWiki. You can view the history of pages, compare revisions, and revert to previous revisions. Figure 6-3 shows the history of a page called A New Page. You get to this page by clicking the History tab on the article page, or you can enter the following URL directly:
http://127.0.0.1/wiki/index.php?title=A_new_page&action=history
The History page displays a list of information about each revision for that particular page, each displayed on its own line. It also enables you to compare different revisions of the same page by viewing what is called a diff, a graphical representation of the differences between the two files. You can compare a page with any previous version, not just the one immediately preceding it. You can also compare two older versions.
In order to use this page effectively, it is helpful to take a closer look at the information that is displayed. Each line represents a revision, and it consists of text, links to pages with more information, and radio buttons for selecting pages to compare.
Figure 6-4 is a close-up of the top line from the previous figure. Each item is numbered to illustrate the specific meaning of each column.
This link (cur) compares the current revision (which is always the first one listed) with the revision represented by this row. The link is disabled on the first row, as it makes no sense to compare a revision with itself.
The second link in the row compares this revision with the previous revision, which is the revision in the row directly beneath it.
The date reflects the date on which that particular revision was made, and if you click on it, you are taken to a page that displays the revision. Whenever you view an earlier revision of a page, the user is notified at the top of the page that they are reading an earlier version of the document so that they will know they are potentially reading outdated information.
This is the user who created the revision.
The next three links all contain information pertaining to the user who created this revision. There is a link to the Talk page for this user, a link to a list of this user's other contributions, and a link to a page that enables you to block this user from making additional revisions (see the section called "Blocking" later in this chapter).
The
msignifies a minor edit.The comments made by the user when submitting the edit are displayed here. It's a good idea to have a policy regarding what kind of comments users should place here when submitting an edit. When the user describes the edit in some detail, it can make it easier to review. For example, if all you did was fix the spelling of one word, then it is helpful to note that fact in the comments so that the next reviewer will know what was changed.
In addition to the links, there are radio buttons you can use to make an ad hoc selection. The left radio button selects the earlier of the two revisions to be compared, while the right radio button selects a more recent revision.
When you compare pages, you are taken to a page that displays a diff. Links to view the diff look like the following:
http://127.0.0.1/mysql/index.php?title=A_new_page&diff=111&oldid=107
The first parameter, diff = 111, refers to the current revision, and oldid = 107 refers to an earlier revision. In terms of radio buttons, the oldid refers to the earlier of the two revisions, which is the radio button in the left-hand column.
The program used to generate the diff is set in LocalSettings.php. Figure 6-5 illustrates a diff as displayed by MediaWiki. The left column represents the earlier revision and the right column represents the more recent revision. The page does not show the complete content from both pages. Instead, it shows the lines where differences exist, plus some additional context that includes the preceding line.
Lines of text preceding by a minus sign (−) are lines that have been deleted (it is displayed in yellow if you are using the default skin). Lines of text preceded by a plus sign (+) are lines that have been added. In this example, line 7 was modified between the two revisions. In the earlier revision, it said, "Not to be outdone, I'm adding a fifth revision." In the later of the two revisions, it says, "Not to be outdone, I'm adding a fifth revision. A minor change." The diff program treats this as if line 7 were deleted from the earlier revision and a new line 7 was added in the more recent revision. The program is smart enough to know that the two lines share a lot of the same text, so only the actual new text is highlighted in red—the phrase "A minor change."
The other links on the page work just like the links on the History page. There are some additional links as well, which are used to revert to previous versions. There are three different ways to return to an earlier version of a page: rollback, revert, and undo. They all do basically the same thing, but in modestly different ways. Here are the definitions:
Undo: Makes the most recent previous revision the current revision
Revert: Makes any earlier revision the current revision
Rollback: Eliminates any edits made by the last user to a page, so that the page that existed prior to that user's edits is once again the current page. From a practical perspective, the purpose of a rollback is to revert a page back to its state prior to being vandalized, which is why you would want to wipe out a series of edits by a user. This privilege is limited to sysops by default and is available from the History page.
Both undo and rollback are triggered by clicking on their respective links. In order to revert to an earlier page, you click the Edit link on the diff page. When you click the link to edit the page, you are taken to the edit page. The edit page displays the following warning: "You are editing an out-of-date revision of this page. If you save it, any changes made since this revision will be lost." You can make any changes you want (or no changes at all) and then click the Save Page button, and this revision will now become the current revision for the page.
The process of returning a page to an earlier revision suffers to some degree from a lack of clarity in the terminology MediaWiki uses to describe the action. In some cases, the interface uses the word revert and in others it uses rollback, and the online documentation isn't particularly helpful in clarifying the difference between reverting to an earlier revision, rolling back to an earlier revision, or undoing to an earlier revision.
The delete action deletes the page's record from the page table and inserts the relevant information into the archive table. The text and revision tables are not changed. This makes it possible to restore deleted pages using the Special:Undelete page.
The process is similar to editing and submitting changes to a page. When a page is to be deleted, a form is presented asking for confirmation. When the user submits the form, a token ($wpEditToken) is passed back to the server.
Deleting files and images works differently than deleting pages. By default, deleted files are truly deleted, but you can configure MediaWiki to save versions of files as well. You need to set $wgSaveDeletedFiles to true in LocalSettings.php, and you need to assign the directory in which the deleted files will be stored by setting it in $wgFileStore as follows, replacing directory with the name of the directory in which you want the files to reside:
$wgFileStore['deleted']['directory']
When you move a page, all you are doing is renaming the page. In the page table, the name is changed, but the page ID isn't changed. This allows the history of the page to remain intact. A new redirect page is created with the original name of the page so that any links to the old name are automatically redirected to the new page location. There are a few important things to keep in mind when moving pages:
Image or category pages cannot be moved.
You should always move a page, rather than simply cut the content from one and paste it into another, because it loses the page history. In some cases this is more important than others—for instance, the license under which Wikipedia content is released requires acknowledgment of all contributors, and the history is how the contributors are tracked.
Moving it back to the original name will result in a warning because it requires the deletion of the redirect page that is created upon the move.
If you change your mind and want to change the name back to what it was, you need to move the page back instead of undoing it or rolling it back—undo and rollback do not work for moves because of the way in which a page's revision history stays connected to the moved page. One confusing aspect of MediaWiki is that you can also go to the log page for the move (click View Logs from the History page). There will be a link called Revert that moves the file back to the original name.
The purge action is one that can be particularly helpful to Web developers. It clears the cache of a page. Most of the other actions are usually triggered by following a link on a page produced by MediaWiki, but this is one of the rare examples of an action that is usually triggered by manually appending the action information to the end of the URL. The following example shows the URL needed to purge the cache for the main page of your wiki:
http://127.0.0.1/wiki/index.php?Main_Page&action=purge
If you are not logged in, then you will get a form that asks for confirmation before MediaWiki clears the cache; and only then will the cache be purged.
The protect, watch, and patrol actions are related in that they are three different ways that administrators can monitor context on a wiki and ensure that the content is appropriate for the site.
Protect and Unprotect use $wpEditToken to verify that the request is a valid one. You can set protections against editing and moving a page. You have the option of using the default, restricting unregistered viewers from editing and moving the page, or limiting the ability to edit and move the page only to sysops. Wikipedia uses this feature to protect pages that are particularly controversial and subject to a great deal of vandalism. By limited edits and moves to sysops, access is limited to only trusted members of the community.
These actions place or remove the page in a user's watchlist. If the page is already in the list, then it is removed. You toggle the value indicating whether a page is watched or not by clicking the Watch tab (labeled Unwatch if the page is already on your watchlist). To view the pages on your watchlist, go to the special page Special:Watchlist. You can find a link to this page in the upper-right corner of the wiki page if you are logged in.
Marking a page as patrolled is limited to sysops, and this is a simple mechanism that notifies other Sysops that a page has been reviewed by a trusted figure. For example, you may decide to review all submissions for nonregistered users. If that's the case, then you will watch for any new revisions by unregistered users and read what has been posted. Afterwards, you mark the page as patrolled so that no one else will check it.
Another available option when viewing the list of revisions on the History page is to block a particular user. If you are in the appropriate group (sysop) and you find that a user is making inappropriate edits, you may elect to block that user. To do so, you can click the Block link and you will be taken to the Block User page, illustrated in Figure 6-6.
As you can see in Figure 6-6, you can block a user for a particular period of time. The drop-down menu provides options ranging from two hours to an infinite amount of time, or you can select Other and enter your own duration. You can also enter the reason why the user was blocked.
You can block a user by IP address or by username. This is an important distinction, and you can fine-tune the results by setting the following values in the form:
Block anonymous users only: By selecting this option, you only block anonymous users. This is important when you are blocking an IP address because you may have more than one user coming from the same IP address and you may not want to block registered users who participate in the wiki.
Prevent account creation: When you select this option, you are denying account creation to anyone from a particular IP address (if you are blocking by username, then the user in question already has created an account).
Automatically block the last IP address used by this user, and any subsequent addresses they try to edit from: This option associates any IP address used by a particular user and blocks it. This can be something of a draconian measure because more than one user can share an IP address (and each user can use more than one IP address). Nevertheless, there may be instances when you want to do this.
You can get a list of blocked users on the Special:Ipblocklist page. Figure 6-7 shows a screen shot of this page. In this example, the user was logged into the wiki as WikiSysop, and blocked user Mchoate, selecting all of the options, including to automatically block the last IP address used by Mchoate.
If you look closely at Figure 6-7, you will see that two items are listed in the block IP list. The first is Mchoate, and the second is WikiSysop. How did that happen? Because the user logged into the wiki under both usernames on the same computer, MediaWiki followed the instructions and blocked WikiSysop because WikiSysop was using the same IP address as the user Mchoate, who was blocked.
Metadata means data about data. There are a handful of actions that are used to display data about a page, rather than the page itself: info, credits, dublincore, and creativecommons.
The info action must be enabled by setting $wgAllowPageInfo to true in LocalSettings.php. This is because it requires a lot of effort to generate. The URL for displaying page info is as follows:
http://127.0.0.1/wiki/index.php?title=Main_page&action=info
The info page tells you the number of watchers the page has, how many edits have been done, and the number of distinct authors, as illustrated in Figure 6-8.
The credits action enables you to see who is responsible for the content on a given page. The URL looks like this:
http://127.0.0.1/wiki/index.php/Main_Page?action=credits
The output of the page contains the following kind of information:
This page was last modified 16:05, 4 June 2007 by ProfWikis - MySQL user WikiSysop. Based on work by Mark Choate and Professional Wikis and Anonymous user(s) of ProfWikis - MySQL.
Two actions, dublincore and creativecommons, are closely related. Both have to be enabled in LocalSettings.php:
/** RDF metadata toggles */ $wgEnableDublinCoreRdf = false; $wgEnableCreativeCommonsRdf = true;
The dublincore action is rather simple—it causes Dublin Core metadata to be produced in the Resource Description Framework (RDF). The Dublin Core refers to a set of primary metadata terms that have been defined by the Dublin Core Metadata Initiative. The terms are simple, and you will see the basic set in the following sample output. You can learn more about the Dublin Core at http://dublincore.org.
Type in the following URL:
http://127.0.0.1/wiki/index.php?title=Main_page&action=dublincore
Instead of an HTML page being returned, you will receive an XML page that expresses the core metadata for the document in question:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rdf:RDF PUBLIC "-//DUBLIN CORE//DCMES DTD 2002/07/31//EN"
"http://dublincore.org/documents/2002/07/31/dcmes-xml/dcmes-xml-dtd.dtd">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description rdf:about="http://127.0.0.1/mysql/index.php/Page_title">
<dc:title>Page title</dc:title>
<dc:publisher>ProfWikis - MySQL</dc:publisher>
<dc:language>en</dc:language>
<dc:type>Text</dc:type>
<dc:format>text/html</dc:format>
<dc:identifier>http://127.0.0.1/mysql/index.php/Page_title</dc:identifier>
<dc:date>2007-05-30</dc:date>
<dc:creator>ProfWikis - MySQL user WikiSysop</dc:creator>
<dc:rights rdf:resource="http://creativecommons.org/licenses/by/3.0/"/>
</rdf:Description>
</rdf:RDF>The creativecommons action causes the same information to be generated, except that it includes information about the license under which the content is released, if it has been configured. In order to configure licensing information, the following variables need to be set in LocalSettings.php:
## For attaching licensing metadata to pages, and displaying an ## appropriate copyright notice / icon. GNU Free Documentation ## License and Creative Commons licenses are supported so far. # $wgEnableCreativeCommonsRdf = true;
$wgRightsPage = ""; # Set to the title of a wiki page that describes your license/copyright $wgRightsUrl = "http://creativecommons.org/licenses/by/3.0/"; # prepends 'Content is available under a' $wgRightsText = "Creative Commons Attribution-Noncommercial 3.0 License"; $wgRightsIcon = "http://creativecommons.org/images/public/somerights20.png";
MediaWiki knows about certain licenses, and will do interesting things with the licensing information you place here, if it's a license supported by Creative Commons (http://creativecommons.org).
The following licenses are available:
Creative Commons Attribution 3.0 License
http://creativecommons.org/licenses/by/3.0/Creative Commons Attribution-Noncommercial 3.0 License
http://creativecommons.org/licenses/by-nc/3.0/Creative Commons Attribution-Share Alike 3.0 License
http://creativecommons.org/licenses/by-sa/3.0/Creative Commons Attribution-No Derivative Works 3.0 License
http://creativecommons.org/licenses/by-nd/3.0/Creative Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License
http://creativecommons.org/licenses/by-nc-nd/3.0/Creative Commons - GNU GPL 2.0
http://creativecommons.org/licenses/GPL/2.0/Creative Commons - GNU LGPL 2.1
http://creativecommons.org/licenses/LGPL/2.1/
There are actually three different images you can choose from if you visit Creative Commons and look at their licenses. The image shown in Figure 6-9 is a generic image that simply says some rights have been reserved. The image chosen will appear on the bottom of all of your pages once you have configured the pages to do so.
There are many cases when you want one page to be redirected to another page. Earlier, when you learned about how to move pages, you saw that once a page was moved, a redirect page was put in place with the original name of the page that pointed to the page with the new name. This means that any links in place that still point to the old page name will automatically be taken to the current version of the page. Another example of when you would want to use a redirect would be to use more than one intuitive name to refer to a particular page.
The following is an example of a redirect page that points to the Main page:
#redirect[[Main Page]]
You might be wondering how you edit a redirect page, as every time you try to go to the redirect page, you are redirected to some other page. Fortunately, there's an easy solution. Simply append &redirect = no to the end of the URL of the redirect, and you will not be redirected, but taken to the edit page for the redirect.
You can include category tags on a redirect page, although it doesn't make sense to put any categories on the redirect page that are already listed on the target page. When you arrive at a page as a consequence of a redirect, there is a notice at the top of the page content notifying the reader that the page they are viewing is being displayed as a redirect.
It is possible to redirect to a section of a page, by appending the section anchor to the URL. Note one important side effect of doing this, however: the "redirected from" link will not be displayed on the page.
If you rename a page that is the target of a redirect, then the original redirect is automatically updated to reflect the new name of the target page. If the target of a redirect is deleted, then the original redirect is considered broken. You can check for broken redirects using the Special:BrokenRedirects page.
While technically not an action, there are two special pages that let you import and export pages on a wiki. This enables you to export a page on Wikipedia, for instance, and import it into your very own personal wiki.
In order to export the content of a page, you need to use the Special:Export page. The content of pages is exported in a special XML format that optionally contains all the revisions of the page. When you go to the Special:Export page, you are presented with a text field in which you can enter a list of page names you want exported, with one name on each line. A checkbox enables you to check whether to export all the revisions of the page. Once you have listed the pages that you want exported, click the Export button and the exported content will be sent to your browser. Save this file, and you can import it into another wiki.
In order to import a page, go to the Special:Import page, where you will be given the option to select a file to upload. Select a file that has been exported and then this file will be imported to the new wiki.
In this chapter, you have learned about different page actions that enable you to manage pages in a variety of different ways. As a wiki administrator, you can use this information to decide which groups can perform which actions to pages, as well as to get information about the page itself. The next chapter covers MediaWiki topics related to information architecture, which is the process of organizing a site to make information easier to find. You will learn about ways to manage the organization of your wiki through categories, as well as how to manage MediaWiki's search features.