Once you have XWiki installed you'll want to configure it. This introduction has moved to Configuration in the new documentation.

Enable superadmin account

Moved to Enable the Superadmin Account.

Language settings

Moved to Language Configuration, whose xwiki.cfg options are listed on Language Parameters.

Algorithm

Moved to Language Resolution.

Date format

Moved to Set the Date Format.

Enabling/Disabling Statistics

Moved to Statistics Configuration, whose xwiki.cfg options are listed on Statistics Parameters. Turning statistics on for a single subwiki is Enable Statistics for a Subwiki.

Optional Store Features

Moved to Optional Store Features.

Document versioning

Moved to Optional Store Features.

Document recycle bin

Moved to Optional Store Features.

Attachment recycle bin

Moved to Optional Store Features.

Customizing error pages

Moved to Error Pages, and the procedure to Customize an Error Page.

Customizing the Skin

See Skins.

Security configuration

See the Security Guide.

HTTPS/SSL

By default, the protocol to use to generate external URLs (HTTPS, HTTP) is extracted from requests to XWiki, so most of the time you don't have anything to do if you properly configure your proxy, but it's possible to force a specific protocol using xwiki.url.protocol property in xwiki.cfg.

To set up HTTPS/SSL, you may need to configure your Servlet Container and any front-end web server or proxy in front of XWiki. For example:

• Tomcat
• Jetty

Customizing Menus

The first thing to understand is that menus depend on the skin you're using. If you're using the 1.0 skin you're likely using the Panels Application to provide the different menu panels you see on the left or right of your wikis. Check the Panels Application to know more on how to configure/modify them.

Encoding

Moved to Character Encoding.

User Authentication

See the User Authentication documentation.

Customizing the Verified Registration Page

The Verified Registration Page is part of the Administration Application. It allows you to require users to fill in a captcha and validates user input on both the server side and the client side using Javascript. The configuration allows you to add fields and validation constraints to the fields.

To enable captcha, see the Captcha configuration.

For more information about configuring the registration page, you can visit the page on the Administration Application.

Default User Preferences

See the User Module documentation.

Initial Groups

Moved to Set the Initial Groups of New Users.

Logging

See the Logging page.

Configuring Interwiki links

Moved to Configure Interwiki Links.

Link URLs

Moved to HTTP Reverse Proxy for XWiki, which covers the headers XWiki reads to build its links and the xwiki.home property that holds the public address.

Reverse proxy setup

Moved to HTTP Reverse Proxy for XWiki. Forcing the protocol with xwiki.url.protocol is covered on HTTPS for XWiki in Docker.

Short URLs

It's possible to configure XWiki to use shorter URLs.

Configure the names of database schemas

Sometimes, especially in a complex environment, we need to control the names of database schemas other than the default.

• xwiki.db: name of database schema for the main wiki (including the name of the wiki in a single-wiki environment, otherwise the database name comes from the Hibernate configuration file).
• xwiki.db.prefix: useful mainly for sub wikis, where we have a separate database schema for each sub wiki. This prefix is added to the database schema name after usual mapping between wiki names and schemas. Note that this is also applied to the main wiki database name.

Controlling Page Tabs

You can do this from the Administration.

If you wish to turn on/off comments/annotations/attachments/history/information tabs only for a single page you just need to define some properties in a script in the page.

Last, suppose you wish to turn them off based on some programmatic rule (such as display them only for Administrators). In that case, you should define the properties in the layoutExtraVars.vm template file from your XWiki installation. For example:

#if (!$hasAdmin)
  ## Hide tabs
  #set($displayDocExtra = false)
  ## Hide viewer shortcuts in the menu
  #set ($displayShortcuts = false)
#end

Configure "Version Summary" behavior

When editing a page, you can add a brief description of your changes in the "Version Summary" field by default (look at Common edit actions). You can disable this feature by setting xwiki.editcomment=0 in xwiki.cfg.

When the "Version Summary" feature is enabled, you can also make "Version Summary" mandatory by setting xwiki.editcomment.mandatory=1 in xwiki.cfg. This will show a pop-up window with the request to write a short comment if no comment is entered. It doesn't allow you to enter an empty comment. If you want a popup, but you also want to be able to enter an empty comment, set xwiki.editcomment.suggested=1 in xwiki.cfg.

