Jump to navigation Jump to search

The file docs/design.txt in the MediaWiki core repository was created in 2003 to describe the basic architecture of MediaWiki at the time, and remained mostly unchanged since then, and thus has grown inaccurate and misleading. It is reproduced here for posterity, before removing it from the code repository.


This is a brief overview of the new design.

More thorough and up-to-date information is available on the documentation
wiki at

Primary classes:

    Encapsulates the state of the user viewing/using the site. Can be queried
    for things like the user's settings, name, etc. Handles the details of
    getting and saving to the "user" table of the database, and dealing with
    sessions and cookies.

    Encapsulates the entire HTML page that will be sent in response to any
    server request. It is used by calling its functions to add text, headers,
    etc., in any order, and then calling output() to send it all. It could be
    easily changed to send incrementally if that becomes useful, but I prefer
    the flexibility. This should also do the output encoding. The system
    allocates a global one in $wgOut.

    Represents the title of an article, and does all the work of translating
    among various forms such as plain text, URL, database key, etc. For
    convenience, and for historical reasons, it also represents a few features
    of articles that don't involve their text, such as access rights.
    See also title.txt.

    Encapsulates access to the "page" table of the database. The object
    represents a an article, and maintains state such as text (in Wikitext
    format), flags, etc.

    Encapsulates individual page revision data and access to the
    revision/text/blobs storage system. Higher-level code should never touch
    text storage directly; this class mediates it.

    Encapsulates a "look and feel" for the wiki. All of the functions that
    render HTML, and make choices about how to render it, are here, and are
    called from various other places when needed (most notably,
    OutputPage::addWikiText()). The StandardSkin object is a complete
    implementation, and is meant to be subclassed with other skins that may
    override some of its functions. The User object contains a reference to a
    skin (according to that user's preference), and so rather than having a
    global skin object we just rely on the global User and get the skin with
    See also skin.txt.

    Represents the language used for incidental text, and also has some
    character encoding functions and other locale stuff. The current user
    interface language is instantiated as $wgLang, and the local content
    language as $wgContLang; be sure to use the *correct* language object
    depending upon the circumstances.
    See also language.txt.

    Class used to transform wikitext to html.

    Keeps information on existence of articles. See linkcache.txt.

Naming/coding conventions:

  These are meant to be descriptive, not dictatorial; I won't presume to tell
  you how to program, I'm just describing the methods I chose to use for myself.
  If you do choose to follow these guidelines, it will probably be easier for
  you to collaborate with others on the project, but if you want to contribute
  without bothering, by all means do so (and don't be surprised if I reformat
  your code).

  - I have the code indented with tabs to save file size and so that users can
    set their tab stops to any depth they like. I use 4-space tab stops, which
    work well. I also use K&R brace matching style. I know that's a religious
    issue for some, so if you want to use a style that puts opening braces on
    the next line, that's OK too, but please don't use a style where closing
    braces don't align with either the opening brace on its own line or the
    statement that opened the block--that's confusing as hell.

  - Certain functions and class members are marked with /* private */, rather
    than being marked as such. This is a hold-over from PHP 4, which didn't
    support proper visibilities. You should not access things marked in this
    manner outside the class/inheritance line as this code is subjected to be
    updated in a manner that enforces this at some time in the near future, and
    things will break. New code should use the standard method of setting
    visibilities as normal.

  - Globals are particularly evil in PHP; it sets a lot of them automatically
    from cookies, query strings, and such, leading to namespace conflicts; when
    a variable name is used in a function, it is silently declared as a new
    local masking the global, so you'll get weird error because you forgot the
    global declaration; lack of static class member variables means you have to
    use globals for them, etc. Evil, evil.

    I think I've managed to pare down the number of globals we use to a scant
    few dozen or so, and I've prefixed them all with "wg" so you can spot errors
    better (odds are, if you see a "wg" variable being used in a function that
    doesn't declare it global, that's probably an error).

    Other conventions: Top-level functions are wfFuncname(), names of session
    variables are wsName, cookies wcName, and form field values wpName ("p" for

History and attribution:

2014-01-28 Ladsgroup -->
2012-01-29 Jeroen De Dauw this is no longer a guideline afaik
2009-08-16 Alexandre Emsenhuber * maintenance.txt: the execute() method must be public to match Maintenance's one * design.txt: whitespaces fix
2008-07-17 Alexandre Emsenhuber Doc tweaks: * Moved doc about primary scripts to scripts.txt * Lines ending to 80 chars
2007-06-26 Rob Church Some updates; regarding method/member visibilities, OutputPage is not Parser, and Language objects
2007-01-08 Brion Vibber doc updates
2005-08-23 Antoine Musso fix 3175
2005-04-12 Ævar Arnfjörð Bjarmason * Changed Wikipedia to MediaWiki.
2005-04-12 Brion Vibber Change .doc extension to .txt so people stop asking why we have Word documents. WE DONT THEY ARE TEXT!!!!111eleven
2004-12-02 Evan Prodromou Further explanation as to why to avoid CVS keywords.
2004-11-29 Evan Prodromou Removed CVS keywords from files, to make merging between branches easier. Interpolated keywords cause lots of conflicts and headaches at merge time for older (<1.12.x) CVS versions.
2004-07-25 Arne Heizmann sp
2004-02-28 Erik Moeller using index.php and redirect.php instead of wiki.phtml and redirect.phtml keeping phtml stubs around for compatibility and CVS history
2003-04-14 Lee Daniel Crocker Initial revision