Once you have XWiki installed you'll want to configure it. Configuration can be done in 2 ways:

• by stopping the XWiki instance and editing either the xwiki/WEB-INF/xwiki.cfg file or the xwiki/WEB-INF/xwiki.properties one, and then restarting XWiki. Note that xwiki.cfg was the historical file containing the configuration option but we're moving away from it and in due time all the XWiki configuration options will be found in xwiki.properties
• by logging in as a user with admin rights and going to the administration page using the top level menu. You can also go directly to http://localhost:8080/xwiki/bin/admin/XWiki/XWikiPreferences. This allows to keep the server running while making the changes.
  • Some configurations are only accessible from the xwiki.cfg and xwiki.properties files and have no equivalent on the administration page.
  • If you're a developer and need to understand how Configuration works in XWiki, check the Configuration Module Documentation.
  You can verify some basic settings of your XWiki installation (on Tomcat, MySQL) using the Check Config and Indexes application.

There are various things you can configure:

Enable superadmin account

Edit the xwiki.cfg file and enable the xwiki.superadminpassword property. For example:

When logging in, the username will be "superadmin" and the password will be the one you set in the xwiki.superadminpassword property.

Language settings

To define the default language for your wiki go to the administration page, click on "Localization", locate the "Default Language" field and select the language you wish to use.

In addition you can configure your wiki to be multilingual. See the I18 user page for more information.

Last, you can also force your wiki to display only in one of the languages specified in the settings, by editing your WEB-INF/xwiki.cfg file. Search for the "Internationalization" section, and you should see two commented settings that you can uncomment to fix their value (1 means true, 0 false).

Algorithm

The algorithm to find the locale to use is the following, in this order:

• If the wiki is not multilingual use the wiki default locale (default_language xproperty in XWikiPreferences xobject or English if not found).
• If the wiki is multilingual
  • Try to get the locale passed in the request (looking for a language query string parameter).
  • If the language value is default use the wiki default locale. If a parameter is found sets a language cookie to remember the language in use.
  • Try to get the locale from the language cookie
  • If the default language is preferred (xwiki.language.preferDefault from xwiki.cfg or preferDefaultLanguage property from the space preferences (WebPreferences xobject) or wiki preferences (XWikiPreferences xobject})), and since the user didn't explicitly ask for a language already, then use the wiki default locale.
  • Try to use the browser's Accept-Language header sent in HTTP request.
  • Fallback to the wiki default locale

In addition the xwiki.language.forceSupported configuration property (editable in xwiki.cfg) is enabled by default and means that if at any step above the locale found is not in the list of supported locales, then the locale is not set and the algorithm moves to the next step.

Date format

To define the date format used in the interfaces, go to Wiki -> Administer Wiki -> Localization, locate the "Date format" field and enter the date format you wish to use. Examples:

More information about date formatting.

Enabling/Disabling Statistics

To disable the Statistics feature edit your xwiki.cfg file and replace the following properties as shown here (to enable statistics, change 0 to 1):

where:

• xwiki.stats controls whether statistics are on or off
• xwiki.stats.default controls whether statistics are on or off by default for the current Wiki. This is useful in multi wiki mode. A wiki can decide whether statistics are on or off by setting the "statistics" field in XWiki.XWikiPreferences. If no such field is defined then the default value xwiki.stats.default is used.

  There's currently no UI to set the statistics on or off for a given subwiki. Thus at the moment you'll need to do 2 things:

  • Edit XWiki.XWikiPreferences to add a new boolean property to the class, by going to http://localhost:8080/xwiki/bin/edit/XWiki/XWikiPreferences?editor=class
  • Set the statistics property to true by going to http://localhost:8080/xwiki/bin/edit/XWiki/XWikiPreferences?editor=object and setting the statistics property to true

Optional Store Features

Document versioning

One of the key features of a wiki engine is the ability to keep all the history of a document, giving users the ability to see the evolution of a document, but also to revert changes. However, the history of an active wiki continuously grows and is usually much larger than the current version of the data. It is possible to disable the versioning feature in XWiki, which means that less storage space will be used, although it will not be possible to revert the document in case of vandalism.

