Wikis vs Nested Pages
Last modified by Eleni Cojocariu on 2026/03/19 08:16
Content
Explanation
What Wikis bring over Nested Pages, or vice-versa:
| Feature | Supported by Wikis? | Supported by Nested Pages? | Notes/Ideas |
|---|---|---|---|
| Set a custom Skin/Color Theme/Icon Theme |  | | |
| Set custom Panels | | | |
| Delegate Administration/Right Management | | * | An administrator can give Admin rights to a user or group for a Page and all its children Pages. While implementing rights in Farm Mode is generally more challenging with Nested Pages than with a separate Wiki, it is still possible. |
| Dedicated Users and Groups | |  | Provides isolation, both in terms of visibility and security. |
| Notion of Owner | | | The Owner of a Wiki has all permissions in a Wiki. |
| Ability to install JAR Extensions | | | When installing an extension via the Extension Manager UI, you can only install it for the whole Wiki. It’s not possible to install an extension only under a specific Nested Page. The XWiki Core does have some support for space-level features (e.g., JAR components or macros that work only in one space). You can, however, restrict their activation to certain Pages or spaces using permissions or configuration. |
| Ability to install Applications/Flavors | | | When importing or using the EM UI to install an application (XAR), you cannot install it under a specific Nested Page (i.e., relative to a Nested Page). Similarly, it’s not possible to install a Flavor within a Nested Page. |
| Ability to have a dedicated domain name/Clean URL scheme and Breadcrumb | |  * | [*]Possible, but requires some configuration at the Apache level or via the URLRewriteFilter. |
| Ability to maintain the database easily | | | Each Wiki has its own schema, making maintenance, backups, and restores easy on a per-Wiki basis—ideal for farm setups. Wikis can be moved independently to another server (though some links may break, depending on usage), addressing scalability concerns. Extensions can create custom tables within a Wiki's schema, and schemas can be optimized for specific purposes, such as custom mappings. |
| Ability to easily query data across instances | * | | [*] Since each Wiki uses an independent schema, you cannot run a single database query across multiple Wikis. However, you can query content across schemas using the Query Manager’s Solr syntax. In contrast, Nested Pages reside within the same Wiki (and schema), so a single database query can access data from multiple Nested Pages. For example, displaying data from different Wikis in a LiveTable is not straightforward and typically requires custom JSON. |
| Ability to search in multiple instances | | | Solr search indexes data independently from the database storage, so searching works across both Wikis and Nested Pages. |
| Deletion of Wiki or Nested Page | * | | [*] Deleting a Nested Page will warn about broken links which is not the case when deleting a Wiki. Also, you cannot rollback a deleted Wiki, so unless you have a backup you've lost your data. You can't restore a deleted Page with a single click from the UI either, but at least you can restore each children Page under a Nested Page from the UI, or use a script. In other words, there's no Recycle bin for Wiki. |
| Renaming of Wiki or Page | | | Page Rename updates backlinks automatically, but it's not the case across Wiki. |
| Invite Users | | | You cannot invite users only for a Page, but you can invite users on a Wiki. |
| Implement a "playground" | | | Nested Pages share XClasses Pages. If you modify one XClass (e.g. XWiki.JavaScriptExtension) you affect all the Pages that use it. Wikis have to duplicate the XClasses, but this means the modifications are isolated. As a consequence, it's much harder (if not impossible) to implement a "playground" using Nested Pages than using a Wiki. |
| Easiness of upgrades | | | Harder to upgrade XWiki: each Wiki needs to be upgraded individually, even if it's only 1 click in the UI. Also it's slower to upgrade multiple wikis (e.g. when running database migrations since each Wiki is a database). |
| Easiness of creation | | | While it's fast to create Nested Pages in XWiki, creating a Wiki takes more time. In addition, creating a Wiki requires Create Wiki rights, while creating a Page requires Edit rights. |
| Scalability | | | While the number of Wikis is not limited, having an XWiki instance with thousands of wikis is not recommended (each "empty" Wiki will contain thousands of internal Pages) and thus doesn't scale in practice (long time to create, hard to upgrade). Also note the limitation that installing a XAR application on the farm means installing it on each Wiki which is resource consuming (time, memory). |
