Back to description
Wikis are websites that are collaboratively written by their readers. The software that makes wikis possible is called a... more
Wikis are websites that are collaboratively written by their readers. The software that makes wikis possible is called a wiki engine. This chapter introduces the wiki concept, and what you read here will apply to almost any wiki engine. The rest of the book, however, is devoted to one wiki engine in particular called MediaWiki, the wiki engine that runs what is arguably the world’s most famous wiki, Wikipedia.
The idea that wikis are websites collaboratively written by their readers is simple enough, but the simplicity of the idea belies the profound impact a wiki can have on the flow of information among individuals. A wiki is to a typical website what a dialogue is to a monologue. On the surface, a conversation shares a lot in common with a lecturein both cases, someone is talking and someone is listening, but the experience of a conversation is qualitatively different from the experience of either lecturing or being lectured, and the outcome of a conversation is qualitatively different from the outcome of a lecture as well.
In other words, authors are readers and readers are authors; there is no approval process required to post information on a wiki and there is no pre-ordained structure imposed on the content that is presented there. If you think of a regular website as a farm, with all the content organized into neat little rows of corn or beans, then a wiki is a meadow, teaming with grasses and wild flowers. A meadow isn’t chaotic, however; there is order there, but it is a different kind of order. It’s an emergent kind of order, one that evolves and is discovered, rather than imposed.
As with all definitions, this definition is only partly true. As time has passed, the principle of openness has been reshaped as a consequence of the hard realities of the world, and many wikis now restrict editing to certain users. Wikis have now become so popular that there are quite a few content management systems claiming wiki status with a completely different set of features than those conceived by the father of wikis, Ward Cunningham. He launched the first wiki (something he called a WikiWikiWeb back then) on March 25, 1995. A host of content management systems label themselves as wikis, even though they bear only a minor resemblance to the original wiki concept. This can make getting started with wikis a confusing affair.
Note
The Wiki Way is the name of a book by Ward Cunningham, and it is also a phrase used in reference to what was originally called Wiki Design Principles, which can be found on Ward’s wiki at http://c2.com/cgi/wiki?WikiDesignPrinciples.
The most common question I am asked in my consulting practice goes something like this: “We have a content management system in place, but we’d like to have a wiki, too. How can my wiki integrate with the content management system?” This is like someone walking up to me and saying, “I have a pair of red shoes and a pair of black shoes and I’d like to integrate them into the same outfit.” I might suggest they wear both shoesone red and one black. That might actually work if the only difference between the red shoes and the black shoes were the color. But what if the red shoes were running shoes and the black shoes were stiletto pumps? It would be very hard to get where you want to go.
The problem is this: A wiki is a content management system, not an alternative to a content management system. A website is a collection of related HTML pages that is accessible through the World Wide Web at a particular domain name (usually), and these pages are organized and linked to each other in a systematic way to make it easy for readers to find the information they seek. A content management system is a software application that provides tools to help people create and deploy websites. A wiki is a kind of content management system with a very special set of features that make it easy for people to use them to collaborate.
There are many different kinds of content management systems, each one suited to a different purpose, so the first question that really needs to be answered is “What are you trying to accomplish?”
There is a time and a season for everything. There is a time to wiki and a time not to wiki. This chapter aims to shed some light on when it makes sense to use a wiki, and when it may make sense to try a different approach. I start by exploring the history of wikis and why wikis have become such an item of interest in organizations. This is followed by a more detailed look at how wikis work and what kind of functionality is important when selecting a particular wiki engine. The chapter concludes with a discussion of best practices for running a successful wiki.
Once you know where you are going, it’s a lot easier to figure out what kind of shoes you need to wear in order to get there.
... less
In order to run MediaWiki, you need a Web server, support for PHP, and a database, either MySQL or Postgres. The simplest... more
In order to run MediaWiki, you need a Web server, support for PHP, and a database, either MySQL or Postgres. The simplest way to install MediaWiki is to install it on a computer running Linux or a Unix-like operating system, with the Apache Web server and mod_php installed. The PHP installation should be version 5.0 or later (don’t use 5.1 with 64-bit computers, as there are reportedly some bugs), and the database should be either MySQL 4.0 or later, or Postgres 8.0 or later. This is the basic configuration that Wikipedia’s servers run and the configuration on which the developers of MediaWiki focus their efforts. It is also possible, although a little more difficult, to install and run MediaWiki on Windows servers.
mod_php
Apache is not the only Web server you can use, but it is the best of the options, for a few reasons. First, because of the success of Wikipedia, we know that MediaWiki has been installed on a high-traffic website that uses Apache servers, and we know that this configuration works reliably and can scale to accommodate whatever optimistic growth expectations we have about our own wiki endeavors. Second, the Apache/PHP combination is pervasive and readily available. PHP can be loaded as a dynamic shared object (DSO) in Apache, which makes installation and configuration a much simpler task in most cases. While the core PHP libraries are supposed to be threadsafe, not all of the many extensions available for it are, so experts often recommend that you do not run PHP on Web servers that are threadedthis includes Internet Information Server (IIS). If you are running Apache 2, then you need to use the pre-forked version.
In all other cases, the most stable approach is to use FastCGI to run PHP. FastCGI is a speedier alternative to regular old CGI, as it allows CGI applications to stay in memory between requests, something that CGI does not do and that leads to a lot of overhead as the program is reloaded into memory every time it is executed. Note that not all of the features or options available to MediaWiki when running under Apache with mod_php work when running in CGI mode, with or without FastCGI.
In the previous chapter, you learned how to set up the Web servers and PHP implementations necessary to run MediaWiki. In... more
In the previous chapter, you learned how to set up the Web servers and PHP implementations necessary to run MediaWiki. In this chapter, you will learn about the basic configuration options for MediaWiki, and get a general overview of how the software works “out of the box.” Many of the topics touched on lightly in this chapter are handled in much greater depth in subsequent chapters. When appropriate, cross-references are provided directing you to the chapter of the book that covers a given topic so that you can jump directly to it if you are particularly eager to learn more.
The authors of MediaWiki are unabashed in their commitment to develop MediaWiki primarily for Wikipedia. The fact that others can also make use of it is an added bonus, and certainly a “nice-to-have,” but at the end of the day it’s not their primary goal. Despite this, the developers have been generous by making MediaWiki highly configurable. You can customize a great deal of your wiki without doing any kind of programming other than changing the values of a few variables.
Much of this chapter serves as an introduction to how MediaWiki is organized. In addition to covering the basic features of the software, it also describes how to customize those features when appropriate. You should have a fresh, virgin wiki at your disposal to experiment with. In some instances, it may be most useful to look at an actively maintained wiki to see how a certain feature works; and in those instances you’ll see examples in Wikipedia. In other cases, examples are based on the newly minted wiki installed in the previous chapter, in case you want to follow along and perform the tasks yourself.
In this chapter, you will learn about writing and editing content on MediaWiki using wikitext. Wikitext is a shorthand form... more
In this chapter, you will learn about writing and editing content on MediaWiki using wikitext. Wikitext is a shorthand form of HTML, intended to be easier (and quicker) to type than HTML. As a consequence, the more you know about HTML, the easier it will be to begin using wikitext. This chapter assumes you have a basic knowledge of HTML, so it does not provide a detailed explanation about how to write HTML. If you are a complete newcomer, a good starting place is Jon Duckett’s Beginning Web Programming with HTML, XHTML, and CSS (Wrox, 2004).
MediaWiki provides a wide array of tools to edit and customize pages. This chapter focuses on wikitext, but this is only the beginning. In Chapter 6, you will learn advanced methods of managing pages, such as how to move and delete pages, how to protect them from unwanted editing, and how to add additional functionality to them through extensions or external applications. In Chapter 8, you will learn how to use MediaWiki’s magic words and templates, as well how to define your own skins for MediaWiki, which also means more advanced skills for determining the style and presentation of your content.
Prior to jumping into the nuts and bolts of writing wikitext, I’ll share some thoughts about writing for the Web in general in order to provide some context for the discussion of wikitext itself.
In the previous chapter, you learned how to create and edit pages using wikitext, but that just skimmed the surface of the... more
In the previous chapter, you learned how to create and edit pages using wikitext, but that just skimmed the surface of the kind of content you can add to a wiki page. In this chapter, you will learn how to configure MediaWiki so that files can be uploaded, as well as how to control what kinds of files can be uploaded. You will also learn how to link to images, embed images in pages, and create thumbnails, as well as how to make image galleries. The chapter concludes with a discussion of uploading different file types and how you can use this feature as a simple document management tool.
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
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.
HTTP
GET
index.php
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.
The objective of information architects is to make information easy to find. They do this in two ways. The first way is by... more
The objective of information architects is to make information easy to find. They do this in two ways. The first way is by organizing a site, usually in a hierarchical fashion, and using that organizational structure to create a system of navigation that enables users to drill down into the content by following links. The second way is through search engines. Wikis are organized differently than other websites, and in this chapter you will learn how to organize your content on MediaWiki so that users can quickly and easily find the information they are looking for.
Magic words and templates provide advanced methods for including content that is dynamic or needs to be standardized across... more
Magic words and templates provide advanced methods for including content that is dynamic or needs to be standardized across pages. Skins determine the overall look and feel of MediaWiki, as well as standard navigation features, and user tools. All three tools can be customized. This chapter will show you how to create your own templates, and how to modify the default MediaWiki skin to change the look and feel of your wiki. In Chapter 9, you will learn how to install and write extensions to MediaWiki, including how to create your own magic words.
This chapter assumes the reader knows what Cascading Stylesheets (CSS) are and how they work. It also assumes a basic understanding of programming languages, ideally PHP. If you are not familiar with CSS, you should familiarize yourself with it prior to reading the section on MediaWiki skins. An excellent introduction is available on Wikipedia at http://en.wikipedia.org/wiki/CSS. Another good source is Richard York’s Beginning CSS: Cascading Style Sheets for Web Design, Second Edition (Wrox, 2004).
http://en.wikipedia.org/wiki/CSS
By now, you are familiar with magic words and how to use them with wikitext. In this chapter, you will learn how to create... more
By now, you are familiar with magic words and how to use them with wikitext. In this chapter, you will learn how to create your very own magic words and special pages. Of necessity, this means diving a little deeper into the inner workings of MediaWiki, and it requires familiarity with PHP. If you are completely unfamiliar with PHP and computer programming, you can find several good books that can help you.
See especially Beginning PHP, Apache, MySQL Web Development, by Michael K. Glass et al. (Wrox, 2004).
Otherwise, read on and learn about MediaWiki’s extension mechanism.
Extensions enable you to customize MediaWiki to your individual needs. The MediaWiki community has made a fairly large number of extensions available, which are a good starting place to learn how to write them. Extensions are surprisingly easy to write in MediaWiki. They are made possible by a rather large collection of hooks throughout the application that you can register callback functions with, which are then called at opportune times.
XML tag extensions and parser functions are callback functions that enable you to extend wikitext. There are a large number of other hooks, though, that give you the opportunity to modify MediaWiki behavior at all stages of the page delivery process.
In addition to learning how to use hooks in this chapter, you will also learn how to create your own special pages.
The ability to interact with MediaWiki through an application programming interface is an evolving feature. In this chapter... more
The ability to interact with MediaWiki through an application programming interface is an evolving feature. In this chapter, you will learn about bots, programs used to automate certain administrative tasks on MediaWiki, as well as the MediaWiki API, which is currently in development and is intended to provide a programming interface to MediaWiki so that external applications can interact with it.
Both the section on bots and the section on the API make extensive use of examples written in the Python programming language. Even if you do not know Python, you will be able to learn a lot about how bots and the API work, which you can use to develop scripts in your language of choice. With respect to the API, all interaction is managed through URLs, so you don’t even have to write any script to see samples of the API output; simply type the URL in your browser and see what is returned.
This chapter takes a look at how to performance-tune MediaWiki sites. Because of Wikipedia’s success, you could consider... more
This chapter takes a look at how to performance-tune MediaWiki sites. Because of Wikipedia’s success, you could consider it to be a worst-case scenario in terms of performance management. It is fairly safe to say that most other installations will have much less traffic and be much less complex than the one in place for Wikipedia, but it’s nice to know that there no doubt that MediaWiki can scale.
When MediaWiki receives a request for a page, it performs a number of tasksfrom ensuring that the user requesting the page is allowed to see it to converting wikitext to HTML, and then generating the page itself, delivering the appropriate layout based upon the preferences of the user. As programmers are wont to say: this is not a trivial task. Consider the fact that Wikipedia is reportedly the eighth most visited website in the world and one can see that for the developers of MediaWiki, performance is an important issue.
A website lives in a complex environment and numerous factors influence a site’s performance characteristics. From a user’s perspective, performance is simply a measure of how long it takes for a page to load after the user has clicked a link to that page. When a user clicks on a link, a request is sent to the host server in the form of an HTTP header, a simple string of text that looks like this:
GET /mysql/index.php/Main_Page HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
This request has to find the host server and then travel through a series of networks to get there, where the server gets the request and returns a new header, followed by the content of the page. This round-trip is made in a matter of seconds and appears almost instantaneous to the user when everything goes well. Of course, things never go well all the time, and many factors can influence the time it takes for the request/response cycle to complete.
Factors that affect a site’s performance include the amount of bandwidth available to the user whose computer is making the request; how far away the server is from the computer making the request; general network congestion, which can slow down the trip to and from the host server; and the bandwidth available to the server.
On the server itself, performance factors include the size of the Web pages, the speed of the microprocessor and the amount of RAM available to it, how long it takes to read data from hard drives or to query the database, as well as internal network traffic. Finally, the software used to run the site, obviously, is a factor in a site’s performance. Because of all the factors that contribute to a site’s perceived performance, optimizing performance can be a complex activity.
Purchase Before purchasing this product, please be sure you have met all software and system requirements, and that you understand any limits placed upon its use.
Return Policy Wrox Chapters on Demand are non-returnable and non-refundable.
Watermarking Wrox Chapters on Demand are sold with a small unique watermark at the bottom of each page identifying the purchaser name, email address, and order number.
Reader Software Wrox Chapters on Demand are offered as PDFs, and they can be viewed using the Adobe Reader, ADE, or a compatible PDF reader. If you do not have the Reader installed, it can be downloaded for free at Adobe.com.
Test Download As Wrox Chapters on Demand purchases are non-returnable, it is advisable that you test your system and software configurations with a free sample download before you place an order.
Usage Rights for a Wrox Chapters on Demand File Any Wrox Chapters on Demand product you purchase from this site will come with certain restrictions that allow Wiley to protect the copyrights of its products. After you purchase and download this title, you:
If you have any questions about these restrictions or need any further assistance please refer to Technical Support (www.wiley.com/techsupport) or call (877) 762-2974 (8 a.m. - 5 p.m. EST, Monday - Friday).
Related Books