Multi-user Environment in MediaWiki 1.1- A Sequel

Exclusive offer: get 50% off this eBook here
MediaWiki 1.1 Beginner's Guide

MediaWiki 1.1 Beginner's Guide — Save 50%

Install, manage, and customize your own MediaWiki-based site

£14.99    £7.50
by Jeff Orlof Mizanur Rahman | March 2010 | Open Source

In this article by Mizanur Rahman and Jeffrey T. Orloff, we will learn how to modify our profiles and change the editing preferences. It also explains how the administrators, or sysops, can view a page's history to view previous edits made to the page.

Read Multi-user Environment in MediaWiki 1.1 here.

Time for action-reverting to previous content

In our example, it appears that someone has not only changed the text for one of our pages, but someone has vandalized it as well. While one edit may be a legitimate change, as the sysop we don't want this page edited by the public, so we are going to revert to the previous page. In the case of vandalism, we have no other choice than to go back to the clean version of the page. The following screenshot shows the two changes made to the page. Following the screenshot, we will learn how to revert to the original page.

  1. Open your wiki and navigate to the page you wish to make changes to.
  2. Click on the history tab at the top of the page and you will be taken to the page history. Locate the time and date of the revision you wish to revert to.
  3. Click on the ti me and date link. In our example, we selected 21:39, 14 September 2009.
  4. We will now be taken to the page that existed on that date, and at that time.
  5. Click on the edit tab at the top of the page. You will now be taken to the editing page. As we are reverting, we don't need to make any changes. It is good practice to put something in the edit summary referring to the fact that you reverted to an earlier page.
  6. Click on Save page. A newline will be added to the page history reflecting the changes you just made as shown in the following screenshot:

In the case of vandalism, it may be wise to check the contribution history of the user who vandalized the article by clicking on their IP address or user name. Clicking on their IP will often bring you directly to their user contribution page. If you are able to click on their user name, that will bring you to their user page. In the lower-left corner, there is a toolbox with a User contributions link. Click on this link. If this user is vandalizing many articles, you may need to take action.

What just happened?

When we noticed that our page had been edited and we did not approve of the changes, we used the page history to revert to an earlier version of the content that met our approval.In our example, we were able to revert from a legitimate change as well as an attack by a vandal. We also learned that when a vandal strikes our wiki, we may want to check their User contributions page to see what other articles they may have wreaked havoc on.

More administrative tools

MediaWiki has quite a few more tools that the administrator can use to help monitor a multi-user wiki. While some of these have been mentioned already in the text, such as edit summaries and minor changes, they need further explanation.

Edit summaries

We had a brief discussion about edit summaries in the last exercise when we were reverting to an earlier revision of a page. It is highly recommended that anyone editing a page fills in the Summary field because it makes it easier for you and your fellow contributors to understand what has been changed. It is also extremely helpful when going through the history of the page.

The edit summary box can hold one line of 200 characters. If you attempt to enter more than this, only the first 200 characters will be displayed and the rest will be disregarded. In the case of a small addition to an article, it is highly recommended the full text of this addition be copied to the Summary field, giving a maximum of information with a minimum of effort. This way, readers of the summary will be unlikely to check the page itself as they already know the extent of the edit. These kinds of summaries allow users to check Recent changes, page history, and User contributions very efficiently.

In addition to a summary of the change itself, the Summary field may also contain an explanation of the change. Note that if the reason for an edit is not clear, it is more likely to be reverted, especially in the case that some text is deleted. To give a longer explanation, use the talk page and make a note about it in the edit summary.

After saving the page, the summary cannot be edited, so try to avoid any errors.

Minor changes

If you look at the previous screenshot, you will see a check box labeled This is a minor edit.Minor edits have been glossed over in this article but now, we will give them a bit more attention.

When editing a page, logged-in users may mark a change to a page as a minor edit. Minor edits deal with changes such as correcting a type, changing the format of the content, or changing the presentation of the content. Minor edits usually do not involve changing the actual content of the page.

By contrast, a major edit makes the article worth reviewing for anyone who watches it closely. Therefore, any change that affects the meaning of an article is not minor, even if it involves one word.

The distinction between major and minor edits is significant because you may decide to ignore minor edits when viewing recent changes. Logged-in users can even set their preferences to not display such edits. No one wants to be fooled into ignoring a significant change to an article simply because it was marked minor, of course. So remember to consider the opinions of other editors when choosing this option.

