Chapter 3 Editing in MediaWiki
Tabs
In MediaWiki, nearly all page-specific actions are accessible through what are usually tabs, though it depends on the skin: in some cases the “tabs” are just links displayed on the side, and in the case of Vector, which is the default skin, some of the tab actions are dropdown links, viewable alongside the main tabs. The exact set of tabs/dropdown actions/etc. one sees depends on the type of page it is, the permissions one has, and the extensions installed. Figure 3 shows the standard view of tabs and dropdown actions that an administrator would see, for a regular page in a fictional “Algebra Wiki”, with the Vector skin (along with the search interface alongside it, and a star icon in order to watch
or unwatch the page – see here for more information on watching pages).
The “Edit” tab shows up as “View source” instead, if the user isn't allowed to edit the page, in Vector and most other skins.
We'll cover most of these actions in this chapter.
Creating and editing pages
In MediaWiki, every page's URL is also its title; there are no URLs that simply look like “?id=123456”, of the type that appear in many other content-management systems. That's important, because it means that the creation and renaming of pages can be done in a transparent way, open to all users.
The way to create a new page, and edit an existing page, are basically the same: in both cases, you first have to go to that page. How do you get to a page? For both existing pages and pages that don't exist yet, there are the same three ways to do it:
- Type in the page name in the URL
- Search on that page name, and then either arrive at the page (for existing pages), or follow the link to create it in the search results (for pages that don't exist)
- Follow a link to that page.
A link to a nonexistent page is usually called a “
red link”. By default, they're red, which easily distinguishes them from links to pages that exist, which are usually blue. The actual MediaWiki term for them, for what it's worth, is “broken link” (though “redlink” is also used, in URLs). Broken/red links are useful for indicating that a page that doesn't exist yet should be created. With Page Forms (an extension we'll get to later), you can actually have red-linked pages created automatically in certain cases – but most of the time, this has to be done manually.
Page names
For the most part, page names can contain any Unicode character. The following characters, however, are not allowed in page names:
# < > [ ] | { }
The underscore character, _, could be added to that list as well, since underscores are simply treated the same as spaces.
By default, page names always start with an uppercase letter: if a page name gets typed in that starts with a lowercase letter, it will simply get capitalized by the system. This can be changed, however, by adding the following to LocalSettings.php:
$wgCapitalLinks = false;
Page names are restricted to 255 bytes, which, depending on the character set being used, can be as many as 255 characters or as few as 63 characters. Standard Latin characters are one byte each, while most other languages' characters are represented using two or three bytes, and some archaic languages, mathematical symbols, etc. take four bytes.
Editing mode
Once you're at a page, you will see a slightly different interface depending on whether you're allowed to edit it. If you can't edit the page, there will most likely be a tab named “View source”, which lets you view the source wikitext of the page (if you're interested in doing that). If you can edit the page, on the other hand, that same tab will most likely be called “Edit” instead. In that case, to edit the page, you just have to click on the “Edit” tab, and start typing. For new pages, the tab is called “Create” instead of “Edit”, and there is usually an explanatory message on the page that includes a link to that tab, but otherwise it's the same. In all these cases, you will end up at a URL that ends with “action=edit”, which indicates that you're now in editing mode.
For existing pages, you can most likely also click “Edit” on any page section – usually, every section header will have a link that looks like “[Edit]” near it. This is quite useful – if you have a small change you want to make, it's always better to only edit the section in which it appears, because there's less text to deal with.
The edit page consists of, essentially, one big text area, plus some helper inputs at the bottom, including, most notably, the “Save page” button. The text of the page, or section, being edited goes in the big text area; it is meant to be written in a syntax called wikitext, which is simpler than HTML but which can also include a lot of scripting-like functionality (this is covered in all of Chapter 4).
The WikiEditor extension
, which is bundled in with MediaWiki, is a fairly indispensable extension that provides a nice toolbar above the editing area with support for special characters (symbols, and non-Latin characters), and other features. Figure 3 shows what it looks like, with the “Advanced” option selected, and figure 3 shows what it looks like with the “Special characters” option selected. “Special characters” provides support for entering a variety of non-keyboard symbols: accented Latin characters, symbols, and 15 other alphabets. And the other buttons provide all sorts of formatting and syntax; the “picture” icon in the top bar (the one that looks like mountains) even lets you upload an image or other file, and insert it into this page.
WikiEditor, judging from the toolbar, looks like a standard WYSIWYG editor, but it's not: what shows up in the editing textarea is still always wikitext; so that, for example, if you highlight some text and click on “B” for “bold”, what will show up in the editing area will not be bold text but rather the text you highlighted with three apostrophes on either side.
You can read more about WikiEditor here:
The WikiEditor toolbar can be customized to add additional icons and menus, using JavaScript; the “Cite” option shown in the figures is one example of such customization, used within Wikipedia. See here for documentation on how to add customizations:
Of special note also is the pen icon, which, when clicked, makes the editing area look more like a code editor, or IDE (integrated development environment) for wikitext, with line numbering, syntax highlighting, and bracket matching. This functionality is especially useful when editing templates. This icon is provided by the
CodeMirror extension
, which hooks into WikiEditor:
Besides WikiEditor, there is also the Page Forms extension, which lets you provide a form for editing, in addition to or instead of the standard edit page; this extension is covered in depth in Chapter 17.
Here is what the bottom of the edit page looks like, below the main input for the text, for a fictional “Dolphin Wiki”:

In the “Summary” field, the user is supposed to summarize their changes in the current edit; this is very useful when looking at the page history later. Clicking “Watch this page” adds this page to the user's watchlist (which we'll get to later in this chapter). “Save page” of course saves the page. “Show preview” shows what the page will look like if it's saved in its current state, while leaving the edit form underneath the preview, so that the user can keep editing. “Show changes” shows the differences between the current text and the saved page, again with the edit form placed at the bottom. It's generally a good idea to hit both of these before saving a page, to make sure that everything looks alright, and that nothing was deleted, or added, accidentally. Finally, “Cancel” is simply a link that takes the user back to the regular page.
VisualEditor
The VisualEditor extension provides WYSIWYG/WYSIWYM editing in MediaWiki.
What does this mean? WYSIWYG
, which is pronounced "WIZ-ee-wig" and stands for "what you see is what you get", simply means that the content, when being edited, looks identical, or nearly identical, to how it appears when being viewed. This has been the standard approach in word-processing applications, like Microsoft Word
or Google Docs
, for decades.
In reality, true WYSIWYG editing is impossible for MediaWiki, because its wikitext can include template calls and parser functions, two scripting-like features that, when displayed, can take almost any appearance – there's no way to mimic that display in the editing screen while still making the contents editable.
A WYSIWYG-style editor for MediaWiki, then, has to take a split approach: true WYSIWYG for regular wikitext (including handling of bold, italics, headers, tables and the like), and an alternate approach for template calls, to let users add and edit them. (The Page Forms extension, discussed in detail in Chapter 17, also provides a form-based approach for editing template calls.) Such an editor might better be described with the alternate acronym WYSIWYM
, for “what you see is what you mean”, which implies a looser connection between what's on the editing screen and what shows up on the page. Though it's less well-known, WYSIWYM is a standard approach for word-processing software (this book was in fact created with a WYSIWYM editing tool, LyX).
VisualEditor is a popular tool, and some users (especially those just starting with wiki editing) consider it essential. It is available on all Wikimedia wikis, and used widely on non-Wikimedia ones as well.
VisualEditor makes use of a library, called Parsoid
, which handles conversion from wikitext to HTML and back. There are actually two “Parsoids”: the original one, written in JavaScript, which has become retroactively known as “Parsoid/JS”, and the current one, written in PHP, first known as “Parsoid/PHP” but now simply called “Parsoid”. The original Parsoid, Parsoid/JS, added its own complexity, since it made use of the Node.js library and had to be run as a standalone service. The newer Parsoid, thankfully, is much easier to deal with. It requires no special handling to run, and it is integrated into core MediaWiki, which means that it does not need to be installed either. So VisualEditor, which used to be complicated to both install and run, is now as easy to set up as almost every other extension.
MediaWiki now contains two wikitext parsers: the standard one (simply called “the parser”), and Parsoid. The eventual plan is to switch over all parsing to use Parsoid, and at some point later to get rid of the old MediaWiki parser completely.
But back to VisualEditor. Figure 3 shows the row of tabs on the English-language Wikipedia, for users who have enabled VisualEditor in their preferences. "Edit" brings the user to the VisualEditor interface, while "Edit source" brings the user to the standard editing textarea.
Figures 3 and 3 show different aspects of VisualEditor in use, on the same article in the English-language Wikipedia: the standard editing interface, here used to edit a link (note how similar VE's display looks to standard MediaWiki page appearance), and the interface to edit a template call, here for the main infobox for the page.
Note the pencil icon at the top right of Figure 3 – it lets you toggle back and forth between VisualEditor editing and standard wikitext editing. Given that this toggle exists, there's actually no need for two separate editing tabs; and you can change it to one tab by just adding $wgVisualEditorUseSingleEditTab = true; to LocalSettings.php.
You may be wondering how the template parameters in Figure 3 each get their own help text; that is accomplished with the TemplateData extension, which is bundled in with MediaWiki.
You can read more about VisualEditor, and all its possible customizations, here:
For those who use the Page Forms extension, VisualEditor can also be embedded within textarea inputs in forms; you just need to install a helper extension, VEForAll. See here.
In addition to editing, VisualEditor can also be used to make MediaWiki's page diffs look more visual and easier to understand; see here.
TinyMCE
There is another option for WYSIWYG editing in MediaWiki: the TinyMCE extension, which uses TinyMCE, a popular JavaScript-based editing tool that is heavily used within WordPress, among other applications. TinyMCE is not as well-integrated into MediaWiki as VisualEditor is (it can't do template editing, for example), but it has certain advantages: it seems to load more quickly, for example.
Like VisualEditor, TinyMCE can be used within Page Forms forms; see here.
You can read more about the TinyMCE extension here:
CodeEditor
Some pages hold text that's more akin to computer code than to wikitext: the most obvious example is pages in the “Module” namespace, defined for the Scribunto extension (here), but there are potentially also JavaScript pages (such as MediaWiki:Common.js), CSS pages (such as MediaWiki:Common.css), and so on. The CodeEditor extension, which is bundled in with MediaWiki, makes use of Ace,
a popular open-source web-based code editor, to let you edit you such pages with tools including line numbering, syntax highlighting, and matching of parentheses and brackets. It is is very similar in concept to the CodeMirror extension (here), but it is used for pages that define code, unlike CodeMirror, which is used for pages that hold wikitext.
CodeEditor's documentation is viewable at:
Page history
The next feature available for every content page in MediaWiki is the history page. You can reach it by adding "action=history" to a page's URL query string, and, as with the edit page, it's available in most skins via a tab, and in some skins as a sidebar link. In English, the tab is called “History” or "View history", depending on the skin.
The history page doesn't usually get much attention, although it is, in a sense, the heart of MediaWiki, because being able to see the page history is what lets wikis function like wikis. Because you can always see the entire set of changes, you can open up editing of your content to any group of people, no matter how large, without fear that important data will be lost.
Here are a few rows from the history page for the article “Tandy 2000”, on the English-language Wikipedia:

Every row represents a single edit to the page, and all edits are stored permanently. (In MediaWiki nomenclature, an edit is also known as a “revision”. It's rarely called a “version”; that word is generally reserved for software.) Each row holds important information and links:
- “cur” and “prev” links, and radio buttons, for showing differences (as described in the next section, “Page diffs”)
- the date and time in which the edit was made (configured for the current user's time zone), which link to a page showing that revision
- the name of the user who made the edit, or the person's IP address if the edit wasn't made by a logged-in user
- additional links to the user's talk page and list of contributions
- sometimes, the character “m” (in English), to indicate that the person who made this edit considered it a “minor edit”
- the number of bytes in the page in this revision (for Roman letters, the number of bytes is usually equal to the number of characters, although for other languages, like Chinese, there are often three bytes per character)
- the user's own summary of the edit
- an “undo” link, for all but the earliest row (covered in the upcoming section, “Undoing”)
- a “thank” link, to send a message of thanks to the editor (provided by the “Thanks” extension, which is in use on Wikipedia - see here).
Clicking on the date/time brings you to the page for that specific revision – each one has its own permanent URL. Going to the URL for a specific edit shows you the contents of the page at that time, in addition to some information at the top about that revision:

Administrators will also see links for “block” and “rollback” within the rows of the history page. These are both covered in the upcoming section, “Blocking and rollbacks”.
Page diffs
The elements at the beginning of each row – “cur” and “prev” links (in English), and the two columns of radio buttons – are used to compare between revisions. Clicking on the “prev” link shows you the change made in this revision, while the “cur” link shows the differences between this revisionĀ and the current one. The sets of radio buttons, meanwhile, allow for precise comparison of any two revisions – the first column is meant to select an older revision, and the second column a newer revision (the JavaScript ensures that you can't select a row in the second column older than the one in the first column). Clicking on “Compare selected revisions” will display all the differences between the two revisions.
Figure 3 shows an example of one such display, from an edit made on December 8, 2019 to the article “Vickrey auction” on the English-language Wikipedia.
Colors and bolding are used to show differences. The algorithm used to determine the differences is MediaWiki's own, and it's fairly good, though not perfect. When one or more blocks of text are rearranged on the page, for example, the change is often shown as more dramatic than it actually is: it can be displayed as a massive deletion and addition of text, instead of a simple rearrangement.
Visual diffs
If you have the VisualEditor extension installed (here), you can enable page diffs to be “visual”, making use of VisualEditor's code to display the diff as a change to the HTML, which may be easier to understand for many users. Figure 3 shows how the visual diff appears for the same Wikipedia change we saw earlier. As you can see with the changed citation numbers, and the new reference at the end, visual diffs show not just the direct changes made by the user, but all resulting changes in the display. (There were some other, similar changes to the page in this diff that were snipped out, to keep the image size manageable.)
One other big advantage of visual diffs, not shown in this example, is that they show paragraph swaps as barely a change at all, by using arrows, rather than making it seem as if the user deleted a paragraph and created a whole new one.
Undoing
The "undo" link, after the edit summary, allows any user to undo that one change. An "undo" link also appears in any page showing the difference between two revisions. Not every difference can be automatically undone, though, and thus not every "undo" link will work, whether it's between a large number of revisions or just two adjacent ones. Clicking on an "undo" link that can't be performed by the system will lead to the error message, "The edit could not be undone due to conflicting intermediate edits."
MediaWiki decides whether or not a change can be undone based on whether the undo would affect any of the edits that have been done since the more recent of the two revisions. The more edits that have been done since the later revision, the smaller the chance that this change can be automatically undone. Conversely, a difference involving the current revision can always be automatically undone, whether it's back to the previous revision or to any revision before that.
If you can't undo a change automatically, you'll have to do it manually, which, for large pages, can be a painful process. In that case, using a text editor can usually make the task easier than editing the text directly within a web page.
Blocking and rollbacks
If you're an administrator, there are a few more links that you'll see on every row in the history page. Next to every username or IP address there will also be a "block" link, to block that person (see here). And, in the top row, near the "undo" link, there will also be a "rollback
" link. This is a useful link, which automatically undoes the last edit to the page, as well as any edits made by that same user directly preceding the last one; there's no need to go through a second screen. It's especially useful for dealing with vandalism, when you know without a doubt that a certain user's changes are malicious and should all be undone. It should be used with caution in other circumstances, though: if, for instance, you just want to undo the last change you made to a page, if you hit "rollback" you may be surprised to see that more than one of your edits has been reverted, potentially going all the way back to the first revision of the page. (Though it should be noted that the change done by the rollback is simply recorded as another edit, so the rollback can itself easily be undone.)
Deleting revisions
What if a person puts slanderous text, or reveals secret information, like someone's phone number, on a wiki page? Of course, you can revert the edit, but that bad text will remain accessible to anyone who views the page history, and, if it's a public wiki, it could even get linked to from elsewhere. That's a bad outcome, but thankfully there's a way for administrators to hide certain revisions altogether. In LocalSettings.php, you can add the following line:
$wgGroupPermissions['sysop']['deleterevision'] = true;
This will give the 'deleterevision' permission to all administrators. (We'll get to user groups and user permissions in the next chapter.) You can give this permission to other user groups, although having this exact line is the easiest approach.
If you add this line, any administrator who's logged in will see another checkbox on each row, and another button above the rows, reading (in English) "Change visibility of selected revisions". Selecting any number of checkboxes, and clicking the button, will bring you to a page reading "Delete/undelete revisions". Contrary to its name, this page does not actually delete anything, but rather hides certain revisions (though, as we'll see later, regular page deletions don't actually delete any content either). The interface is slightly more complex if more than one revision has been selected. Figure 3 shows the interface for one revision, and Figure 3 shows it for more than one.
As you can see, in either case, there are three things that can be hidden: the text of the revision (the most important of the three), the revision summary, and the user who made the revision. Once a revision is hidden, neither administrators nor other users will be able to see the hidden elements of that revision; though they'll still be able to see that the revision happened. If all three of the above elements are hidden, here is how that row in the page history will look:

The most recent revision cannot be hidden; the inclusion of a checkbox on that row appears to just be a mistake in MediaWiki. Once elements of a revision are hidden, that same interface can be used to unhide any of them. Because this feature is so useful, we recommend enabling it for any wiki, public or private.
Moving pages
Moving a page, in MediaWiki parlance, just means renaming it. The ability to move a page is set by the 'move' permission, which by default is open to everyone in the 'users' group, i.e. all logged-in users.
To move a page, click on the tab or dropdown action labeled “Move”. You will then see an interface like the one in Figure 3.
You can choose to either have a redirect from the old page, or not; it's recommended to have one, so that links to the old page name will still work. If there are no links to it yet, though, then it doesn't matter.
Moving a page to a title that already exists is effectively the same as deleting the other page; that's why only people with the 'delete' permission, usually administrators, are allowed to do it.
If you have a large batch of pages that all need to be renamed in the same way, the Replace Text extension (here) may be helpful.
Deleting pages
By default, administrators can delete any page (except for special pages). On a regular page, among the list of tabs, or dropdown actions, an administrator should see one that says “Delete”. Clicking on it will bring you to an interface for deleting the page in question. A page, once deleted, can't be viewed by anyone; but by default it can be restored by any administrator, with all its revisions intact; so in that sense, no content is ever truly deleted.
Deletion and undeletion
ability are governed by the 'delete' and 'undelete' permission types, respectively. So, for instance, to allow a user group to only undelete pages, you could add something like this to LocalSettings.php:
$wgGroupPermissions['articlesavers']['undelete'] = true;
Deletions definitely make sense for the case of pages created by spammers or vandals, since such pages are simply noise. And in the case of Wikipedia, deletions make sense because they render official a community decision to get rid of a certain page. (Though such decisions are sometimes overturned.) But for regular pages on regular wikis, where the contents were just considered unnecessary for some reason, blanking
a page (i.e., removing its contents and hitting “save”) is often a better strategy.
The advantages of blanking are that anyone can do it, anyone can undo it, and anyone can see what the old contents were, at any time. It's a much less severe way of accomplishing the same goal.
Edit conflicts
Edit conflicts are less common than people who don't edit wikis may think, but they do happen. An edit conflict occurs when person A saves a page while person B is still in the middle of editing that same page. When person B goes to save the page, MediaWiki will prevent the save from happening. Instead, Person B will get an error message indicating that there was an edit conflict, and they will see an interface showing both their version of the page and the latest version. At that point the user will have to manually merge their changes into the latest version.
Edit conflicts are another reason why it's a good idea to edit a section of the page, instead of the entire page – if you edit one section, and it's not the section where someone else made their change, then there's a good chance that your edit can go through without a conflict.