If you set "Version Summary" as mandatory or suggested, you can remove the "Version Summary" field and use only a pop-up window to write a comment. Set xwiki.editcomment.hidden=0 in xwiki.cfg to do this.

You can use the special fields in the XWikiPreferences object instead of editing xwiki.cfg. These fields are: editcomment, editcomment_mandatory.

Configuring Directories

See XWiki Directories.

Permanent Directory

See Permanent Directory, Configure the Permanent Directory, Find the Current Permanent Directory and Sub-Directories in the Permanent Directory.

Temporary Directory

See Temporary Directory.

Redirections

XWiki supports defining redirections for incoming requests. To activate this feature, modify your xwiki.cfg file and set the following property: xwiki.preferences.redirect=1.
Then, for each redirection you want to add, add a XWiki.GlobalRedirect object to your main wiki's XWiki.XWikiPreferences document. The XWiki.GlobalRedirect object has 2 fields: pattern and destination. The URL received is matched on pattern, and if there's a match, it's replaced with the value from the destination. XWiki then redirects to the new URL.

Trusted domains

By default, redirections are only allowed to the trusted domains of the wiki. Those trusted domains are coming from two sources:
  - all domains used to access the wiki are trusted by definition, as well as the aliases used for subwikis,
  - in xwiki.properties, it's possible to specify the property url.trustedDomains to specify other domains that should be trusted.

In case a redirection is attempted on a domain not trusted, a warning is displayed in logs, and the redirection is prevented.
Note that this whole mechanism can be switched off by setting url.trustedDomainsEnabled to false in xwiki.properties.

Customizing the PDF export Look & Feel

General Architecture

Here's how the PDF and RTF exports currently work:

As shown in the diagram, you can customize 4 parts:

• The templates, pdf.vm and the referenced subparts, pdfhtmlheader.vm, pdfheader.vm, pdffooter.vm, pdftoc.vm, pdfcover.vm, which can be overridden by a copy located in a custom skin
• The CSS is used to render the content as PDF/RTF. There is no pdf.css by default. It could be created in /templates or a skin; a copy in a skin, and override the one located in /templates
• The XHTML2FO XSL transformation. The default one, xhtml2fo.xsl, is packed in a core jar, but could be overridden by a new one in a template or an xhtml2fo.xsl file in WEB-INF/classes directory, if customization needed.
• The FOP XSL transformation. The default fop.xsl is also packed in a core jar.

After the export request triggers XWiki ExportAction, the content of your document is parsed by Velocity to get the initial XHTML content. JTidy, a HTML/XHTML syntax checker and pretty printer, will clean the initial XHTML to make it XHTML compliant. No customization is possible in this step.