To disable versioning edit xwiki.cfg and add xwiki.store.versioning=0.

Attachment versioning is also available and turned on by default.

Document recycle bin

By default deleted documents are not permanently removed, but are placed in a recycle bin, from which they can later be removed or restored. To disable it, edit xwiki.cfg and add xwiki.recyclebin=0.

By default, a deleted document can be permanently deleted right away by administrators, and after 7 days by regular users. To change these limits, edit xwiki.cfg and add:

Attachment recycle bin is similar.

Customizing error pages

The screen displayed to the user when an error occurs can be easily customized without modifying the skin in the following cases: when the wiki, document or attachment that is currently looked for does not exist, or when a denied access occurs. You simply need to create the following respective pages in your wiki:

• XWiki.WikiDoesNotExist,
• XWiki.DocumentDoesNotExist,
• XWiki.AttachmentDoesNotExist,
• XWiki.AccessDenied

Creating these pages rather than editing the skin's velocity files will save you time during upgrades since you won't need to merge the possibly updated skin files with yours.

Customizing the Skin

See the Skin Guide.

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 configured your proxy but it's possible to force a specific protocol using xwiki.url.protocol property in xwiki.cfg.

To setup 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

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 it's likely you're 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

See the Encoding Guide.

User Authentication

See the Authentication Guide.

Customizing the Verified Registration Page

The Verified Registration Page is part of the Administration Application and 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 which are there.

In order to turn on captcha, you simply go to the administration page, click "Registration" and you will find a checkbox for turning on captcha along with other registation page related settings.

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

You can set the default groups which new users will automatically be added to by changing the xwiki.users.initialGroups parameter in your xwiki.cfg file. To make all new users be added to the groups XWiki.CoolPeople and XWiki.CommunityMembers you will have to set the initialGroups parameter like this:

• Current members will not be automatically be added to these groups, only new members.
• The groups have to be created before being specified as initial groups.

Logging

See the Logging page.

Configuring Interwiki links

Interwiki linking is a short hand syntax for linking to pages on other websites. For example, you could link to http://en.wikipedia.org/wiki/InterWiki just by typing [[InterWiki@WikiPedia]].

Interwiki links (XWiki Syntax 1.0)

Since XWiki renders wiki syntax using the Radeox engine, it supports Interwiki links in much the same way as SnipSnap. 

To configure Interwiki links on your wiki:

• Create a file named [location from where you start your container]/conf/intermap.txt
• Fill intermap.txt with content like:
  IMDB http://us.imdb.com/Title?
  OpenWiki http://openwiki.com/?
  SourceForge http://sourceforge.net/
  TWiki http://twiki.org/cgi-bin/view/
  Why http://clublet.com/c/c/why?
  Wiki http://c2.com/cgi/wiki?
  WikiPedia http://www.wikipedia.com/wiki/
  You can of course add your own entries.

