Page Editing

Version 365.1 by Eleni Cojocariu on 2025/08/19 16:11

Describes all the features available to edit a page.

Content Editing

To edit the content of a wiki Page you can choose to do it in 2 ways:

Section Editing

See editing a section.

Translations

You can translate the page in the current language, if the translation is missing and multilingual is on, by using the Translate button. All the following changes will be saved to the new translation.

editInPlace-translate.png

Simple and Advanced Editing

See Simple and Advanced Editing.

Common edit actions

See:


Choosing or Changing a Syntax

You have the possibility to choose or change the Syntax in three cases:

After you choose or change the Syntax, the result is a Syntax conversion of the Page.

Hiding Pages

There are two ways to hide a Page:

Form editing mode (aka inline mode)

Inline mode, or Form mode, is a special feature of XWiki, that allows administrators to define patterns of structured information (like a blog entry, or a standard tax form). Pages containing such structured information can be edited and re-edited as simple HTML Forms, which have (almost) the same structure as the displayed page. Thus, when clicking the edit button, it seems that the page content can be edited in-place, or inline and the form view is automatically displayed.

Technically the inline mode is triggered automatically differently whether the page is written in XWiki Syntax 1.0 or 2.0, using the following algorithm:

Note that it is beyond the scope of this simple guide to explain the programming technique supporting this feature. Please check the Developer's Guide to find out more about programming with Objects/Classes and Forms.

Objects editing mode

In XWiki it's possible to attach Objects to pages. Objects are simple sets of properties with values that add additional information about a page. For example a security right can be added to a page to control its rights, a blog object is attached to a page representing a blog entry, etc. Again, it's beyond this simple guide to explain this programming technique. Please check the Developer's Guide to know more about programming with Objects/Classes.

ObjectEditor.png

Classes editing mode

We've seen that some pages can have Objects attached to them. Some pages can also be Object definitions, a.k.a Classes. The Classes editing mode calls the class editor on the current page, allowing to edit the Classes attached to the page. Again, it's beyond this simple guide to explain this programming technique. Please check the Developer's Guide to find out more about programming with Objects/Classes.

ClassEditor.png

Access Rights editing mode

This mode allows you to control the access rights for the page you're viewing (you need to have the required access rights to modify a page's rights). See the Rights Management topic for more information.

Title Behavior

Pages have both names and titles. The page name is used in the URL to the page while the title is used to display a user-friendly short description of the page. The title is used for example as the top level headings when viewing a page.

Page titles can be set while editing pages in Wiki or WYSIWYG modes.

Titles are not mandatory by default but it's possible to configure XWiki to make titles mandatory.

The title's content is parsed using Velocity so you're also allowed to put Velocity content in there in addition to plain text (this is for example useful when wanting to internationalize titles). Note that you're not allowed to use any wiki markup.

When a page has no title set then XWiki will use the page name as its title.

Information

It's also possible to configure XWiki to extract the topmost heading from the page's content. For example if you have a level 1 heading, it'll be used as the page title. If you don't have a level 1 heading but have a level 2 heading then the level 2 heading will be used as the page title. The heading level depth XWiki used for titles is controlled in XWiki's title configuration. Since you're allowed to use any wiki syntax in headings, if a page doesn't have a title set (and titles are not mandatory) then any wiki markup in the topmost headings will get rendered when displaying the extracted title for that page.

However this is a backward compatibility option and we do not recommend that you use it. The reason we deprecated this behavior that allowed styling the titles is because it leads to all sorts of issues:

  • The title is used in several places including the browser's title or in LiveTable results and since those places forces to display the title in plain text, this means you'd see wiki markup or HTML displayed as is
  • When the heading is generated through a script, if that script gets executed outside of the page's rendering context, it can lead to side effects and the page title displayed in LiveTable or other places can be completely wrong

Authors

Pages have different kind of authors that are updated and manipulated for different purposes.

XWiki 14.0+

