Documentation Guide

Last modified by Lucas Charpentier (Sereza7) on 2023/11/29 11:11

General Remarks

This document is meant to provide best practices on how the documentation should be written and maintained.
Either you write XWiki documentation on a regular basis or you want to make more simple contributions it's best you read the following guidelines.

On documentation efforts usually go towards:

  • Fixing bugs
  • Improving existing documentation
  • Keeping pages up to date with the latest changes in XWiki
  • Creating new documentation for new features, applications, procedures, etc.


The following things are important when contributing to documentation:

  • Your will emoticon_wink
  • Having basic English skills, as all documentation should be written in English (since you are reading this guide, your skills are more than enough)
  • You must be registered as an user (use the "Register" link on the top right) 
  • Reading this guide

Fixing bugs

Sometimes you will encounter trivial bugs, like:

  • Grammar errors
  • Typing errors
  • Broken links
  • Other "one" word bugs

Such bugs should be fixed directly in the page. You don't need to ask someone, just fix them emoticon_smile Please, in doing so don't forget to:

  • Mark the changes as "minor" 
  • Write a short comment describing the fix

That's all!

Updating existing pages

Any documentation can become obsolete or just not be good enough from your point of view. In these cases, if you want to upgrade/improve the documentation, you shouldn't make changes directly in the documentation page. Rewriting the documentation can take very long and nobody wants to have unbaked bread. Please proceed as follows:

  1. Make sure the documentation you are planning to add applies to the suported versions.
  2. If you're unsure about the changes you want to make, you may ask the XWiki forum or Chat before starting the rework.
  3. Create a new page on the Drafts space.
  4. If the work is a full rewrite of the documentation page, you can flag the original page as "under revision" with a link to the draft you have created:
    This page is being reworked at the moment, therefore you shouldn't modify the present document. To bring changes to the page please see the current [[Draft >> your-draft-url]].
    • Reference the original page from your draft:
      This page is a draft for the [[PageName >> original-page-url]]. The rework should be completed until <date>.
  5. If you are adding information about a new feature or documenting changes in an existing feature make sure you also specify the release during which those additions/changes were introduced, using the version macro (see above or below). This will make it easier for readers to see if the information applies to them.
  6. Once you have completed the draft, please notify the community on the XWiki forum.
  7. After the community agrees with the improvements and possibly offers new suggestions you may replace or update the original page with the updated draft.
  8. The draft must be removed after that, in order to avoid duplicate pages.

When to create a new page

Before building a new page you should first search for that piece of information in the existing documentation. You may find that:

  • A similar page already exists and portraits the situation you were about to describe. Make sure you also check the Drafts page. Somebody may be already working on a similar page. If so, you could contact her/him and help.
  • There is a page on that only covers part of the message you were about to convey. You can write additional information to the existing page.
  • There is no documentation on your choice of topic. At this point you may create a new page.

How to create new pages

Now that you've decided to create a new page you should take notice of the following steps:

  1. If there are no similar pages on the Drafts page, add a link to your draft followed by a short description.
  2. At this point you could inform the community on the user mailing list about your plans. Most probably you will get helpful suggestions and even find contributors.
  3. After you have completed the draft, please notify the XWiki community on the user mailing list.
  4. After the community has reviewed the document and additional improvements have been made the original page can be replaced with the draft.
  5. Make sure you remove the draft after the original page has been updated, in order to avoid duplicate pages.
  6. If you are not replacing an original page, but want to create a new page altogether and you are not sure where it's best to add it you can ask on the user mailing list or on IRC what the best place is. The community will most likely point you to the right wiki & space.

Text editing

You've decided to make a new document or improve an existing one. Chances are you'll want to add new text and/or bring changes to existing paragraphs. When editing the text in a document it's best to:

  • Write the page title in the title field
  • Use headings to mark the different sets of information
    To ensure the best experience for assistive technology users, heading hierarchy should be under the page title, which means using only the H2 level and lower.
  • Use bold to emphasize important pieces of text
  • Use bullets to make content easier to skim through

When you're done typing don't forget to review your text for typos and/or mistakes before submitting it.

List Items

It's very frequent to have an item list and to have some images or tables to display inside a list item.

What not to do:

* Item 1
* Item 2

{{image reference="whatever.png"/}}

* Item 3

The reason is that this breaks the list and the image will not be displayed inside the list item.

Instead you should write:

* Item 1
* Item 2(((
{{image reference="whatever.png"/}}
* Item 3


Macros can help you better visualize information within a page. You should use:

  • The code macro to insert pieces of code. Make sure you always use the language parameter as otherwise you're going to make it slower than it should be (the content will be analyzed to infer the langage) and in a lost of cases the wrong language will be found leading to bad syntax coloring.
  • The info macro to highlight important information
  • The warning macro to let readers know of possible issues they might come across
  • The toc macro to create a table of content for large documents covering a long array of information.


  • Now that you have added text you should use links to point to other useful resources outside the page
  • Don't use URLs for links to If the URL format or the domain get changed the links will be broken. You should use the wiki:Space.Name notation instead. To easily get the "id" of the page you are linking to, scroll to the bottom of that page, select the Information tab, and copy the value in the Page Reference field.
  • More information about links, including differences between the different syntaxes, can be found by reading the XWiki Syntax page
  • If you wish to link to a file on GitHub you must use the {{scm}} macro. The rationale is that this will allow us to change SCM without breaking all our URLs (which is what we experienced when we moved from Subversion to GitHub). Here's how it works:



    {{scm project="xwiki-rendering"/}}

    {{scm project="xwiki-commons" path="xwiki-commons-core/pom.xml"/}}

    {{scm branch="stable-3.1.x" path="xwiki-platform-core/pom.xml"/}}

    {{scm path="xwiki-platform-core/pom.xml"/}}

    {{scm branch="stable-3.1.x" path="xwiki-platform-core/pom.xml"}}With **label**{{/scm}}

    {{scm branch="stable-3.1.x" path="xwiki-platform-core/pom.xml" raw="true"/}}


     Parameter name  Default value  Description
     user  xwiki  the github user
     project  xwiki-platform  the repository name in the provided user
     branch  master  the branch or tag
     raw  false  UI or raw content
     path  empty string  the resource in the repository

Literals / computer terms

It is recommended to use the  notation for literals and computer terms.

For example, instead of saying This is the "age" xproperty, you'd write This is the ##age## xproperty.

Screen shots / Images

It is recommended to use images to illustrate the content you are writing about. There are some practices it's best to follow with respect to images:

  • Always use the {{image}} macro. This allows to have a common style for all images (borders, ability to click when the image is resized, etc). For example:

    {{image reference="someimage.extension" width="350px"/}}These lines...

  • Use names that are suggestive
  • Only have screenshots of the latest skin
  • You should save your images only as PNG.
  • To give documentation a homogeneous look we recommend using four standard width sizes for screenshots:              
    • Extra Large: width of the image : 960px; (used for whole interface screens)
    • Large: width of the image : 650px;
    • Medium: width of the image : 350px;
    • Small: width of the image : 150px;
  • You should add a piece of text in italics under images that describes what that image is about (by using the caption parameter of the image macro)
  • If your image is part of a bullet list, that image should be aligned to the text in the bullets. For this purpose we use
    * Some text here(((
    {{image reference="someimage.extension"/}}


Whenever you need to add a diagram, you must:

This has several benefits:

  • Consistent diagram L&F across
  • The source of the diagram is in the wiki content and thus can be easily modified (it wouldn't be the case with a screenshot of a generated diagram for example)
  • Makes it easier to edit diagrams as otherwise you would need to use the same tool as the one used by the person who generated the diagram to be modified (provided he attached the source to the page, see previous point)


  • URL Architecture 
  • Content:
    !theme bluegray
    -> URL;
    :Routing Filter;
    floating note left
      Executed as the first
      Filter in web.xml
    end note
    floating note right
      Parse URL and check if there's
      a Resource Reference Handler to
      handle the Resource Type
    end note
    if (Resource Reference Filter?) then (Yes)
      :Resource Reference Handler Servlet;
      :Resource Reference Handler;
      note: e.g. WebJarsResourceReferenceHandler
    else (No)
      partition "Legacy Action Handling" {
        :Evaluate rest of web.xml;
          :Legacy Action Servlet;
        split again
          :Other Servlets;
        end split

Here are a few tools to help produce and test plantuml diagrams:

Affected Versions

When documentation is added that depends on the versions of XWiki or the released extension (in case of XWiki, for XWiki versions >= LTS version), this must be specified using the {{version}} macro

Example result:


See the Version macro page for more examples.


  • When you're not sure about the appropriate syntax you should use please consult the XWiki Syntaxes Page
  • Pages should be written in 2.1 syntax
  • When converting a page from 1.0/2.0 to 2.1 syntax you should look at the end result and make sure nothing was broken in the process. Double check that comments have been properly converted as well.
  • Avoid using HTML code and use XWiki Syntax instead

Preview & Save

  • It's preferable to click "Preview" when editing a page to view your changes before you save the document. This way you don't send notifications to people following that page (by IRC, mail or RSS) each time you make a minor addition.
  • When changing a document you should write a short comment describing the changes you introduced. This way everyone can stay up to date with no need to check the "History" tab.
  • If you are making small improvements make sure you check the "Is minor edit" checkbox before saving your page.


  • If you want to replace an attachment with a newer version you shouldn't delete the old attachments. Just save the new attachment under the same name and a new version will be created for the old attachment.
  • File extensions should  be in lowercase letters (this is not mandatory, but it's recommended for better versioning). E.g. If you use both upper and lower cases for Image.png & Image.PNG you'll get two different attachments with separate versions.
  • If you're using multiple words to name your attachments, it's best that each word starts with a capital letter, making the file name easy to scan. E.g.: CreagePage.png, RemoveSpace.png, TopBarRenameToucan.png

Making your page accessible on the wiki

Once you've successfully created and edited a page it's equally important to make sure other people can reach that page as well.

  • When you create a new document it's best to set a parent for that page. Setting parents to documents allows for easy creation of hierarchies, as deep as you want.
  • You should also add links from other pages towards the document you have just created. 

Moving a page

If you decide to move a page you should not remove the old page altogether. Use the old document to point to the new page. This way users that have the old link saved can still reach the information they are interested in by finding their way to the new URL. You can use the redirect syntax to link the new page from the old page.

Removing old documentation

The community only supports the LTS and beyond. Thus the documentation on should be aligned and only document the LTS and beyond.

The consequence is that documentation gardening should be done to:

  • Remove documentation and versions macros that only affects old versions of XWiki.
  • Remove mentions of old XWiki versions by removing the versions macros around valid content. This avoid the documentation to be littered with references to old (not supported) versions of XWiki.

Start contributing

Now that you've read how you should create and modify documentation you can start contributing yourself. Not sure what to work on? Here's a list of pending to do's.

Get Connected