Restart XWiki (you'll need to restart XWiki every time you change intermap.txt) and try out an Interwiki link. If it does not work, check your xwiki.log file. You'll see if conf/intermap.txt could not be found, or if there was an error parsing it.

Interwiki links (XWiki Syntax 2.x)

In order to use Interwiki links in the XWiki Syntax 2.x it is necessary to configure the appropriate list in your xwiki.properties file. Look for the following section:

Link URLs

With parameters, you can specify what type of links will be made by XWiki.

Reverse proxy setup

XWiki can and does run behind reverse proxies such as Apache mod_proxy. Usually the only thing needed is to have the x-forwarded-host http header set to the external URL and XWiki will write links correctly.

Some reverse proxy software does not set this header and with XWiki 3.0M3 or newer, you can use the xwiki.home parameter in single wiki instances (non farm) to achieve the same result.

• xwiki.home - parameter in xwiki.cfg will be used to make all links pointing to the main wiki on the server. If your main wiki is called "xwiki" but you want your users to access it by going to www.yoursite.tld instead of xwiki.yoursite.tld, you may set the xwiki.home parameter to http://www.yoursite.tld/
  This parameter will also work for single wiki instances and will be the final authority if the x-forwarded-host parameter is not set.

• xwiki.url.protocol - with the xwiki.url.protocol parameter in xwiki.cfg you can explicitly specify the protocol as https. This is useful if you are running xwiki behind a reverse proxy which converts https into plain http so xwiki only sees http.

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 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, if you wish to turn them off based on some programmatic rule (such as display them only for Administrators), you should define the properties in the layoutExtraVars.vm template file from your XWiki installation. For example:

Configure "Version Summary" behavior

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

When the "Version Summary" feature is enabled, you can also set "Version Summary" to be mandatory by setting xwiki.editcomment.mandatory=1 in xwiki.cfg. This will show a popup window with the request to write a short comment if there is no comment 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 also remove the "Version Summary" field and use only a popup window for writing 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, editcomment_suggested and editcomment_hidden.

Configuring Directories

XWiki uses the following directories:

• A Temporary directory. It's used for example to cache images after re-sizing them or store attachments after loading them out of the database.
• A Permanent directory. It's used for storing data such as extensions and filesystem attachments which must not be deleted and search indexes which are replaceable but laborious to create.

Permanent Directory

To set the permanent directory, you have 2 options:

• Set the xwiki.data.dir system property when starting the JVM (ie. the Servlet Container's JVM, specifically: -Dxwiki.data.dir=...)
• Set the environment.permanentDirectory property in your xwiki.properties file

Make sure to choose a folder different from the XWiki home on which XWiki (which usually means whatever user running the application server in which XWiki is installed) has write access. For example the standard Debian package use /var/lib/xwiki/data which is usually a good fit for many Linux distributions.

If the location points to a file or a directory to which XWiki does not have write access to, a warning will be printed in the log and the temporary directory will be used as a default. The temporary directory can be periodically cleaned and all its content deleted so it is critical that it is not used for anything else. Thus it's especially important to set the Permanent directory to not point to the temporary directory.

List of sub-directories in the permanent directory:

• store: Data stores
  • store/file: Attachments (when they're saved on the filesystem, which is the default, otherwise they're saved in the database), and deleted documents. Note that even when attachments are saved on the filesystem the attachment metadata are saved in the database (e.g. creator, date, etc).
  • store/solr: Solr configurations and data which are not possible to reindex from a different data source (cache data is located in cache, see below).
• extension: Installed extensions and metadata about where they are installed.
• cache: Cache files. These files and subdirectories can be removed, XWiki will regenerate them (e.g. the Solr seach indexes). However that can take a lot of time. Examples of what's contained in the cache:
  • Solr search indexes
  • Descriptors of core extensions. If you delete them, XWiki will simply try to resolve those extensions again at startup but it won't need to resolve much since the WAR embeds complete descriptors for all the JARs. Removing this directory allows cleaning descriptors that were downloaded in previous versions of XWiki.
  • FOP Font cache
• mails: The Mail Sender API (used by several features of XWiki that require sending mails) will serialize email messages in this directory before they are sent, so that if XWiki crashes or is stopped, those mails are not lost and can be resent. Once a mail is successfully sent, its associated file is removed from this directory. Thus this directory will contain mails that failed to be sent.
• logs: Contains the xwiki logs but this is only true for the XWiki Standalone packaging which has Jetty configured to generate its logs in this directory.
• jobs/status: Logs and statuses of the various background jobs executed inside XWiki (e.g. when deleting a page or set of pages a job is used). The path follows the job id. Note that most of them are used only to remember what happened during the job execution and are generally safe to remove but some might use the job status for other purposes. Here are a few example of standard jobs (but there can be more coming from extensions):
  • jobs/status/distribution: Remember the decisions taken in the Distribution Wizard (DW) of each wiki (usually during install/upgrade). It's recommended to keep them but the worst that can happen when deleting them is getting the DW again during next restart (if one of the step is triggered, for example when you have an orphaned or invalid extension installed) and have to cancel again some steps until the next upgrade
  • jobs/status/extension: Removing them is safe and won't have any impact other than loosing the log of latest install/uninstall of each extension
  • jobs/status/refactoring: Removing them is safe and won't have any impact other than loosing the log of latest refactoring operations
  • jobs/status/solr/indexer: Removing it is safe and won't have any impact other than loosing the log of latest Solr indexing operation
  • jobs/status/wikicreation: Removing it is safe and won't have any impact other than loosing the log of latest wiki creation operations
• database: This is only true for the XWiki Standalone packaging and it contains the HSQLDB database data (i.e. the wiki pages and more).
• mentions: The Mentions Application uses this directory to store the queue of documents that are waiting to be analysed for new mentions.
• observation: The Observation Module Remote uses this directory to store the unique identifier of the instance in a cluster.
• XWiki 15.9+ configuration.properties: Contains configuration generated by XWiki itself (for example the validation and encryption keys used for cookies when not provided in xwiki.cfg)

Temporary Directory

The temporary directory is taken from the Servlet Container's javax.servlet.context.tempdir Servlet Context property and thus must be configured at that level. If it is pointed to a file or directory where XWiki cannot write, it will print a warning in the log and attempt to use the java.io.tmpdir System property. If this is not a writable directory, an exception will be thrown.

Also note that 3rd party libraries used by XWiki could be using another temporary directory. Usually that would the tmp dir provided by the JVM, i.e. the location pointed to by the java.io.tmpdir System property.

Configuring WebDAV (since 1.7)

WebDAV support has been added to XWiki beginning with XWiki 1.7. It is very important to note that WebDAV is enabled by default.

Securing WebDAV Server

XWiki's WebDAV implementation only supports the Basic Access Authentication scheme for authenticating WebDAV clients. Because of this reason it is highly recommended that you employ a transport level security mechanism like SSL to protect your clients. You may consult your web application container's documentation to see how this can be achieved.

Disabling WebDAV

To disable WebDAV support in your XWiki server, simply edit your web.xml file and remove the url-mapping element for mapping webdav requests. The url-mapping element for WebDAV looks like this:

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 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 settings 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 used to render the content as PDF/RTF. There is no pdf.css by default. It could be created in /templates or in a skin; a copy in a skin, override the one located in /templates
• The XHTML2FO XSL transformation. The default one, xhtml2fo.xsl, is packed in a core jar but it could be override by a new  one in a template or a xhtml2fo.xsl file in WEB-INF/classes directory, if customization needed.
• The FOP XSL transformation. The default one, 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 own 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 take care of 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 of 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.

Override the PDF Templates

Customize the PDF Footer

By default, the PDF footer will display the page number, the last author and the date on which 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:

To see the changes, just export any wiki page:

Customize the PDF Cover

This could be useful when you want for instance 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:

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

Override the CSS rules

In order to use your own 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 to not get the WYSIWYG editor which would make it complex to enter XML/XSL.

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

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:

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 in order to use your own 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 in the xhtmlxsl textarea and then customized.

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

as

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

Debugging PDF export

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

Configuring Wiki Syntaxes and default Syntax

To know how to configure the Wiki syntaxes that are 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:

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]]).

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

Rendering Cache

See the Performance page.

Allowed Pages for Inactive Users

The xwiki.cfg configuration file includes a property called 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 that are marked as inactive are allowed to see.

This property is needed due to the fact that in XWiki, some users can be marked as inactive, for example when enabling user email verification in the administration. An inactive user has an account, but the account needs to be validated in order 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 default) by editing xwiki.properties:

For example if you wish to turn off the Icon Transformation in order to not 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.

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

Note that these macros are still visible if your users has been configured to show hidden pages.

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, and 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 and 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 and 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 and 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 you can 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:

You can also enable/disable section editing with:

Editing Conflicts

The Edit Conflict feature can be disabled (XWiki 11.3.2 and XWiki 11.6RC1) from the xwiki.properties file by setting edit.conflictChecking.enabled = false:

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:

Delete Pages

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

Enabling Advanced users to skip the recycle bin

Advanced users can be allowed choose if they want 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.

Advanced users can be allowed choose if they want 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 on 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:

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:

Note that this flag doesn’t prevent against any modifications in your wiki, there’s still some places where it’s not taken into account.

Sample xwiki.cfg

See xwiki.cfg.vm

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