We distinguish 4 different kind of author information:

  • the creator: there's no ambiguity, it's the user who created the document
  • the content author: it's the author who performed a change in the content of the document, by opposition with changing a metadata of the document such as an xobject, or an attachment. We distinguish it for security reason since the content of the document might contain scripts that are executed when viewing the document.
  • the effective metadata author: it's the author which has been used to save any change in the document, content or not. So changing the content of the document will update both this author, and the content author. However, updating an attachment of a document will only update this author, not the content author.
  • the original metadata author: it's finally the author you see displayed in the interface, it's most of the time the same as the effective metadata author but in some usecases it might be different. For example when a script wants to allow a user to perform a save without changing the effective author for security reasons, but wants to display the author who actually triggered the save.

Locking

By default, when you edit a page, a lock is put on the page (the duration can be configured), till you either Save (any kind of Save), Cancel the edition or close the browser window.

If you keep the page open in the browser without doing any Save action, the lock will be active by default for 30 minutes (see lock duration configuration).

Anyone trying to edit a page that is locked will see the following warning message allowing you to know that the page is locked and also to force the lock.

lock.png

If you force the lock then the last user who saves will overwrite the content with his version of the page.

Edit conflict

XWiki 11.2+

XWiki detects during the edition of a page if a conflict might happen when saving the page. If this warning occurs, this means someone edited and saved the page while you were working on it.

XWiki 11.3.1+, 11.4+

You have two main choices:

  • force save the page: in that case you will override saved while you were editing the page; they are not really lost though since they might be retrieved in the previous version of the page.
  • reload the editor: in that case your changes will be lost and the editor will be reloaded with the last version saved.

We display the diff between the version you're trying to save and the last version that has been saved, so you can copy some changes made and reapply them if you like.
Note that you can also simply cancel the save and go back to the editor to make changes before trying again to save.
You can click on the arrow of each action to have a quick description of what it actually means.

XWiki 11.5+

The support of conflict edition was improved by implementing a merge on save mechanism. This means that in case of conflict edition (two users saving the same page at the same time), instead of always displaying a window to the user asking what to do, we first try to perform a merge of both page. If the changes concerned two very different parts of the page (two different sections, an edit performed on an object against an edit of the content, etc) the user won't notice that a merge has been performed.

Now, some conflicts might still occur if both users tried to edit the same part of the page. In that case, a new window is displayed asking the user what to do.
The user will now have three different choices:

  • Merge the page and fix conflict with his/her own changes: this means that as much as possible, we try to merge the changes. Only for the part that are conflicting, we only kept the changes from the last user. This is the recommended choice.
  • Force save the page: this means no merge at all will be performed. Only the changes performed by the last user will be saved. It basically discards the changes made by the previous user.
  • Reload the editor: this choice might be taken very carefully as it might cause a loss of data. It means that the current changes performed on the page will be completely lost and the editor will be reloaded with the last changes.

The conflict window now display the changes that will be performed for each choices. Be careful with the parts in red since it shows what part of the page will be lost during the operation. Note that it's also possible to select two specific versions of the page to perform a comparison before making a choice.

Information

The Conflict Edit feature can be disabled.

XWiki 11.8+

The conflict edition window allows one more choice: to fix each conflict individually. This new choice is marked as advanced since it's not something easy to handle.

When choosing the new option, the UI is updated to display the changes between the latest version saved and the current version the user is trying to save. At each place a conflict occurred, the changes display an orange bar and a blue area is reserved for the conflict resolution.
This blue area displays some text, and a select with several choices. The displayed text in the blue area is what will be used for fixing the conflict, you can see the text changing for each choice.

The conflict choices are the following:

  • current version (default): the conflict is fixed by getting the current changes
  • before your changes: the conflict is fixed by getting what was there before you starting to edit. Both latest version saved and your current changes would be lost for this conflict,
  • latest version saved: the change made on the latest version saved (the one you are conflicting with) are taken to fix the conflict
  • custom version: with this option, a text area is displayed to allow you to enter any new value to fix the conflict. Multiple lines can be entered.

If the choice text displays something in red, it is because no content is actually available for the chosen version to fix the conflict: usually it means the content in conflict will be removed with the choice made.

Extension page protection

Extension pages are protected against editing (unless explicitly indicated otherwise in the extension) to avoid mistake a user could make while still allowing advanced users to force it if really required.

extensionProtectedPage.png

Default Language

There are two ways to change the locale/default language:

Get Connected