In order to provide your customization you need to start by tweaking the default templates (they can also be copied to a new skin) and/or by creating a new XWiki Class. To do that, simply create a new page called XWiki.PDFClass and edit it in class mode (for ex. http://yourserver.com/xwiki/bin/edit/XWiki/PDFClass?editor=class). Add the following "Text Area" properties as needed (they are all optional, so you only need to define the ones you need to use):

• style: contains the CSS information that will overwrite or complement the default pdf.css values if they exist. css4j, a CSS API implementation for the Java™ platform, will handle this.
• xhtmlxsl: contains the XHTML to FO XSL overriding the default one. It is processed by Apache Xalan, a XSLT processor for transforming XML documents into HTML, text, or other XML document types. This field needs to be the actual content of the customized xhtml2fo.xsl. Note that you can also use velocity in this field (useful to get the content of an attached .xsl file, which comes in very handy when you need to fill in a big file, since the limit of textarea properties is 60 000 characters)
• fopxsl: contains the FOP to PDF/RTF XSL overriding the default one. It is processed by Apache FOP.

The good thing about fop/xsl-fo is that the xsl-fo document is independent of the final result. So we can export the wiki documents into many formats.

Then create a new page (say XWiki.PDFTemplate) and add the XWiki.PDFClass object to it.

Last use that page when calling the PDF/RTF export using the pdftemplate parameter as in http://yourserver/xwiki/bin/export/Space/Page?format=pdf&language=en&pdftemplate=XWiki.PDFTemplate.

#template('colorThemeInit.vm')
h2 {
   color: $theme.titleColor;
}

td {
   border-color: $theme.borderColor;
}

h1, .my_Page_break {
  page-break-before:always;
}

Override the PDF Templates

Customize the PDF Footer

By default, the PDF footer will display the page number, the last author and the date the last modification was performed. In order to also display a customized message, the template pdffooter.vm must be overridden. To do that, edit the skin class (e.g. http://yourserver/xwiki/bin/edit/XWiki/XWikiSkins?editor=class) and add a "TextArea" object named pdffooter.vm:

After adding the pdffooter.vm, you might want to edit it (clicking on it opens a detailed editor) and e.g. give it a "Pretty name". In this editor, also set the "Editor" property to "pure text" as otherwise the WYSIWYG-Editor will be used:

Next, edit the skin page (e.g. http://yourserver/xwiki/bin/edit/XWiki/DefaultSkin?editor=object) and add the following code to the pdffooter.vm property:

$msg.Page <span class="page-number"></span> - $msg.get('lastmodifiedby')
$xwiki.getUserName($tdoc.author, false)
$msg.get('lastmodifiedon')
$!xwiki.formatDate($tdoc.date)
<div>
<p>CustomName SAS. All rights reserved. Confidential and proprietary document. Printed Copies are not controlled.</p>
</div>

To see the changes, just export any wiki page:

Customize the PDF Cover

For instance, this could be useful when you want to add the company's logo to the PDF cover. In order to do this, the template pdfcover.vm must be overridden. Just like for the PDF header, a "TextArea" property named pdfcover.vm must be added to the XWiki.XWikiSkins class (e.g. http://yourserver/xwiki/bin/view/XWiki/XWikiSkins?editor=class).

Next, edit the skin page (e.g. http://yourserver/xwiki/bin/edit/XWiki/DefaultSkin?editor=object) and add the following code to the pdfcover.vm property:

<img src="$xwiki.getSkinFile("logo.png")"/>

<div style="text-align: center; width: 100%;">
<h1>
#set($title = "$!pdfdoc.display('title', 'rendered')")
#if($title == '')
  $escapetool.xml($!doc.displayTitle)
#else
  $escapetool.xml($title)
#end
</h1>
<br />
<br />
$!xwiki.getUserName($tdoc.author, false)
<br />
$!xwiki.formatDate($tdoc.date)
</div>

The last step consists of attaching the image "logo.png" to the skin:

Override the CSS rules

In order to use your template when exporting a page as PDF, you need to create a class in the XWiki space and name it PDFClass. Next, edit the page in "Class" mode (e.g. http://yourserver/xwiki/bin/edit/XWiki/PDFClass?editor=class) and add the following TextArea properties:

• style: contains the CSS rules that will override the default pdf.css values; by default, there won't be a pdf.css file on your filesystem, but you can create it in the folder \webapps\xwiki\templates\ or specify it in your skin page
• xhtmlxsl: contains the XHTML2FO XSL transformation that will override the default one
• fopxsl: contains the FOP XSL transformation that will override the default one

For each property added, make sure to set the Content property metadata to PureText in order not to get the WYSIWYG editor, which would make it complex to enter XML/XSL.

Then, create the wiki page for which you want to customize the PDF export (e.g. XWiki.PDFTemplate) and add a XWiki.PDFClass object.

Supposing your wiki page Sandbox.TestPage1 contains a table, you have to edit it in "Wiki" mode and add a style parameter as shown below:

(% class="mytable" %)
|=Column 1|=Column 2
| data|data

Next, edit the template page (e.g. XWiki.PDFTemplate) in "Objects" mode and write your own CSS rules in the style property:

Because no template is used by default, you need to specify the pdftemplate parameter in the URL to use your template: http://yourserver/xwiki/bin/export/Sandbox/TestPage1/?format=pdf&pdftemplate=XWiki.PDFTemplate.

Tip: download the PDF class and PDF template for this example and test them on your wiki.

Override the xhtml2fo.xsl rules

As explained above, the entire code of xhtml2fo.xsl needs to be copied into the xhtmlxsl textarea and then customized.

For example, to disable the generation of clickable URLs in the PDF, modify the following section:

  <xsl:template match="html:a[@href]" mode="transform">
    <fo:basic-link xsl:use-attribute-sets="a-link">
      <xsl:call-template name="process-a-link"></xsl:call-template>
    </fo:basic-link>
  </xsl:template>

as

  <xsl:template match="html:a[@href]" mode="transform">
    <fo:inline>
      <xsl:call-template name="process-a-link"></xsl:call-template>
    </fo:inline>
  </xsl:template>

or disable the generation of clickable URLs for some specific href links in the PDF

  <xsl:template match="html:a[@href]" mode="transform">
    <xsl:choose>
      <!-- disable these internal links ("data-parent" attribute start with "#accordion" or href is "#my_anchor") -->
      <xsl:when test="starts-with(@data-parent,'#accordion') or @href = '#my_anchor'">
        <fo:inline>
          <xsl:call-template name="process-a-link"></xsl:call-template>
        </fo:inline>
      </xsl:when>
      <xsl:otherwise>
        <fo:basic-link xsl:use-attribute-sets="a-link">
          <xsl:call-template name="process-a-link"></xsl:call-template>
        </fo:basic-link>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template>

Debugging PDF export

To inspect the contents of the created XHTML file (and be able to style it) - turn on logging http://yourserver/xwiki/bin/view/AdminGuide/Logging and set com.xpn.xwiki level to DEBUG. After PDF export action, xwiki log file contains intermediates states XHTML code after these lines:

DEBUG c.x.x.p.i.PdfExportImpl        - Cleaning HTML: //(show XHTML code without style)//
DEBUG c.x.x.p.i.PdfExportImpl        - Cleaned XHTML:
DEBUG c.x.x.p.i.PdfExportImpl        - Applying the following CSS: //(show CSS properties)//
DEBUG c.x.x.p.i.PdfExportImpl        - HTML with CSS applied: //(show HTML code with CSS properties merged in tag with "style=" )//
DEBUG c.x.x.p.i.PdfExportImpl        - Final XHTML for export:
DEBUG c.x.x.p.i.PdfExportImpl        - Intermediary XSL-FO: //(show document with eXtensible Stylesheet Language - Formatting Objects used to generate PDF files)//
DEBUG c.x.x.p.i.PdfExportImpl        - Final XSL-FO source:
and finally DEBUG c.x.x.p.i.PdfExportImpl        - PageSequence x-page-sequence generated 3 pages.

Configuring Wiki Syntaxes and default Syntax

To configure the Wiki syntaxes available to the user when writing wiki pages, check the Rendering Administration Application.

Title behavior

The following configuration parameters (found in xwiki.cfg) can be used to control title behavior:

#-# Defines whether title handling should be using the compatibility mode or not. When the compatibility
#-# mode is active, XWiki will try to extract a title from the document content.
#-# If the document's content first header (level 1 or level 2) matches the document's title
#-# the first header is stripped.
#-# The default value is 0.
# xwiki.title.compatibility=1

#-# Defines the maximum header depth to look for when computing a document's title from its content. If no header
#-# equal or lower to the specified depth is found then the computed title falls back to the document name.
#-# The default value is 2.
# xwiki.title.headerdepth=2

#-# Defines if setting the title field must be mandatory in the WYSIWYG and Wiki editors. It is mandatory when this
#-# property is set to 1. The default value is 0 (not mandatory).
# xwiki.title.mandatory=0

Link Label Generation

Starting with XWiki Syntax 2.0 it's possible to configure how labels are generated by the system when the user doesn't provide one (e.g. [[mywiki:Main.WebHome]]).

Here's an extract from the xwiki.properties file, which is where this feature is configurable:

#-# Specifies how links labels are displayed when the user doesn't specify the label explicitly.
#-# Valid values:
#-#   %w: wiki name
#-#   %s: full space name (e.g. space1.space2)
#-#       Note: Prior to 7.4.2/8.0M2 this was only displaying the last space name
#-#   %ls: last space name. New in 7.4.2/8.0M2
#-#   %p: page name
#-#   %np: nested page name (i.e. will display the space name for Nested Pages). New in 7.4.2/8.0M2
#-#   %P: page name with spaces between camel case words, i.e. "My Page" if the page name is "MyPage"
#-#   %NP: nested page name with spaces between camel case words, i.e. "My Page" if the page name is "MyPage".
#-#        New in 7.4.2/8.0M2
#-#   %t: page title
#-#
#-# Note that if the page title is empty or not defined then it defaults to %np. This is also the case
#-# if the title cannot be retrieved for the document.
#-#
#-# The default is "%np". Some examples: "%s.%p", "%w:%s.%p".
# rendering.linkLabelFormat = %np

Rendering Cache

See the Performance page.

Allowed Pages for Inactive Users

The xwiki.cfg configuration file includes xwiki.inactiveuser.allowedpages. This property can be used to build a whitelist of pages that can be read by inactive users. The format that should be used is a comma-separated list of pages that users marked as inactive can see.

This property is needed because in XWiki, some users can be marked inactive, for example, when enabling user email verification in the administration. An inactive user has an account, but the account needs to be validated for the user to be able to access the wiki. Access rights do not apply to inactive users (they are recognized neither as XWikiGuest nor as members of XWikiAllGroup).

Rendering Transformations

You can control which Transformations are active (by default, the Macro and Icon ones are active) by editing xwiki.properties:

#-# Controls what transformations will be executed when rendering content.
#-# A transformation modifies the parsed content. For example the Icon transformation replaces some characters with
#-# icons, a WikiWord transformation will automatically create links when it finds wiki words, etc.
#-# Note that the Macro transformation is a special transformation that replaces macro markers by the result of the
#-# macro execution. If you don't list it, macros won't get executed.
#-# The default value is: rendering.transformations = macro, icon

For example, if you wish to turn off the Icon Transformation in order not to render emoticons, you'd have to define the following property: rendering.transformations = macro.

Macros categories and visibility

You can override the default categories of a macro by editing xwiki.properties.

#-# Overrides default macro categories (Each macro has default categories already defined, for example
#-# "Navigation" for the Table of Contents Macro).
#-# Note: the categories are case sensitive.
#-#
#-# Ex: To redefine the macro categories for the TOC macro so that it'd be in the "My Category" and "Deprecated" 
#-# categories + redefine the category for the Script Macro to be "My Other Category", you'd use:
# rendering.transformation.macro.categories = toc = My Category\,Deprecated
# rendering.transformation.macro.categories = script = My Other Category

You can also configure the macro categories for which macros should be hidden by default, by editing xwiki.properties:

#-# Override the default hidden macro categories.
#-# Note: the categories are case sensitive.
#-#
#-# The default value is:
# rendering.transformation.macro.hiddenCategories = Internal,Deprecated
#-#
#-# For instance, to make the "Development" category hidden by default, in addition to the "Internal" and
#-# "Deprecated" categories, you'd use:
# rendering.transformation.macro.hiddenCategories = Development,Internal,Deprecated

Note that these macros are still visible if your users have configured to show hidden pages by editing the profile preferences.

Securing Groovy Scripts

See:

• The Commons Groovy Module
• The Platform Groovy Module

Lock Duration

By default, when a user starts editing a page, a lock will be set on that page, see Page Editing. The lock is valid by default for 30 minutes, after which it gets invalidated.

In order to increase this duration, you have 2 options:

• Add a property named lock_Timeout to your xwiki.cfg configuration file, set the value in seconds (and restart XWiki). For example, for 15 minutes: lock_Timeout = 900.
• Or add the configuration in the wiki itself:
  • Edit the XWiki.XWikiPreferences document using the class editor
  • Add a Number property named lock_Timeout (case sensitive)
  • Edit the XWiki.XWikiPreferences document using the object editor
  • Find the lock_Timeout property and put the desired number of *seconds* a lock should be valid for
  • Don't forget to save the document

Editing

Default editor

You can choose which default editor to use when editing wiki content (wiki or WYSIWYG editor). XWiki uses the following strategy when deciding which editor to use:

1. If editing a TextArea object property and that property has explicitly specified a specific editor to be used to edit it, then that editor will be used. This is set when using the Class editor. For example:

   

2. Then, if no property editor is defined, or if editing standard wiki content (like page content), XWiki will check if the current user has configured an editor for a given content type. If the current edited content is of that type, then that editor will be used. For example:

   

3. Then, if no property editor is defined, XWiki will check if the current (nested) page has configured an editor for a given content type. If the current edited content is of that type, then that editor will be used. For example:

   

4. Then, if no property editor is defined, XWiki will check if the current wiki has configured an editor for a given content type. If the current edited content is of that type, then that editor will be used. For example:

   

5. Then, if no property editor is defined, XWiki will check if there's a configuration in xwiki.properties for a given content type and if the current edited content is of that type, then that editor will be used. For example:

   edit.defaultEditor.org.xwiki.rendering.syntax.SyntaxContent=text

6. Then, if no editor has been defined, XWiki will check if the current user has defined a preferred editor to use. For example:

   

7. Then, if no preferred editor to use has been defined for the current user, XWiki will check the default editor set up in the Page Administration (XWiki.XWikiPreferences of the page) . Could be set because of XWIKI-17324. For example:

   

8. Then, if no editor has been defined, XWiki will check the default editor set up in the Administration UI. For example:

   

Default WYSIWYG editor

You can configure the default WYSIWYG editor to use.

See the WYSIWYG Editor Configuration page to find out how to enable or disable editing features.

Section Editing

By default, section editing is limited to level 1 and level 2 sections. This can be controlled by editing xwiki.cfg:

#-# This parameter controls the depth of sections that have section editing.
#-# By default level 1 and level 2 sections have section editing.
xwiki.section.depth=2

You can also enable/disable section editing with:

#-# This parameter will activate the sectional editing.
xwiki.section.edit=1

Editing Conflicts

The Edit Conflict feature can be disabled since XWiki 11.3.1+, 11.4+ 

 from the xwiki.properties file by setting edit.conflictChecking.enabled = false:

#-# Indicate if the mechanism to detect and handle edition conflicts should be enabled or not.
#-# If disabled, it means that in case of edition conflicts, the latest save will be always take into account, and
#-# erase previous data (which can always be recovered in the history of the document).
#-# This option is provided because the feature is still experimental and it could be useful is some specific usecases
#-# to switch it off. However it is not recommended to do so.
#-#
#-# The default is:
# edit.conflictChecking.enabled = true

In-place Editing

To disable the in-place WYSIWYG editing mode (and thus default to the Standalone WYSIWYG editing mode), modify the xwiki.properties file and set edit.document.inPlaceEditing.enabled = false:

#-# Indicate if the XWiki documents should be edited in-place, without leaving the view mode, whenever possible (e.g. if
#-# the default edit mode for that document and the preferred editor both support in-place editing). When enabled,
#-# clicking on the document Edit button makes the document title and content editable in-place, without leaving the
#-# view mode. When disabled, clicking on the document Edit button loads the default (stand-alone) edit mode for that
#-# document.
#-#
#-# The default is:
# edit.document.inPlaceEditing.enabled = true

Delete Pages

This section is hidden when the recycle bin is not activated.

Enabling Advanced users to skip the recycle bin

Advanced users can choose to skip the recycle bin (and remove the pages permanently) when deleting pages.

To do so, search for the "Delete" section and set "can skip the recycle bin" to Yes. The default value is No.

The configuration is resolved by looking in three locations, from the most specific to the least specific:

• In the configuration of the current wiki
• In the configuration of the main wiki
• In xwiki.properties (see the property details below)

If the default value is found in one location, the next one is tried. If no value is found, the recycle bin skipping is not activated.

Details of the configuration on xwiki.properties:

#-# Indicates whether skipping the recycle bin when deleting pages is allowed for Advanced users.
#-# It is disabled by default.
#-# This setting is only used if the wiki has a recycle bin activated (xwiki.recyclebin=1 in xwiki.cfg).
#-# This setting can be overloaded:
#-# * By the main wiki in the Refactoring.Code.RefactoringConfigurationClass class of the
#-#   Refactoring.Code.RefactoringConfiguration document of the main wiki.
#-# * By sub-wikis in the Refactoring.Code.RefactoringConfigurationClass class of the
#-#   Refactoring.Code.RefactoringConfiguration document of the sub-wikis (itself overloading the main wiki's
#-#   configuration).
#-#
#-# The default value is:
# refactoring.isRecycleBinSkippingActivated = false

Readonly

In order to configure your XWiki instance to be readonly (useful when doing an upgrade by setting up a new instance and you don't want new content to be created, for example).

To achieve this, you need to edit the xwiki.cfg configuration file and set the xwiki.readonly property to true and restart XWiki.

If you want to turn on the readonly mode live without a restart, you can also execute a small snippet with a user having programming rights (a restart of XWiki will remove the readonly mode in this case), while waiting for a future feature (see issue XWIKI-10119):

{{groovy}}
def xwiki = xcontext.getXWiki()
xwiki.isReadOnly = true
{{/groovy}}

Note that this flag doesn't prevent against any modifications in your wiki, there're still some places where it's not taken into account (see issue XWIKI-18437)).

Sample xwiki.cfg

See xwiki.cfg.vm

Note that we generate the default xwiki.cfg file from this template file by applying Velocity during the build, so all $<something> properties you see in this file are replaced at build time.

Sample xwiki.properties

See xwiki.properties.vm

Note that we generate the default xwiki.properties file from this template file by applying Velocity during the build, so all $<something> properties that you see in this file are replaced at build time.

 from the xwiki.properties file by setting edit.conflictChecking.enabled = false:

#-# Indicate if the mechanism to detect and handle edition conflicts should be enabled or not.
#-# If disabled, it means that in case of edition conflicts, the latest save will be always take into account, and
#-# erase previous data (which can always be recovered in the history of the document).
#-# This option is provided because the feature is still experimental and it could be useful is some specific usecases
#-# to switch it off. However it is not recommended to do so.
#-#
#-# The default is:
# edit.conflictChecking.enabled = true

System properties and environment variables

Everything you find in the xwiki.cfg and xwiki.properties files can also be configured through Java system properties or environment variables. This is very usefull for example when you have a setup where it's much easier to pass parameter then editing files.

See Configuration Module for more details.

In-place Editing

To disable the in-place WYSIWYG editing mode (and thus default to the Standalone WYSIWYG editing mode), modify the xwiki.properties file and set edit.document.inPlaceEditing.enabled = false:

#-# Indicate if the XWiki documents should be edited in-place, without leaving the view mode, whenever possible (e.g. if
#-# the default edit mode for that document and the preferred editor both support in-place editing). When enabled,
#-# clicking on the document Edit button makes the document title and content editable in-place, without leaving the
#-# view mode. When disabled, clicking on the document Edit button loads the default (stand-alone) edit mode for that
#-# document.
#-#
#-# The default is:
# edit.document.inPlaceEditing.enabled = true

Delete Pages

This section is hidden when the recycle bin is not activated.

Enabling Advanced users to skip the recycle bin

Advanced users can choose to skip the recycle bin (and remove the pages permanently) when deleting pages.

To do so, search for the "Delete" section and set "can skip the recycle bin" to Yes. The default value is No.

The configuration is resolved by looking in three locations, from the most specific to the least specific:

• In the configuration of the current wiki
• In the configuration of the main wiki
• In xwiki.properties (see the property details below)

If the default value is found in one location, the next one is tried. If no value is found, the recycle bin skipping is not activated.

Details of the configuration on xwiki.properties:

#-# Indicates whether skipping the recycle bin when deleting pages is allowed for Advanced users.
#-# It is disabled by default.
#-# This setting is only used if the wiki has a recycle bin activated (xwiki.recyclebin=1 in xwiki.cfg).
#-# This setting can be overloaded:
#-# * By the main wiki in the Refactoring.Code.RefactoringConfigurationClass class of the
#-#   Refactoring.Code.RefactoringConfiguration document of the main wiki.
#-# * By sub-wikis in the Refactoring.Code.RefactoringConfigurationClass class of the
#-#   Refactoring.Code.RefactoringConfiguration document of the sub-wikis (itself overloading the main wiki's
#-#   configuration).
#-#
#-# The default value is:
# refactoring.isRecycleBinSkippingActivated = false

Readonly

In order to configure your XWiki instance to be readonly (useful when doing an upgrade by setting up a new instance and you don't want new content to be created, for example).

To achieve this, you need to edit the xwiki.cfg configuration file and set the xwiki.readonly property to true and restart XWiki.

If you want to turn on the readonly mode live without a restart, you can also execute a small snippet with a user having programming rights (a restart of XWiki will remove the readonly mode in this case), while waiting for a future feature (see issue XWIKI-10119):

{{groovy}}
def xwiki = xcontext.getXWiki()
xwiki.isReadOnly = true
{{/groovy}}

Note that this flag doesn't prevent against any modifications in your wiki, there're still some places where it's not taken into account (see issue XWIKI-18437)).

Sample xwiki.cfg

See xwiki.cfg.vm

Note that we generate the default xwiki.cfg file from this template file by applying Velocity during the build, so all $<something> properties you see in this file are replaced at build time.

Sample xwiki.properties

See xwiki.properties.vm

Note that we generate the default xwiki.properties file from this template file by applying Velocity during the build, so all $<something> properties that you see in this file are replaced at build time.

 from the xwiki.properties file by setting edit.conflictChecking.enabled = false:

#-# Indicate if the mechanism to detect and handle edition conflicts should be enabled or not.
#-# If disabled, it means that in case of edition conflicts, the latest save will be always take into account, and
#-# erase previous data (which can always be recovered in the history of the document).
#-# This option is provided because the feature is still experimental and it could be useful is some specific usecases
#-# to switch it off. However it is not recommended to do so.
#-#
#-# The default is:
# edit.conflictChecking.enabled = true

In-place Editing

To disable the in-place WYSIWYG editing mode (and thus default to the Standalone WYSIWYG editing mode), modify the xwiki.properties file and set edit.document.inPlaceEditing.enabled = false:

#-# Indicate if the XWiki documents should be edited in-place, without leaving the view mode, whenever possible (e.g. if
#-# the default edit mode for that document and the preferred editor both support in-place editing). When enabled,
#-# clicking on the document Edit button makes the document title and content editable in-place, without leaving the
#-# view mode. When disabled, clicking on the document Edit button loads the default (stand-alone) edit mode for that
#-# document.
#-#
#-# The default is:
# edit.document.inPlaceEditing.enabled = true

Delete Pages

This section is hidden when the recycle bin is not activated.

Enabling Advanced users to skip the recycle bin

Advanced users can choose to skip the recycle bin (and remove the pages permanently) when deleting pages.

To do so, search for the "Delete" section and set "can skip the recycle bin" to Yes. The default value is No.

The configuration is resolved by looking in three locations, from the most specific to the least specific:

• In the configuration of the current wiki
• In the configuration of the main wiki
• In xwiki.properties (see the property details below)

If the default value is found in one location, the next one is tried. If no value is found, the recycle bin skipping is not activated.

Details of the configuration on xwiki.properties:

#-# Indicates whether skipping the recycle bin when deleting pages is allowed for Advanced users.
#-# It is disabled by default.
#-# This setting is only used if the wiki has a recycle bin activated (xwiki.recyclebin=1 in xwiki.cfg).
#-# This setting can be overloaded:
#-# * By the main wiki in the Refactoring.Code.RefactoringConfigurationClass class of the
#-#   Refactoring.Code.RefactoringConfiguration document of the main wiki.
#-# * By sub-wikis in the Refactoring.Code.RefactoringConfigurationClass class of the
#-#   Refactoring.Code.RefactoringConfiguration document of the sub-wikis (itself overloading the main wiki's
#-#   configuration).
#-#
#-# The default value is:
# refactoring.isRecycleBinSkippingActivated = false

Readonly

In order to configure your XWiki instance to be readonly (useful when doing an upgrade by setting up a new instance and you don't want new content to be created, for example).

To achieve this, you need to edit the xwiki.cfg configuration file and set the xwiki.readonly property to true and restart XWiki.

If you want to turn on the readonly mode live without a restart, you can also execute a small snippet with a user having programming rights (a restart of XWiki will remove the readonly mode in this case), while waiting for a future feature (see issue XWIKI-10119):

{{groovy}}
def xwiki = xcontext.getXWiki()
xwiki.isReadOnly = true
{{/groovy}}

Note that this flag doesn't prevent against any modifications in your wiki, there're still some places where it's not taken into account (see issue XWIKI-18437)).

Sample xwiki.cfg

See xwiki.cfg.vm

Note that we generate the default xwiki.cfg file from this template file by applying Velocity during the build, so all $<something> properties you see in this file are replaced at build time.

Sample xwiki.properties

See xwiki.properties.vm

Note that we generate the default xwiki.properties file from this template file by applying Velocity during the build, so all $<something> properties that you see in this file are replaced at build time.

 from the xwiki.properties file by setting edit.conflictChecking.enabled = false:

#-# Indicate if the mechanism to detect and handle edition conflicts should be enabled or not.
#-# If disabled, it means that in case of edition conflicts, the latest save will be always take into account, and
#-# erase previous data (which can always be recovered in the history of the document).
#-# This option is provided because the feature is still experimental and it could be useful is some specific usecases
#-# to switch it off. However it is not recommended to do so.
#-#
#-# The default is:
# edit.conflictChecking.enabled = true