Users who are not logged into the wiki are not able to mark changes as minor because of the potential for vandalism. The ability to mark changes as minor is another way you can entice your visitors to register.

It is always better to mark the edit as minor if you are doing the following changes:

  • Spelling corrections
  • Simple formatting (capitalization, bold, italics, and so on)
  • Formatting that does not change the meaning of the page (for example, adding horizontal lines or splitting a paragraph into two where such splitting isn't contentious)
  • Obvious factual errors (changing 1873 to 1973, where the event in question clearly took place in 1973)
  • Fixing layout errors

We have to remember the following things when we are marking an edit as minor edit:

  • Any change to the wikitext, even if it does not affect the presentation of the page in HTML (for example, adding a space or a line break), will still be treated as a change according to the database.
  • Marking a major change as a minor one is considered bad manners, especially if the change involves the deletion of some text.
  • Reverting pages is not likely to be considered minor under most circumstances. W hen the status of a page is disputed, and particularly if an edit war is brewing, then it's better not to mark any edit as minor. Reverting blatant vandalism is an exception to this rule.
  • A user's watchlist will only list the most recent change made to a page, even if that edit was minor. Therefore, a minor change will supersede a major one in the watchlist. This is because a user who keeps a watchlist is generally interested in all changes made to a page. If you are uncertain about the changes made to a page, double-check the page history.
  • If you accidentally mark an edit as minor when it was in fact a major edit, you should make a second "dummy" edit, but make a note in the edit summary that "the previous edit was major". As a trivial edit to be made for this purpose, just opening the edit box and saving (changing nothing) will not work, neither will adding a blank space at the end of a line or a blank line at the end of the page—in these cases the edit is canceled and its summary discarded. However, you can add an extra space between two words, or can even add a line break. These changes are preserved in the wikitext and recorded as a change, although they do not change the rendered page.
  • It may be worth communicating any disagreement about what is minor via Talk or a message to the contributor, being careful to avoid a flame war with other users. There is a gray area here, and many contributors will appreciate feedback on whether they've got it right.

It is also good to remember the following terms since we are using them every now and then:

  • Dummy edit: A dummy edit is a change in wikitext that has little or no effect on the rendered page, but saves a useful dummy edit summary. The dummy edit summary can be used for text messaging, and correcting a previous edit summary such as an accidental marking of a previous edit as "minor". Text messaging via the edit summary is a way of communicating with other editors. Text messages may be seen by dotted IP number editors who don't have a user talk page, or editors who haven't read the subject's talk page, if it exists. A dummy edit should be checked as "minor" by logged-in editors. Consider the following example:
    Changing the number of newlines in the edit text, such as putting a newline where no newline exists or adding one more newline to two existing newlines, has no effect on the rendered page. But changing from one newline to two newlines makes a rendered difference as it creates spacing between the contents in Mediawiki and may not be a dummy edit. Adding newlines to the end of the article will not save as a dummy edit.
  • Dotted IP number editors are editors who are referred to by their IP address in the dotted decimal notation rather than a username, for example, 192.168.1.230.

  • Null edit: A null edit occurs if a page save is made when the wikitext is not changed, which is useful for refreshing the cache. A null edit will not record an edit, make any entry in the page history in recent changes, and so on. The edit summary is discarded. Consider the following examples:
    • Opening the edit window and saving.
    • Adding newlines only to the end of the article and saving is also a null edit.
MediaWiki 1.1 Beginner's Guide Install, manage, and customize your own MediaWiki-based site
Published: March 2010
eBook Price: £14.99
Book Price: £24.99
See more
Select your format and quantity:

Pop quiz - edits

So, are you ready to test what you have learned about edits in MediaWiki? Try the following quiz to see what you have learned so far.

  1. How many characters can the edit summary textbox hold?
    1. 200
    2. 400
    3. 600
    4. 1000
  2. Major edits always require an edit summary.
    1. True
    2. False
  3. Which of the following would not be considered a minor edit?
    1. Changing the date of fall of the Berlin wall from 1998 to 1989
    2. Adding a horizontal rule underneath the page title
    3. Adding a section about Neil Armstrong to a page about lunar landings
    4. Making the words "Berlin wall" appear in italicized font
  4. Dummy edits can be used to send text messages to the editors.
    1. True
    2. False
  5. When the wikitext changes, you can use a Null edit.
    1. True
    2. False

Your wiki's community

As stated many times throughout the book, a wiki is used best when it is a tool that the community can use. In order for the community to collaborate and use the wiki effectively, we need to make sure that as the sysop, we do our job and allow communication between the users. In this section, we will look at a few tools that MediaWiki has in place to help facilitate communication among the wiki' s users. We will also see how extensions can help make our job as sysops easier, while making the end user's experience richer as well.

Talk pages

The first method of communication among the wiki users should be the talk pages. There are two types of talk pages: standard talk pages are used to discuss an article, and user talk pages are used to communicate with other users or leave them messages. Every page has an associated talk page, except pages in the Special namespace. If there is no discussion for a page, the link to its talk page will be red. You can still use this feature, you will just be the first person to do so.

Time for action - starting a conversation on a standard talk page

Let's suppose you come across an article that you would like to see more information on. In the sample that we have created, let's say that a registered visitor wants to see a bit more information for the page titled, Best software. The visitor can use the talk page to introduce his or her ideas about the page. Let's see how this can be done.

  1. Log in to your wiki and select an article to begin discussing. For our example, we are using the Best software page.
  2. Click on the discussion tab at the top of the page.
  3. The talk page will now open. Type whatever you wish to communicate. In the example, we wrote:
     I would like to see a description of each software package so I
    know what they can do. Does anyone know them well enough to do
    this? ~~~~

    The four tildes (~) at the end will leave our signature.

  4. Click on Save page. Your page will now look similar to the following screenshot:

Now the editor of the page, if they are paying attention, can respond to FLOSSuser's request for more information. By opening the discussion page and clicking on the edit tab, they can respond. As they would be responding to FLOSSuser's question, they should lead off their discussion with a colon (:) to indent the text like this:

:I like that idea. I will be updating this page shortly so that you
and the other visitors will know what each software package is used
for. Are there any other requests? ~~~~

Now, FLOSSuser can also make use of the colon (:) when responding, only they would use two colons to indent even further:

::Yes, if you have a screenshot for each one I would appreciate that
as well! Thanks. ~~~~

The following screenshot shows that the discussion is nicely organized:

 

 

 

Time for action - starting a conversation on a user talk page

Just as we are able to converse with others through standard talk pages, we can leave messages for others through their user talk page as well. The wikitext formatting is the same; the only real difference comes in how we find a user's page. In this example, FLOSSuser will be leaving a message on Jeff 's user talk page.

  1. Log in to the wiki.
  2. To access a user's talk page, you need to click on their name in their signature (this will be in red, not the standard blue). Open an article that contains their signature and click on the link.
  3. If no discussion has been started, you will be brought to the page as shown in the following screenshot:
  4. This is similar to the newly-created standard talk page in the previous exercise.
  5. Add your comments to the user. For our example, we will write:
    Thank you for making the changes to the Best Software page. I am
    a regular contributor to Ubuntu. Do you mind if I create some GNU/
    Linux and Ubuntu pages? ~~~~
  6. Click on Save page.

Of course, Jeff can then respond on FLOSSuser's page.

What just happened?

We learned two primary ways of communicating with other members of the community, through standard talk pages where we can discuss things related to a page and through user talk pages where we can interact directly with another user. Talk pages are great because they help develop a sense of community among your visitors. If you, as the administrator, encourage the use of talk pages, you will find that you have to worry about edit wars among users.

Talk page rules
If you look at Wikipedia, they have a page dedicated to how a user should format discussions on the talk pages. I would suggest that you do the same for your wiki.

Conflicts

If you have a large user base, there may be times where one user, let's say Jeff , is editing a page for spelling mistakes. Meanwhile, FLOSSuser is making some heavy content changes to the article. Jeff makes his few changes and saves the page. Meanwhile, FLOSSuser, who has made quite a few significant changes, tries to save but receives the error message indicating an edit conflict as shown in the following screenshot:

Time for action - resolving an edit conflict

When an edit conflict takes place, the edit conflict page is shown with the conflict page source. The first text area shows your wikitext or source. Below that, the differences between the two edits are shown according to the differences or diff option. In the Differences, the text you modified is highlighted in yellow while the stored text is highlighted in green. After that, the other edit option is shown in an area called Your text. If you save your changes using the Save butt on, then the other changes will be gone. So before saving any of the changes, we have to merge both the sources (yes, we have to merge as the process is not automatic).

  1. Look at the diff area to see who made the more complicated changes. In this instance, the user Jeff made some minor changes while FLOSSuser made some significant changes.
  2. The user receiving the edit conflict should then merge the two articles together. In this instance, we will copy the text that FLOSSuser created (in the Your text area) and paste it into the edit area.
  3. Once the content has been moved, FLOSSuser should then make the corrections to the article that Jeff made (shown in the diff area).
  4. Click on Save page. The changes will now be reflected on the new page as shown in the following screenshot:

What just happened?

Inevitably, two or more people will make changes to a page at the same time. When this happens, the users who save after the first edits have been saved will receive an edit conflict warning. Edit conflicts can be time consuming because the user will have to merge the two edits together using copy and paste. Oft en times, they should respect the other users edits and go back to include them as well.

In this exercise, we saw what happens when an edit conflict occurs and how to merge the two edits together. This is another reason why the talk pages can be so helpful. If Jeff knew that FLOSSuser was making major changes to the content, he may not have been so anxious to make the minor changes he was responsible for. Of course, in the case where users do not respect one another's edits in resolving a conflict, the sysop may have to revert the page to the state it was in prior to the edits and include what he or she deems appropriate edits.

Discussion extension

There are many extensions that MediaWiki has that can help make the community stronger. Many of these will be discussed in Appendix A, The Best Extensions. For now, we are going to concentrate on one extension in particular called Discussion.

Time for action - installing the Discussion extension

We saw how the talk pages are a good way to let the community discuss the content on a page, but talk pages are generally geared towards potential edits, correcting the article,or future additions to the page. Let's say you want to allow users to comment on a page or its content. User feedback can be a useful tool in creating good content or for inspiring interesting debates. As a sysop, we probably wouldn't want the reader feedback to be intertwined with the talk page though. Instead, we can install an extension called Discussion to provide a space for user to discuss and debate page content.

  1. Download the extension from http://en.wikicaptions.org/wiki/Extensions:Discussion:Installation.
  2. Upload the compressed Discussion file to the extensions folder on your server using your file manager or FTP program.
  3. Extract the Discussion file into the extensions folder.
  4. On your server, open your LocalSetttings.php file and find the value for$wgDBprefix. Write down the value. In the example wiki, this is flossWiki.
  5. Copy the following SQL statement from the URL above to your favorite text editor for editing:
    CREATE TABLE flossWikidiscussion(
    discussion_id INT NOT NULL AUTO_INCREMENT, PRIMARY
    KEY(discussion_id),
    page_id INT NOT NULL,
    id TINYTEXT NOT NULL,
    view_group VARCHAR(16),
    post_group VARCHAR(16),
    restricted_post_group VARCHAR(16),
    moderator_group VARCHAR(16),
    max_depth INT,
    counted_depth INT,
    page_size TINYTEXT,
    show_all_page_size INT,
    expanded_depth INT,
    show_all_order INT,
    init_display TINYTEXT,
    time_format INT,
    characters_max INT,
    author_characters_max INT,
    quoting INT,
    preview INT,
    comment_num1 INT DEFAULT 0,
    comment_num2 INT DEFAULT 0
    );
    CREATE TABLE flossWikidiscussion_comments(
    comment_id INT NOT NULL AUTO_INCREMENT, PRIMARY
    KEY(comment_id),
    discussion_id INT NOT NULL,
    user_id INT,
    author_name TINYTEXT,
    text TEXT,
    time INT,
    status INT,
    author_status INT,
    parent_id INT,
    depth INT,
    vote INT
    );
    CREATE INDEX IDX_discussion_page_id ON
    flossWikidiscussion (page_id);
    CREATE INDEX IDX_discussion_page_url ON flossWikidiscussion
    (page_url);
    CREATE INDEX IDX_discussion_comments_discussion_id ON
    flossWikidiscussion_comments (discussion_id);
  6. Change the flossWiki to your value for $wgDBprefix. For example, your SQL statement will read yourvaluediscussion and yourvaluediscussion_comments.
  7. Copy the edited SQL statement.
  8. Open up your database management tool. We have been using phpMyAdmin.
  9. In phpMyAdmin, select the database for your wiki from the upper-left corner of the screen. Once you have selected your wiki's database, a new screen will open as shown in the following screenshot:
  10. Click on the tab marked SQL. This will open the SQL screen where you can insert your SQL statement.
  11. Paste your edited SQL statement into the available box and click Go. This will create two new tables in your database, yourvaluediscussion and yourvaluediscussion_comments, if you see a message that Your SQL query has been executed successfully. If you are not successful, make sure all of your parameters in your SQL statement are correct and that the $wfDBprefix value is correct.
  12. Close phpMyAdmin and open the LocalSettings.php fi le on your server for editing.
  13. Add the following code to the LocalSettings.php file:
    //Discussion Extension
    require_once(‘extensions/Discussion/Discussion.php');
  14. If the value for $wfDBprefix is empty (null) in your LocalSettings. php file you can proceed without adding a prefix in the SQL query. For example, instead of yourvaluediscussion and yourvaluediscussion_ comments, you would change your query to discussion and discussion_comments.

  15. Save your edits.
  16. Now open your wiki and log in.
  17. Open a page and click on the edit tab.
  18. Insert the < discussion / > tab at the bottom of every page you wish to display comments on.
  19. When you save the page, you will have the ability to post comments.

What just happened?

Well, we had to do quite a bit of work, but after we downloaded the extension, created some new tables in our database, and edited our LocalSettings.php file, we were able to install a really cool extension called Discussion. As a result, our users can now use the talk pages to discuss edits related to the page, and use the Discussion extension to leave comments or engage in a debate about the content on the page.

We also saw just how helpful phpMyAdmin can be when it comes to installing extensions on our wiki. Without this tool, we would have to create the database tables ourselves. Unless we know SQL pretty well, this could be a bit of a chore.

You can add parameters to your < discussion /> tag as well. A complete list of parameters that work with this tag can be found here: http://en.wikicaptions.org/wiki/Extensions:Discussion:Description.

Have a go hero

After successfully installing Discussion, we should feel pretty confident in our abilities to install new extensions on our wiki. There are other extensions out there that can help make your wiki more friendly towards a multi-user environment as well. Now that you have accomplished the exercises in this article, go ahead and find some more on your own to install. If you need help, refer to Appendix A, The Best Extensions.

Summary

We accomplished quite a bit in this article. The first part dealt with the users and how they can modify their profiles and change their editing preferences. By clicking on the my preferences tab, users are able to change the wiki's appearance by applying different skins or add pages to a watchlist so that any edits can be monitored.

In the second part of this article, we were introduced to how the administrators, or sysops, can view a page's history to view previous edits made to the page. If we see an edit that we don't agree with, we learned how we can revert the page to an earlier date to erase these edits. This works especially well should the wiki be a target of vandalism. Finally, we were taken through exercises that helped us build a stronger community for our users. By making use of talk pages, we saw how users are able to communicate directly with one another, or discuss edits and changes related to the page's content. To close out the article, we were taken through an exercise where we installed a MediaWiki extension called Discussion. Discussion allows users and visitors to post comments about the content on the page to promote even more interaction among the wiki's visitors.

MediaWiki 1.1 Beginner's Guide Install, manage, and customize your own MediaWiki-based site
Published: March 2010
eBook Price: £14.99
Book Price: £24.99
See more
Select your format and quantity:

About the Author :


Jeff Orlof

Jeff Orloff is a Technology Coordinator with the School District of Palm Beach County and has worked bringing technology solutions to the education forefront for over ten years. In addition to his work with education, Jeff is a consultant with Sequoia Media Services helping businesses install, configure, and use social media tools and create engaging content for their Web presence.

Mizanur Rahman

Mizanur Rahman from Bangladesh is a Senior Software Engineer at Relisource Technologies (http://www.relisource.com). He loves to work with Java, PHP and other web-based technologies and is a moderator of PHPXperts, the largest PHP user group in Bangladesh.

Contact Mizanur Rahman

Books From Packt

Plone 3.3 Multimedia
Plone 3.3 Multimedia

WordPress 2.8 Themes Cookbook
WordPress 2.8 Themes Cookbook

Spring Python 1.1
Spring Python 1.1

Joomla! 1.5 Content Administration
Joomla! 1.5 Content Administration

Joomla! 1.5 SEO
Joomla! 1.5 SEO

MySQL Admin Cookbook
MySQL Admin Cookbook

JavaFX 1.2 Application Development Cookbook
JavaFX 1.2 Application Development Cookbook

Moodle 1.9 Theme Design: Beginner's Guide
Moodle 1.9 Theme Design: Beginner's Guide

Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software