Skip to Content

Published

Finish the conversion of the Upgrade documentation into the documentation tree

Last modified by Eleni Cojocariu on 2026/08/13 15:14

Finishes the conversion of Documentation.AdminGuide.Upgrade (revision 49.2 as the source, since later revisions are already partly stripped) into documentation.xs.admin.upgrade, and reviews the 14 pages the topic already had against the Documentation Guide.

The legacy page was a hub that assembled its "Part 1" from four transcluded pages, so three procedures had never been converted and were still reachable only through it. They are now pages of the new tree, and the legacy tree keeps no documentation of its own.

New pages

Content corrected against the sources

  • The "invalid extension" log sample was 12 years out of date and in the wrong format. It showed org.xwiki.enterprise artifacts and separated artifact from version with a hyphen; the current message uses a slash, and carries the InvalidExtensionException reason that actually explains the warning. Taken from the assertion in Upgrade1011Test rather than retyped, and the explanation is now the real mechanism (an installed extension pins the versions of its dependencies, so replacing the core extensions invalidates it) instead of "they may have been renamed, removed or have versions that do not match".
  • The Java requirement was pinned to an unsupported version. The legacy text described the Java 17 boundary of XWiki 16.x; per the Java Support Strategy the boundaries that matter now are Java 17 since 16.0.0 and Java 21 since 18.0.0, so the page states both and the symlink example targets java-21-openjdk-amd64.
  • The Debian package names were stale. xwiki-tomcat9-mariadb appeared as the example package; the distribution builds xwiki-tomcat10-*, xwiki-tomcat11-* and xwiki-xjetty-* (verified in xwiki-platform-distribution-debian), so the examples use tomcat11 and the FAQ gives the naming pattern.
  • "Database Upgrade" implied migrations are off by default. xwiki.store.migration=1 is uncommented in the shipped xwiki.cfg; what makes the check worth doing is that it is commonly disabled in production for a faster startup, which is what the page now says.

Broken and silently-dropped links

  • "Upgrades Troubleshootings" listed its two children as unresolved links — XWiki startup hanging during Solr initialization with no target, which renders as a red wikicreatelink to a page that does not exist. Both now link to the pages they name, and the third bullet ("Configuration issues caused by changes in dependencies, servlet containers, or runtime environments") is dropped: it named no page and no symptom.
  • "Distribution Upgrades" sent three of its four methods back to the legacy page, through anchors on a same-wiki link — which xwiki.org drops unless a queryString accompanies them, so the reader landed at the top of the legacy page. All four now point at pages of the new tree.
  • Two anchor-only links pointed a page at its own FAQ and were dropped in the same way: the manually merge link on "Upgrade the Demo Package" now points at Unix Merge Configuration Files, and the last step of the Distribution Wizard page no longer links to its own "Are all the wikis upgraded automatically?" entry.

Duplication removed

  • The FAQ entry "What if the migration of the database fails?" was on both "Database Upgrade" and "Upgrade the Demo Package", word for word. It stays on "Database Upgrade", which is the page the other one includes.
  • The FAQ entry "How to do the merge of the files on Unix operating systems?" existed only to link the merge page that the step now links directly.

Documentation Guide fixes on the existing pages

  • The three WIP warning banners are gone (the hub, "Upgrades Troubleshootings", "XWiki Startup Stuck during Solr Initialization" and the Distribution Wizard page), since the topic is now complete.
  • A result step closes each How-to. All five stopped on their last action, so the reader could not tell whether the upgrade had worked. On the Distribution Wizard page the existing report screenshot becomes that step.
  • Titles: "Upgrades Troubleshootings" reads as "Upgrade Troubleshooting"; using is capitalised in the two flavor titles, per English title case.
  • Types and audiences: "Database Upgrade" was targeted at user although it is about editing xwiki.cfg on the server — now administrator; "Upgrade the Flavor Using the Export/Import Method" was typed tutorial although it is a generic procedure with no worked example — now howto.
  • The hub did not link two of its children. "Move XWiki to a New Server and Upgrade it" and the troubleshooting page were reachable only through the automatic "More" table. The hub also had its three recommendations as a numbered list, which is a procedure inside an Explanation, so they are a plain list now.
  • "Unix Merge Configuration Files" described commands that were all in one block at the end, so neither section contained the commands it described. The block is split into the two sections.
  • Typos: permananet (twice), upgarde (twice), limitatations, Distrivution.

The legacy pages

Documentation.AdminGuide.Upgrade and its three remaining children (UpgradeDebian, UpgradeWAR, UpgradeDocker) keep only a pointer at the new pages. The old section anchors are preserved with the {{id}} macro — HDowngrading, HPart2Upgradingtheflavor, HAlternativeStartfresh2CplusExportandReimportyourdata and the four HMethod1.* ones — because they are what saved links and the release notes use. The "Upgrading" section of the Debian installation page keeps its heading and its HUpgrading anchor and points at the new How-to, rather than leaving the procedure duplicated. None of these pages has any attachment, so there is none to delete.

Backlinks of the legacy page were triaged rather than rewritten wholesale: the two documentation pages that linked to it for prose reasons are repointed (Wikis vs Nested Pages and the Related links of Installation), while the fifteen MyXWiki.org upgraded to … blog posts, the two release notes and the download-form feedback page are left alone as dated records.

Applied outside this change request

"Upgrade XWiki Installed in Docker" was moved from documentation.xs.admin.upgrade to documentation.xs.admin.upgrade.distribution, so that the four distribution methods are siblings under the hub that lists them. A change request cannot carry a move, so it was done as a rename with "Update links" and an automatic redirect: the old URL still resolves, and the one incoming link (the Related links of "Install XWiki using Docker") was repointed automatically.

Known limitation, not fixed here

The five screenshots on the Distribution Wizard page are 799 to 803 pixels wide but are displayed at size="large" (650px) and inside a Gallery, so the browser rescales them. Re-capturing them at the exact width requires running a real flavor upgrade — an instance of an older version upgraded to the current one — which is what the flavor-test-upgrade integration tests set up. They are left as they are, and are worth a follow-up. For the same reason the new pages carry no screenshot: the Debian, .war and Java procedures happen on a terminal, where the code examples are what shows the reader the commands and the messages to look for.

All changes

Summary

Details

Page properties
Title
... ... @@ -1,0 +1,1 @@
1 +Upgrade XWiki Installed from the Debian Packages
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.XWikiGuest
1 +XWiki.elenicojocariu
Default language
... ... @@ -1,0 +1,1 @@
1 +en
Content
... ... @@ -1,0 +1,31 @@
1 +To upgrade an XWiki instance [[installed from the Debian packages>>Documentation.AdminGuide.Installation.InstallationViaAPT.WebHome]]:
2 +
3 +1. Back up the database, the [[configuration files and the permanent data>>xwiki:Documentation.AdminGuide.Backup]].
4 +1. Check the [[Release Notes>>xwiki:ReleaseNotes.WebHome]] of every version between the one you are running and the one you are upgrading to.
5 +1. Update the packages index:(((
6 +{{code language="bash"}}
7 +sudo apt update
8 +{{/code}}
9 +)))
10 +1. Stop the servlet container and uninstall it, //only// when the new XWiki version no longer supports the version you are running, since two versions of Tomcat cannot run at the same time by default:(((
11 +{{code language="bash"}}
12 +sudo systemctl stop tomcat10
13 +sudo apt remove tomcat10
14 +{{/code}}
15 +
16 +Removing the container also removes the XWiki packages that depend on it, so install the package for the new container and the database you already use:
17 +
18 +{{code language="bash"}}
19 +sudo apt install xwiki-tomcat11-mariadb
20 +{{/code}}
21 +)))
22 +1. Upgrade the packages:(((
23 +{{code language="bash"}}
24 +sudo apt upgrade
25 +{{/code}}
26 +)))
27 +1. Check that migrations are enabled, as described in [[Database Upgrade>>documentation.xs.admin.upgrade.distribution.database-upgrade.WebHome]].
28 +1. Restart the servlet container.
29 +1. [[Upgrade the flavor>>documentation.xs.admin.upgrade.flavor.WebHome]] from a browser, which the Distribution Wizard offers as soon as you log in.
30 +
31 +The wiki then runs the new version, and its Pages are the ones the flavor upgrade installed.
DocApp.Code.DocumentationClass[0]
FAQ
... ... @@ -1,0 +1,11 @@
1 +== How do I upgrade XWiki without upgrading every other package? ==
2 +
3 +Install the top-level package instead of running a full upgrade: ##sudo apt install xwiki-tomcat11-mariadb##, replacing the name with the package you actually installed.
4 +
5 +== Why does apt refuse to upgrade the xwiki packages? ==
6 +
7 +Either a dependency cannot be found, because the new XWiki version requires a [[Java version XWiki requires>>dev:Community.SupportStrategy.JavaSupportStrategy.WebHome]] that your repository has no package for — see the "No package can be found for Java" section of [[Installation using Debian/Ubuntu (.DEB) packages>>Documentation.AdminGuide.Installation.InstallationViaAPT.WebHome]] — or the package name changed because XWiki dropped support for the servlet container version you were using.
8 +
9 +== Which package name do I need after XWiki drops a Tomcat version? ==
10 +
11 +The one matching the new container and your database, in the form ##xwiki-tomcat<version>-<database>## — for example ##xwiki-tomcat11-pgsql##. The ##xwiki-xjetty-*## packages follow the same pattern.
Related
... ... @@ -1,0 +1,3 @@
1 +* [[Installation using Debian/Ubuntu (.DEB) packages>>Documentation.AdminGuide.Installation.InstallationViaAPT.WebHome]].
2 +* [[Java Support Strategy>>dev:Community.SupportStrategy.JavaSupportStrategy.WebHome]].
3 +* [[Servlet Container Support Strategy>>dev:Community.SupportStrategy.ServletContainerSupportStrategy.WebHome]].
Target
... ... @@ -1,0 +1,1 @@
1 +administrator
Type
... ... @@ -1,0 +1,1 @@
1 +howto
DocApp.Code.DocumentationExtensionClass[0]

Creation of Upgrade the XWiki .war Package

Summary

Details

Page properties
Title
... ... @@ -1,0 +1,1 @@
1 +Upgrade the XWiki .war Package
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.XWikiGuest
1 +XWiki.elenicojocariu
Default language
... ... @@ -1,0 +1,1 @@
1 +en
Content
... ... @@ -1,0 +1,15 @@
1 +To upgrade an XWiki instance [[installed from the ##.war## package>>documentation.xs.admin.installation.methods.install-xwiki-war.WebHome]], replace the deployed web application rather than copying the new files over it:
2 +
3 +1. Back up the database, the [[configuration files and the permanent data>>xwiki:Documentation.AdminGuide.Backup]].
4 +1. Check the [[Release Notes>>xwiki:ReleaseNotes.WebHome]] of every version between the one you are running and the one you are upgrading to, which is where any required manual operation is announced.
5 +1. [[Download the new ##.war## distribution>>xwiki:Main.Download]].
6 +1. Stop the servlet container.
7 +1. Delete the previously deployed web application directory, keeping your backup.
8 +1. Deploy the new ##.war##.
9 +1. Merge your customizations into the new configuration files, rather than restoring the old ##xwiki.cfg##, ##xwiki.properties## and ##hibernate.cfg.xml## over the new ones, since the new version may have added options.
10 +1. Set ##environment.permanentDirectory## in ##WEB-INF/xwiki.properties## to the permanent directory the instance was already using.
11 +1. Check that migrations are enabled, as described in [[Database Upgrade>>documentation.xs.admin.upgrade.distribution.database-upgrade.WebHome]].
12 +1. Start the servlet container.
13 +1. [[Upgrade the flavor>>documentation.xs.admin.upgrade.flavor.WebHome]] from a browser, which the Distribution Wizard offers as soon as you log in.
14 +
15 +The wiki then runs the new version against the data it had before, and the log may report [[extensions that became invalid>>documentation.xs.admin.upgrade.distribution.upgrade-war-package.invalid-extensions.WebHome]].
DocApp.Code.DocumentationClass[0]
FAQ
... ... @@ -1,0 +1,7 @@
1 +== Can I copy the new ##.war## over the current installation? ==
2 +
3 +No. Old JARs left behind in ##WEB-INF/lib## can stop XWiki from starting, and the new files would overwrite the configuration you customized in ##WEB-INF##.
4 +
5 +== Why must the permanent directory stay the same? ==
6 +
7 +It holds data that is not in the database — the Solr indexes, the extension repository and, depending on your configuration, the attachments — so pointing the new instance elsewhere starts it with none of that.
Related
... ... @@ -1,0 +1,2 @@
1 +* [[Install XWiki .war Package Manually>>documentation.xs.admin.installation.methods.install-xwiki-war.WebHome]].
2 +* [[Configure a Servlet Container>>documentation.xs.admin.installation.methods.install-xwiki-war.configure-servlet-container.WebHome]].
Target
... ... @@ -1,0 +1,1 @@
1 +administrator
Type
... ... @@ -1,0 +1,1 @@
1 +howto
DocApp.Code.DocumentationExtensionClass[0]

Summary

Details

Page properties
Title
... ... @@ -1,0 +1,1 @@
1 +Invalid Extensions after an Upgrade
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.XWikiGuest
1 +XWiki.elenicojocariu
Default language
... ... @@ -1,0 +1,1 @@
1 +en
Content
... ... @@ -1,0 +1,11 @@
1 +After [[upgrading the ##.war## package>>documentation.xs.admin.upgrade.distribution.upgrade-war-package.WebHome]], the log can report as invalid extensions that were valid before the upgrade:
2 +
3 +{{code language="none"}}
4 +WARN ltInstalledExtensionRepository - Invalid extension [org.xwiki.platform:xwiki-platform-distribution-flavor-mainwiki/10.11.1] on namespace [wiki:xwiki] (InvalidExtensionException: Dependency [org.xwiki.platform:xwiki-platform-oldcore-[10.11.1]] is incompatible with the core extension [org.xwiki.platform:xwiki-platform-legacy-oldcore])
5 +{{/code}}
6 +
7 +An installed extension records the versions of the extensions it depends on. Replacing the distribution replaces the core extensions the wiki runs on, so an extension installed against the previous distribution can no longer be satisfied: its dependency is pinned to the version that is gone. An extension that was renamed or removed in the new version becomes invalid for the same reason.
8 +
9 +These messages are warnings, not failures: the wiki starts and its content is intact. The extension is simply not usable until a version matching the new distribution is installed, which is what the [[flavor upgrade>>documentation.xs.admin.upgrade.flavor.WebHome]] does, the Distribution Wizard offers the valid versions and removes the ones that became invalid.
10 +
11 +The message therefore does not need acting on by itself. It is worth reading, though: the extensions it names are the ones the flavor upgrade has to fix, so any that are still reported after the upgrade point at an extension the Distribution Wizard could not resolve.
DocApp.Code.DocumentationClass[0]
Target
... ... @@ -1,0 +1,1 @@
1 +administrator
Type
... ... @@ -1,0 +1,1 @@
1 +explanation
DocApp.Code.DocumentationExtensionClass[0]

Summary

Details

Page properties
Title
... ... @@ -1,0 +1,1 @@
1 +XWiki Startup Failure after a Required Java Upgrade
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.XWikiGuest
1 +XWiki.elenicojocariu
Default language
... ... @@ -1,0 +1,1 @@
1 +en
Content
... ... @@ -1,0 +1,33 @@
1 +An XWiki version can require a newer Java version than the one you are running — Java 17 since XWiki 16.0.0, and Java 21 since XWiki 18.0.0. When the servlet container is still started with the previous Java, XWiki does not report a requirement error: the container only says that the web application failed.
2 +
3 +{{code language="none"}}
4 +Context [/xwiki] startup failed due to previous errors
5 +{{/code}}
6 +
7 +=== Cause ===
8 +
9 +The servlet container runs its own JVM, chosen independently of the system default, so upgrading XWiki does not change it and installing a newer JDK does not necessarily change it either. Tomcat reports the version it uses shortly after starting:
10 +
11 +{{code language="none"}}
12 +[info] JVM Version: 11.0.21+9-post-Ubuntu-0ubuntu122.04
13 +{{/code}}
14 +
15 +The leading number is the Java version — ##11## here, where XWiki 18 needs 21. Two things commonly pin it: a ##JAVA_HOME## hard-wired in the container's configuration file, such as ##/etc/default/tomcat10##, and, on Debian-based distributions, the ##default-java## symbolic link that ##apt## does not always repoint when a newer JDK is installed.
16 +
17 +=== Solution ===
18 +
19 +1. Read the JVM version the container reports in its log, and compare it with the [[Java version XWiki requires>>dev:Community.SupportStrategy.JavaSupportStrategy.WebHome]].
20 +1. Check the container's configuration file for a ##JAVA_HOME## setting, and point it at the required JDK.
21 +1. Check the ##default-java## link when the configuration sets no ##JAVA_HOME##:(((
22 +{{code language="none"}}
23 +ls -l /usr/lib/jvm/
24 +{{/code}}
25 +)))
26 +1. Repoint that link at the required JDK when it still resolves to the old one:(((
27 +{{code language="none"}}
28 +cd /usr/lib/jvm
29 +sudo rm default-java
30 +sudo ln -s java-21-openjdk-amd64 default-java
31 +{{/code}}
32 +)))
33 +1. Restart the servlet container, and confirm that the JVM version it now reports is the required one.
DocApp.Code.DocumentationClass[0]
FAQ
... ... @@ -1,0 +1,7 @@
1 +== Does XWiki run on a newer Java than the one it requires? ==
2 +
3 +Yes, within the versions the [[Java version XWiki requires>>dev:Community.SupportStrategy.JavaSupportStrategy.WebHome]] lists as supported for your XWiki version — a version newer than those is not tested and may fail.
4 +
5 +== Are extra JVM options needed? ==
6 +
7 +Yes, since Java 17 XWiki needs a set of ##add-opens## switches, listed on the {{code language="none"}}Java Support Strategy{{/code}} page. The Debian packages and the standalone distribution set them for you.
Related
... ... @@ -1,0 +1,2 @@
1 +* [[Java Support Strategy>>dev:Community.SupportStrategy.JavaSupportStrategy.WebHome]].
2 +* [[Configure a Servlet Container>>documentation.xs.admin.installation.methods.install-xwiki-war.configure-servlet-container.WebHome]].
Target
... ... @@ -1,0 +1,1 @@
1 +administrator
Type
... ... @@ -1,0 +1,1 @@
1 +explanation
DocApp.Code.DocumentationExtensionClass[0]

Edition of Upgrade

Summary

Details

Page properties
Content
... ... @@ -1,25 +1,12 @@
1 -{{warning}}
2 -WIP: the whole documentation for the Upgrade topic is being under refactoring. Complete documentation is still in [[Upgrade>>Documentation.AdminGuide.Upgrade.WebHome]].
3 -{{/warning}}
1 +Upgrading an XWiki instance brings it to a newer version, so that it benefits from the latest features and stops being exposed to the security issues fixed since.
4 4  
5 -You can upgrade your XWiki instance to newer versions to stay up to date, benefit from the best new features and keep your data safe from security threats.
3 +Before starting:
6 6  
7 -Before proceeding with an upgrade, it is strongly recommended to:
5 +* [[Back up your data>>xwiki:Documentation.AdminGuide.Backup]], so that the instance can be restored if the upgrade goes wrong.
6 +* [[Update the installed extensions>>extensions:Extension.Extension Manager Application||anchor="HUpgrade"]], because a newer version of an extension often carries the compatibility fix the new XWiki version needs.
7 +* Read the [[Release Notes>>xwiki:ReleaseNotes.WebHome]] of every version between the one you are running and the one you are upgrading to, in particular the sections named {{code language="none"}}"Issues specific to XWiki <version>"{{/code}} and any change to the [[prerequisites>>documentation.xs.admin.installation.prerequisites.WebHome]].
8 8  
9 -1. [[Backup your data>>xwiki:Documentation.AdminGuide.Backup]].(((
10 -* Create a full backup of your data, just in case something goes wrong with the update/[[downgrade>>Documentation.AdminGuide.Upgrade.WebHome||anchor="HDowngrading"]].
11 -)))
12 -1. [[Upgrade the extensions first>>extensions:Extension.Extension Manager Application||anchor="HUpgrade"]].(((
13 -* It is recommended to update all installed extensions to make sure that all they are up to date since new versions might contain compatibility fixes that would have otherwise preventing the new version fully start.
14 -)))
15 -1. Check the [[Release Notes>>xwiki:ReleaseNotes.WebHome]].(((
16 -* Review the release notes for the versions between your current version and the target version.
17 -* Pay special attention to sections titled {{code language="none"}}"Issues specific to XWiki <version>"{{/code}} and to any changes in [[hardware of software requirements (prerequisites)>>documentation.xs.admin.installation.prerequisites.WebHome]].
18 -)))
9 +An upgrade then has two parts, in this order:
19 19  
20 -There are multiple methods to upgrade XWiki depending on how many data you need to migrate or how experienced you are with different tools. In the majority of cases an upgrade consists of two parts:
21 -
22 -(((
23 -* Part 1: [[Upgrading the distribution>>documentation.xs.admin.upgrade.distribution.WebHome]] (server side).
24 -* Part 2: [[Upgrading the flavor>>documentation.xs.admin.upgrade.flavor.WebHome]] (wiki Pages).
25 -)))
11 +* [[Upgrading the distribution>>documentation.xs.admin.upgrade.distribution.WebHome]] — the XWiki software on the server, replaced from the filesystem or through the package manager.
12 +* [[Upgrading the flavor>>documentation.xs.admin.upgrade.flavor.WebHome]] — the wiki Pages, updated from a browser.
DocApp.Code.DocumentationClass[0]
FAQ
... ... @@ -1,3 +1,7 @@
1 1  == Do I need to upgrade to each intermediary version? ==
2 2  
3 3  No. XWiki provides migration paths that allow you to upgrade directly from any older version to a newer one. You do not need to install intermediary versions.
4 +
5 +== Can I return to the previous version if the upgrade goes wrong? ==
6 +
7 +Restoring the backup you took beforehand is the reliable route, because an upgrade changes the database schema and the permanent directory; see [[Downgrade your Wiki>>documentation.xs.admin.downgrade-your-wiki.WebHome]].

Summary

Details

Page properties
Content
... ... @@ -1,8 +1,8 @@
1 -The first step of an [[upgrade>>documentation.xs.admin.upgrade.WebHome]] is upgrading the distribution. This updates the XWiki software installed on your server or filesystem. You can upgrade the XWiki distribution using one of the following methods, depending on your [[installation method>>documentation.xs.admin.installation.WebHome]]:
1 +The first part of an [[upgrade>>documentation.xs.admin.upgrade.WebHome]] is upgrading the distribution, which replaces the XWiki software installed on your server. Use the method matching the way XWiki was [[installed>>documentation.xs.admin.installation.methods.WebHome]]:
2 2  
3 -* [[Upgrading from the Debian package>>Documentation.AdminGuide.Upgrade.WebHome||anchor="HMethod1.AUpgradingfromtheDebianpackage.DEB"]].
4 -* [[Upgrade from the Docker image>>Documentation.AdminGuide.Upgrade.WebHome||anchor="HMethod1.BUpgradingfromDocker.Docker"]].
5 -* [[Upgrade the ##.war## package>>Documentation.AdminGuide.Upgrade.WebHome||anchor="HMethod1.CUpgradingtheWAR.WAR"]].
6 -* [[Upgrade the standalone (demo) package>>documentation.xs.admin.upgrade.distribution.upgrade-zip-package.WebHome]].
3 +* [[Upgrade XWiki Installed from the Debian Packages>>documentation.xs.admin.upgrade.distribution.upgrade-debian-package.WebHome]].
4 +* [[Upgrade XWiki Installed in Docker>>documentation.xs.admin.upgrade.distribution.upgrade-xwiki-docker.WebHome]].
5 +* [[Upgrade the XWiki .war Package>>documentation.xs.admin.upgrade.distribution.upgrade-war-package.WebHome]].
6 +* [[Upgrade the Demo Package>>documentation.xs.admin.upgrade.distribution.upgrade-zip-package.WebHome]].
7 7  
8 -After upgrading the distribution, you need to [[upgrade the flavor>>documentation.xs.admin.upgrade.flavor.WebHome]].
8 +Whichever method you use, XWiki applies the pending [[database schema updates and data migrations>>documentation.xs.admin.upgrade.distribution.database-upgrade.WebHome]] the next time it starts, and the [[flavor still has to be upgraded>>documentation.xs.admin.upgrade.flavor.WebHome]] from a browser afterwards.

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.VincentMassol
1 +XWiki.elenicojocariu
Content
... ... @@ -1,4 +1,4 @@
1 -Ensure the ##xwiki.cfg## file is configured correctly to allow the system to automatically upgrade the database schema. More specifically, find the section {{code language="none"}}# Data migrations and schema updates{{/code}}, and verify the following migration setting is enabled (uncommented):
1 +XWiki applies the pending database schema updates and data migrations when it starts, provided migrations are enabled in the ##xwiki.cfg## file. They are enabled in the configuration XWiki ships, but are commonly disabled in production for a faster startup, so check the setting before upgrading. In the {{code language="none"}}# Data migrations and schema updates{{/code}} section, verify that the following line is present and not commented out:
2 2  
3 3  (((
4 4  {{code language="none"}}
DocApp.Code.DocumentationClass[0]
FAQ
... ... @@ -1,3 +1,3 @@
1 1  == What if the migration of the database fails? ==
2 2  
3 -If the migration process fails, drop the ##DATABASECHANGELOG## and ##DATABASECHANGELOGLOCK## tables from your database and then restart the migration. This should allow the migration to proceed without further issues.
3 +If the migration process fails, drop the ##DATABASECHANGELOG## and ##DATABASECHANGELOGLOCK## tables from your database and then restart the migration. This should allow the migration to proceed without further issues.
Target
... ... @@ -1,1 +1,1 @@
1 -user
1 +administrator

Edition of Upgrade the Demo Package

Summary

Details

Page properties
Content
... ... @@ -1,22 +1,14 @@
1 -To [[upgrade>>documentation.xs.admin.upgrade.WebHome]] your XWiki instance to a newer version using the ##ZIP## package:
1 +To upgrade an XWiki instance installed from the [[standalone (demo) distribution>>documentation.xs.admin.installation.methods.install-standalone-demo-distribution.WebHome]], install the new version beside the old one and move your data across:
2 2  
3 -1. Backup the [[configuration files>>Documentation.AdminGuide.Backup||anchor="HConfigurationfiles"]], the [[permananet data>>Documentation.AdminGuide.Backup||anchor="HBackupPermanentData"]] (i.e. the /##data## directory), the HSQLDB database is already included in the /##data## directory, the [[log files>>Documentation.AdminGuide.Backup||anchor="HBackupLogfiles"]] (optional).
4 -1. Check the [[Release Notes>>xwiki:ReleaseNotes.WebHome]].(((
5 -* Review the release notes for the versions between your current version and the target version.
6 -* Pay special attention to sections titled {{code language="none"}}"Issues specific to XWiki <version>"{{/code}} and to any changes in [[hardware of software requirements (prerequisites)>>documentation.xs.admin.installation.prerequisites.WebHome]].
7 -)))
8 -1. [[Download the new version just as you had installed the standalone (demo) distribution>>documentation.xs.admin.installation.methods.install-standalone-demo-distribution.WebHome||anchor="HDownloadStandalone"]].
9 -1. Stop the XWiki instance to prevent file corruption and database inconsistencies.
10 -1. [[Install the new version>>documentation.xs.admin.installation.methods.install-standalone-demo-distribution.WebHome||anchor="HInstallStandalone"]] in a different directory than the old one. Keep both the old and the new installations.
11 -1. Merge the Configuration files:(((
12 -* If you have never modified the configuration files, you don’t need to copy the old configuration files to the new installation. Just keep the new configuration files and proceed with the other steps.
13 -* If you have customized the old configuration files:(((
14 -* Do NOT copy the old configuration files directly to the new installation. The new XWiki version may have introduced new configuration options, and overwriting the files completely could cause you to lose those options.
15 -* Ideally, [[manually merge>>||anchor="HHowtodothemergeofthefilesonUnixoperatingsystems3F"]] the old configuration files with the new ones: Compare the old and new configuration files, keep your custom settings, and add any new settings or changes from the new files.
16 -)))
17 -)))
18 -1. Copy the Permanent data directory (the ##data## directory) from the old XWiki to the new XWiki instance.
19 -1. {{include reference="documentation.xs.admin.upgrade.distribution.database-upgrade.WebHome"/}}
20 -1. Start the new instance to test and verify that the upgrade was successful and the new version is running correctly.
3 +1. Back up the [[configuration files>>Documentation.AdminGuide.Backup||anchor="HConfigurationfiles"]], the [[permanent data>>Documentation.AdminGuide.Backup||anchor="HBackupPermanentData"]] (the /##data## directory, which already contains the HSQLDB database) and, optionally, the [[log files>>Documentation.AdminGuide.Backup||anchor="HBackupLogfiles"]].
4 +1. Check the [[Release Notes>>xwiki:ReleaseNotes.WebHome]] of every version between the one you are running and the one you are upgrading to, in particular the sections named {{code language="none"}}"Issues specific to XWiki <version>"{{/code}} and any change to the [[prerequisites>>documentation.xs.admin.installation.prerequisites.WebHome]].
5 +1. [[Download the new version>>documentation.xs.admin.installation.methods.install-standalone-demo-distribution.WebHome||anchor="HDownloadStandalone"]] as you did when installing the distribution.
6 +1. Stop the XWiki instance, to prevent file corruption and database inconsistencies.
7 +1. [[Install the new version>>documentation.xs.admin.installation.methods.install-standalone-demo-distribution.WebHome||anchor="HInstallStandalone"]] in a different directory, keeping both installations.
8 +1. Keep the new configuration files when you never customized the old ones, and otherwise merge the old files into the new ones instead of copying them over, since the new version may have added options.
9 +1. Copy the ##data## directory from the old instance to the new one.
10 +1. Check that migrations are enabled, as described in [[Database Upgrade>>documentation.xs.admin.upgrade.distribution.database-upgrade.WebHome]].
11 +1. Start the new instance.
12 +1. [[Upgrade the flavor>>documentation.xs.admin.upgrade.flavor.WebHome]] from a browser, which the Distribution Wizard offers as soon as you log in.
21 21  
22 -After upgrading the Distribution, the next step is to [[upgarde the flavor>>documentation.xs.admin.upgrade.flavor.upgrade-distribution-wizard.WebHome]].
14 +The new instance then serves the content of the old one, which stays untouched in its own directory until you remove it.
DocApp.Code.DocumentationClass[0]
FAQ
... ... @@ -1,8 +1,7 @@
1 -== How to do the merge of the files on Unix operating systems ? ==
1 +== How to do the merge of the files on Unix operating systems? ==
2 2  
3 -If you're on a Unix system check some [[commands that may help you doing the merge>>documentation.xs.admin.upgrade.distribution.upgrade-zip-package.unix-merge-config-files.WebHome]] instead of doing it fully manually.
3 +If you are using a Unix system, some [[commands help you do the merge>>documentation.xs.admin.upgrade.distribution.upgrade-zip-package.unix-merge-config-files.WebHome]] instead of doing it fully manually.
4 4  
5 -
6 6  == What if the migration of the database fails? ==
7 7  
8 -If the migration process fails, drop the tables: {{code language="none"}} DATABASECHANGELOG {{/code}} and {{code language="none"}} DATABASECHANGELOGLOCK {{/code}} from your database and then restart the migration. This should allow the migration to proceed without further issues.
7 +If the migration process fails, drop the ##DATABASECHANGELOG## and ##DATABASECHANGELOGLOCK## tables from your database and then restart the migration. This should allow the migration to proceed without further issues.

Edition of Unix Merge Configuration Files

Summary

Details

Page properties
Content
... ... @@ -1,35 +1,25 @@
1 -When [[upgrading an XWiki distribution using the ZIP package>>documentation.xs.admin.upgrade.distribution.upgrade-zip-package.WebHome]] on a Unix system, the configuration files must be merged, not simply overwritten, in order to preserve custom settings while integrating new options introduced by the newer version. The following commands illustrate examples of how to move, compare, and merge the configuration files using standard Unix tools.
1 +When [[upgrading an XWiki distribution using the ZIP package>>documentation.xs.admin.upgrade.distribution.upgrade-zip-package.WebHome]] on a Unix system, the configuration files have to be merged rather than overwritten, so that your settings survive and the options the new version added are kept. The commands below do that with standard Unix tools, assuming ##xwiki.new## is the directory of the new installation and ##xwiki## the directory of the previous one.
2 2  
3 -== Assumption ==
3 +== Back Up the New Files ==
4 4  
5 -We assume ##xwiki.new## is a symbolic link pointing to the directory where the new XWiki version is installed, and ##xwiki## is the directory of the previous XWiki installation.
5 +Each configuration file of the new installation — ##web.xml##, ##xwiki.cfg##, ##xwiki.properties##, ##struts-config.xml## and ##logback.xml## — is first moved aside under an ##.ori## extension, so that the merge can write the result back under the original name:
6 6  
7 -== Move and Back Up Files ==
7 +{{code language="bash"}}
8 +mv xwiki.new/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori
9 +mv xwiki.new/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori
10 +mv xwiki.new/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori
11 +mv xwiki.new/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori
12 +mv xwiki.new/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori
13 +{{/code}}
8 8  
9 -Each configuration file (##web.xml##, ##xwiki.cfg##, ##xwiki.properties##, ##struts-config.xml##, ##logback.xml##) from the new XWiki installation (##xwiki.new##) is first moved to a backup copy with the ##.ori## extension.
15 +== Merge with sdiff ==
10 10  
11 -== Compare and Merge Files with sdiff ==
17 +##sdiff## then compares the file from the old installation with the backup of the new one and writes the merged result into the new installation:
12 12  
13 -The {{code language="none"}} sdiff {{/code}} command can then be used to compare:
14 -
15 -* the configuration file from the old installation (##xwiki/WEB-INF/##),
16 -* the corresponding backup file from the new installation (##xwiki.new/WEB-INF/*.ori##).
17 -
18 -The merged result is written back into the new installation directory.
19 -
20 -{{code language="none"}}
21 -mv xwiki.new/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori
19 +{{code language="bash"}}
22 22  sudo sdiff xwiki/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori -B -W -E -o xwiki.new/WEB-INF/web.xml
23 -
24 -mv xwiki.new/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori
25 25  sudo sdiff xwiki/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori -B -W -E -o xwiki.new/WEB-INF/xwiki.cfg
26 -
27 -mv xwiki.new/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori
28 28  sudo sdiff xwiki/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori -B -W -E -o xwiki.new/WEB-INF/xwiki.properties
29 -
30 -mv xwiki.new/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori
31 31  sudo sdiff xwiki/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori -B -W -E -o xwiki.new/WEB-INF/struts-config.xml
32 -
33 -mv xwiki.new/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori
34 34  sudo sdiff xwiki/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori -B -W -E -o xwiki.new/WEB-INF/classes/logback.xml
35 35  {{/code}}

Edition of Upgrade XWiki Installed in Docker

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.VincentMassol
1 +XWiki.elenicojocariu
Content
... ... @@ -1,24 +1,10 @@
1 -{{warning}}
2 -WIP
3 -{{/warning}}
1 +To upgrade an XWiki instance [[installed using Docker>>documentation.xs.admin.installation.methods.install-xwiki-docker.WebHome]], start a container of the new version against the data of the old one:
4 4  
5 -To upgrade an existing XWiki instance that was [[installed using Docker>>doc:documentation.xs.admin.installation.methods.install-xwiki-docker.WebHome]]:
3 +1. Check that the XWiki data directory is mounted on the host as a persistent volume, and that any [[customized configuration file>>documentation.xs.admin.installation.methods.install-xwiki-docker.configuration.configuration-files.WebHome]] is mapped there too.
4 +1. Check the [[Release Notes>>xwiki:ReleaseNotes.WebHome]] of every version between the one you are running and the one you are upgrading to, noting the manual migration steps, configuration changes and deprecated features they announce.
5 +1. Stop the XWiki container, leaving the database container running.
6 +1. Apply the changes the release notes require, to the configuration files on the host.
7 +1. Start a container of the new XWiki version, mounting the same volumes.
8 +1. [[Upgrade the flavor>>documentation.xs.admin.upgrade.flavor.WebHome]] from a browser, which the Distribution Wizard offers as soon as you log in.
6 6  
7 -1. Ensure your data and configurations are preserved:(((
8 -* The XWiki data directory is mounted to the host (persistent volume).
9 -* Any customized [[configuration files>>documentation.xs.admin.installation.methods.install-xwiki-docker.configuration.configuration-files.WebHome]] are also mapped to the host.
10 -)))
11 -1. Stop the currently running XWiki container. The database container should remain running.
12 -1. Review the [[release notes>>ReleaseNotes.WebHome]] for all intermediate versions between your current version and the target version.(((
13 -* Pay attention to:(((
14 -* Required manual migration steps,
15 -* Configuration changes,
16 -* Deprecated features.
17 -)))
18 -)))
19 -1. Apply any required changes before proceeding (e.g., update configuration files, if needed).
20 -1. Start a new container using the new XWiki version.
21 -
22 -
23 -
24 -
10 +The new container then serves the content of the old one, and the previous image can be removed once you have checked the wiki.
DocApp.Code.DocumentationClass[0]
FAQ
... ... @@ -1,0 +1,3 @@
1 +== Do I need to upgrade the database container as well? ==
2 +
3 +Not as part of an XWiki upgrade — the database keeps its own lifecycle. Check the [[prerequisites>>documentation.xs.admin.installation.prerequisites.WebHome]] of the new XWiki version, which is where a raised minimum database version would be announced.
Related
... ... @@ -1,1 +1,2 @@
1 -* [[Upgrade>>documentation.xs.admin.upgrade.WebHome]].
1 +* [[Install XWiki using Docker>>documentation.xs.admin.installation.methods.install-xwiki-docker.WebHome]].
2 +* [[XWiki Docker Troubleshooting>>documentation.xs.admin.installation.methods.install-xwiki-docker.troubleshooting.WebHome]].

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Upgrade the Standard Flavor of the Wiki using the Distribution Wizard
1 +Upgrade the Standard Flavor of the Wiki Using the Distribution Wizard
Content
... ... @@ -1,32 +1,21 @@
1 -{{warning}}
2 - WIP
3 -{{/warning}}
1 +To upgrade the pre-installed standard flavor of the wiki with the [[Distribution Wizard>>Documentation.UserGuide.Features.DistributionWizard]], once the [[distribution has been upgraded>>documentation.xs.admin.upgrade.distribution.WebHome]]:
4 4  
5 -To upgrade the (pre-installed) standard flavor of the wiki using the [[Distribution Wizard>>Documentation.UserGuide.Features.DistributionWizard]] (DW), after [[upgrading the distribution>>documentation.xs.admin.upgrade.distribution.upgrade-zip-package.WebHome]]:
6 -
7 7  1. Start the XWiki instance.
8 8  1. Log in with a user that has [[programming rights>>Documentation.AdminGuide.Access Rights.Permission types.WebHome||anchor="HProgrammingRights"]].
9 -1. Choose what to do next from the Welcome step that appears in the Distribution Wizard:(((
10 -{{image reference="distribution-wizard-steps.png" size="large" alt="The Distribution Wizard modal presenting the steps and the options to continue/later/never"/}}
5 +1. Choose how to proceed in the Welcome step of the Distribution Wizard:(((
6 +{{image reference="distribution-wizard-steps.png" size="large" alt="The Distribution Wizard Welcome step, presenting the steps and the Continue, Later and Never options"/}}
11 11  
12 -* "Continue": Selecting this option will move you to the next step of the Distribution Wizard.
13 -* "Later": DW will prompt you again after XWiki is restarted. The "Later" button has a sub-option, "Replay recorded actions", which triggers the same behavior as the Distribution Wizard. However, instead of redirecting you to the initially requested Page, it will direct you to the [[Extension History>>extensions:Extension.Extension Manager Application||anchor="HExtensionHistory"]], where you can upload and replay a history file (e.g., replay an install or upgrade from a different wiki). If the database is empty, you will need to log in as the superadmin.
14 -* "Never": Discards the Distribution Wizard, and you will need to manually [[import the XAR>>documentation.xs.admin.imports.import-xwiki-pages.WebHome]].
8 +* "Continue" moves to the next step.
9 +* "Later" prompts you again after XWiki is restarted. Its "Replay recorded actions" sub-option instead sends you to the [[Extension History>>extensions:Extension.Extension Manager Application||anchor="HExtensionHistory"]], where a history file exported from another wiki can be replayed.
10 +* "Never" discards the Distribution Wizard, leaving you to [[import the XAR>>documentation.xs.admin.imports.import-xwiki-pages.WebHome]] yourself.
15 15  )))
16 -1. Upgrade the extensions installed on your wikis. The first steps of the Distribution Wizard are skipped when upgrading the Standard Flavor.(((
17 -* If you are on a subwiki, you can only check for updates for extensions installed on that specific subwiki.
18 -* On the main wiki, global administrators can choose one of the following options:(((
19 -* "Check for updates": Compute the upgrade plan for the main wiki and the global namespace only.
20 -* "Check for updates on farm": Compute the upgrade plan for the entire farm (all wikis + global namespace):(((
12 +1. Upgrade the extensions installed on the wiki. On a subwiki you can only check the extensions installed on that subwiki; on the main wiki, "Check for updates" computes the plan for the main wiki and the global namespace, and "Check for updates on farm" for every wiki of the farm:(((
21 21  {{gallery}}
22 -[[image:check-extension-updates.png||alt="The Distribution wizard step 4 of checking for upgrades"]]
23 -[[image:check-updates-farm.png||alt="The Distribution wizard step 4 of checking for upgrades on farm"]]
24 -[[image:check-updates-finish.png||alt="The Distrivution Wizard showing that all extensions have been successfully updated"]]
14 +[[image:check-extension-updates.png||alt="The Distribution Wizard step for checking extension upgrades"]]
15 +[[image:check-updates-farm.png||alt="The Distribution Wizard checking extension upgrades on the whole farm"]]
16 +[[image:check-updates-finish.png||alt="The Distribution Wizard reporting that all extensions have been successfully updated"]]
25 25  {{/gallery}}
26 26  )))
19 +1. Click "Continue" to leave the report the Distribution Wizard produced. It lists the Pages that were updated, as follows:(((
20 +{{image reference="pages-distribution-wizard.png" size="large" alt="The Distribution Wizard report listing the Pages updated by the flavor upgrade"/}}
27 27  )))
28 -)))
29 -1. Check the report after the installation has finished and click on "Continue". The report displays the updated Pages.(((
30 -{{image reference="pages-distribution-wizard.png" size="large" alt="The Distribution Wizard showing step 5 the report of the installation"/}}
31 -)))
32 -1. Do the [[upgrade of the flavor for all the wikis>>||anchor="HAreallthewikisupgradedautomatically3F"]].
DocApp.Code.DocumentationClass[0]
FAQ
... ... @@ -1,7 +1,7 @@
1 1  == Why do I need programming rights to run the Distribution Wizard when upgrading? ==
2 2  
3 -[[Extension Pages may need to be modified during the upgrade process>>documentation.xs.admin.upgrade.flavor.upgrade-distribution-wizard.programming-rights-impact-distribution-wizard.WebHome]]. If the upgrade is performed with a user that does not have Programming Rights, these pages might not be updated correctly.
3 +[[Extension Pages may need to be modified during the upgrade process>>documentation.xs.admin.upgrade.flavor.upgrade-distribution-wizard.programming-rights-impact-distribution-wizard.WebHome]]. If the upgrade is performed with a user that does not have Programming Rights, these pages might not be updated correctly.
4 4  
5 5  == Are all the wikis upgraded automatically? ==
6 6  
7 -You need to upgrade every wiki: If you have multiple wikis (subwikis), you need to [[navigate to the wiki index>>extensions:Extension.Wiki Application||anchor="HMenusandWikiIndex"]] and run the Distribution Wizard on every wiki.
7 +No. On a farm you have to run the Distribution Wizard on every wiki, reaching each of them from the [[wiki index>>extensions:Extension.Wiki Application||anchor="HMenusandWikiIndex"]].

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Upgrade the Flavor using the Export/Import Method
1 +Upgrade the Flavor Using the Export/Import Method
Content
... ... @@ -1,10 +1,10 @@
1 -To upgrade your wiki instance by migrating the content using the export/reimport XAR:
1 +To upgrade a wiki by migrating its content into a new instance instead of upgrading the flavor in place:
2 2  
3 -1. Check the [[limitations and risks>>documentation.xs.admin.upgrade.flavor.upgrade-export-import.limitations.WebHome]] of upgrading using this method.
4 -1. Identify all the content you have created on the old instance.
5 -1. Verify manually that you know exactly what content must be migrated.
6 -1. [[Export the existing content as a XAR file>>documentation.xs.admin.exports.export-content-xar-format.WebHome]] from the old instance.
7 -1. [[Install>>documentation.xs.admin.installation.methods.WebHome]] a new instance using the preferred method where the content will be migrated.
3 +1. Check the [[limitations and risks>>documentation.xs.admin.upgrade.flavor.upgrade-export-import.limitations.WebHome]] of this method.
4 +1. Identify all the content created on the old instance, and confirm that you know exactly what has to be migrated.
5 +1. [[Export that content as a XAR file>>documentation.xs.admin.exports.export-content-xar-format.WebHome]] from the old instance.
6 +1. [[Install>>documentation.xs.admin.installation.methods.WebHome]] a new instance of the version you are moving to.
8 8  1. [[Import the XAR file>>documentation.xs.admin.imports.import-xwiki-pages.WebHome]] into the new instance.
9 -1. Check the new instance to confirm that all content was transferred correctly.
10 -1. Validate that no important data is missing or broken after the import.
8 +1. Check the new instance, page by page, against the list of content you identified.
9 +
10 +The new instance then holds your content on the new version, without any of the data migrations a regular upgrade would have applied.
DocApp.Code.DocumentationClass[0]
FAQ
... ... @@ -1,7 +1,7 @@
1 1  == Is this a safe method to upgrade the flavor of the wiki? ==
2 2  
3 -No, the recommended way is to [[upgrade the flavor using the distribution wizard>>documentation.xs.admin.upgrade.flavor.upgrade-distribution-wizard.WebHome]]. There are [[limitatations and risks>>documentation.xs.admin.upgrade.flavor.upgrade-export-import.limitations.WebHome]] when using this method to upgrade.
3 +No, the recommended way is to [[upgrade the flavor using the Distribution Wizard>>documentation.xs.admin.upgrade.flavor.upgrade-distribution-wizard.WebHome]]. There are [[limitations and risks>>documentation.xs.admin.upgrade.flavor.upgrade-export-import.limitations.WebHome]] when using this method to upgrade.
4 4  
5 5  == Should default XWiki Pages be included in the export/import? ==
6 6  
7 -No, they should not be included. Make sure to only import your own content Pages and not the default XWiki pages since you’d overwrite the ones provided in new XWiki install.
7 +No. Import only the Pages you created: the default Pages would overwrite the ones the new XWiki installation provides.
Type
... ... @@ -1,1 +1,1 @@
1 -tutorial
1 +howto

Edition of Move XWiki to a New Server and Upgrade it

Summary

Details

Page properties
Content
... ... @@ -1,7 +1,9 @@
1 -To move an existing XWiki instance to a different server and upgrade it at the same time:
1 +To move an existing XWiki instance to a different server and upgrade it, do the two operations one after the other rather than together:
2 2  
3 -1. Install the same XWiki version on the new server as the one running on the old server.
4 -1. Move the existing data (database and [[permananet data>>Documentation.AdminGuide.Backup||anchor="HBackupPermanentData"]] (i.e. the /##data## directory)) to the new server.
3 +1. Install on the new server the same XWiki version as the one running on the old server.
4 +1. Move the database and the [[permanent data>>Documentation.AdminGuide.Backup||anchor="HBackupPermanentData"]] (the /##data## directory) to the new server.
5 5  1. Start the instance on the new server.
6 -1. Verify that all content and features work correctly.
7 -1. Upgrade XWiki by following the standard [[upgrade procedure>>documentation.xs.admin.upgrade.WebHome]].
6 +1. Check that the content and the features work as they did on the old server.
7 +1. [[Upgrade the instance>>documentation.xs.admin.upgrade.WebHome]] on the new server.
8 +
9 +The wiki then runs the new version on the new server, and any problem you met along the way belongs to one of the two operations rather than to both at once.
DocApp.Code.DocumentationClass[0]
FAQ
... ... @@ -1,3 +1,3 @@
1 -== Why should the server migration be separated from the XWiki upgarde process? ==
1 +== Why should the server migration be separated from the XWiki upgrade process? ==
2 2  
3 -Separating the server migration from the upgrade process makes it easier to identify and fix problems and avoid mixing infrastructure issues with data migration issues.
3 +Separating the server migration from the upgrade makes it easier to identify and fix problems, instead of mixing infrastructure issues with data migration issues.

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Upgrades Troubleshootings
1 +Upgrade Troubleshooting
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.superadmin
1 +XWiki.elenicojocariu
Content
... ... @@ -1,13 +1,6 @@
1 -{{warning}}
2 -WIP
3 -{{/warning}}
1 +An upgrade that leaves XWiki unable to start usually fails on the environment around it rather than on the wiki content, and the failure is often reported by the [[servlet container>>documentation.xs.admin.installation.methods.install-xwiki-war.configure-servlet-container.WebHome]] rather than by XWiki. Read both logs first, to find which component stopped.
4 4  
5 -When upgrading XWiki, you may encounter issues that prevent the application from starting correctly or that affect the upgraded environment.
3 +The two failures documented here are:
6 6  
7 -Common problems after an upgrade include:
8 -
9 -* [[XWiki startup hanging during Solr initialization]] because existing Solr cores are not configured for delayed loading.
10 -* [[XWiki failing to start because the servlet container is still running with an unsupported or previous Java]] version after a required Java upgrade.
11 -* Configuration issues caused by changes in dependencies, servlet containers, or runtime environments.
12 -
13 -Before troubleshooting an upgrade issue, check the XWiki and servlet container logs to identify the component causing the failure.
5 +* [[XWiki Startup Stuck during Solr Initialization>>documentation.xs.admin.upgrade.troubleshooting.xwiki-startup-stuck-solr-initialization.WebHome]], when existing Solr cores are not configured for delayed loading.
6 +* [[XWiki Startup Failure after a Required Java Upgrade>>documentation.xs.admin.upgrade.troubleshooting.xwiki-startup-failure-java-upgrade.WebHome]], when the servlet container still runs the Java version the new XWiki version no longer supports.

Edition of Upgrading

Summary

Details

Page properties
Content
... ... @@ -1,108 +1,40 @@
1 -{{box cssClass="floatinginfobox" title="**Contents**"}}
2 -{{toc/}}
3 -{{/box}}
1 +{{info}}
2 +This documentation has moved to [[Upgrade>>documentation.xs.admin.upgrade.WebHome]].
3 +{{/info}}
4 4  
5 5  = Upgrading =
6 6  
7 7  See [[Upgrade>>documentation.xs.admin.upgrade.WebHome]].
8 8  
9 -----
10 -
11 11  == (% class="label label-primary" %)Part 1(%%) Upgrading the distribution ==
12 12  
13 -{{velocity}}
14 -#if ("$!request.get('method')" != '')
15 -=== (% class="label label-default" %)Method $request.get('method')(%%) Upgrading from the $request.get('method') package ===
11 +{{id name="HUpgradingfromtheDebianpackage"/}}{{id name="HMethod1.AUpgradingfromtheDebianpackage.DEB"/}}{{id name="HMethod1.BUpgradingfromDocker.Docker"/}}{{id name="HMethod1.CUpgradingtheWAR.WAR"/}}{{id name="HMethod1.DUpgradingthedemopackage.ZIP"/}}
16 16  
17 -{{display reference="Documentation.AdminGuide.Upgrade.Upgrade${request.get('method')}.WebHome"/}}
18 -#else
19 -=== (% class="label label-default" %)Method 1.A(%%) Upgrading from the Debian package (% class="badge fill-gray pull-right" id="HUpgradingfromtheDebianpackage" %).DEB(%%) ===
13 +See [[Distribution Upgrades>>documentation.xs.admin.upgrade.distribution.WebHome]], which covers each method:
20 20  
21 -{{display reference="Documentation.AdminGuide.Installation.InstallationViaAPT.WebHome" section="HUpgrading"/}}
15 +* [[Upgrade XWiki Installed from the Debian Packages>>documentation.xs.admin.upgrade.distribution.upgrade-debian-package.WebHome]].
16 +* [[Upgrade XWiki Installed in Docker>>documentation.xs.admin.upgrade.distribution.upgrade-xwiki-docker.WebHome]].
17 +* [[Upgrade the XWiki .war Package>>documentation.xs.admin.upgrade.distribution.upgrade-war-package.WebHome]].
18 +* [[Upgrade the Demo Package>>documentation.xs.admin.upgrade.distribution.upgrade-zip-package.WebHome]].
22 22  
23 -=== (% class="label label-default" %)Method 1.B(%%) Upgrading from Docker (% class="badge fill-gray pull-right" %).Docker(%%) ===
24 -
25 -{{display reference="Documentation.AdminGuide.Upgrade.UpgradeDocker.WebHome"/}}
26 -
27 -=== (% class="label label-default" %)Method 1.C(%%) Upgrading the WAR (% class="badge fill-gray pull-right" %).WAR(%%) ===
28 -
29 -{{display reference="Documentation.AdminGuide.Upgrade.UpgradeWAR.WebHome"/}}
30 -
31 -=== (% class="label label-default" %)Method 1.D(%%) Upgrading the demo package (% class="badge fill-gray pull-right" %).ZIP(%%) ===
32 -
33 -{{display reference="Documentation.AdminGuide.Upgrade.UpgradeDemo.WebHome"/}}
34 -#end
35 -{{/velocity}}
36 -
37 -----
38 -
39 39  == (% class="label label-primary" id="HUpgradingwikidocuments" %)Part 2(%%) Upgrading the flavor ==
40 40  
41 -=== Using Distribution Wizard ===
22 +{{id name="HPart2Upgradingtheflavor"/}}{{id name="HUsingDistributionWizard"/}}
42 42  
43 -(% class="label label-success" %)Recommended
24 +See [[Flavor Upgrades>>documentation.xs.admin.upgrade.flavor.WebHome]], [[Upgrade the Standard Flavor of the Wiki Using the Distribution Wizard>>documentation.xs.admin.upgrade.flavor.upgrade-distribution-wizard.WebHome]] and [[Programming Rights Impact on Distribution Wizard>>documentation.xs.admin.upgrade.flavor.upgrade-distribution-wizard.programming-rights-impact-distribution-wizard.WebHome]].
44 44  
45 -See [[Upgrade the Standard Flavor of the Wiki using the Distribution Wizard>>documentation.xs.admin.upgrade.flavor.upgrade-distribution-wizard.WebHome]].
46 -
47 -See [[Programming Rights Impact on Distribution Wizard>>documentation.xs.admin.upgrade.flavor.upgrade-distribution-wizard.programming-rights-impact-distribution-wizard.WebHome]].
48 -
49 -----
50 -
51 51  == (% class="label label-default" %)Alternative(%%) Start fresh, plus Export and Reimport your data ==
52 52  
53 -See [[Upgrade the Flavor using the Export/Import Method>>documentation.xs.admin.upgrade.flavor.upgrade-export-import.WebHome]].
28 +{{id name="HAlternativeStartfresh2CplusExportandReimportyourdata"/}}
54 54  
55 -{{warning}}
56 -See [[Limitations>>documentation.xs.admin.upgrade.flavor.upgrade-export-import.limitations.WebHome]].
30 +See [[Upgrade the Flavor Using the Export/Import Method>>documentation.xs.admin.upgrade.flavor.upgrade-export-import.WebHome]], its [[Limitations>>documentation.xs.admin.upgrade.flavor.upgrade-export-import.limitations.WebHome]] and [[Move XWiki to a New Server and Upgrade it>>documentation.xs.admin.upgrade.move-xwiki-new-server-upgrade.WebHome]].
57 57  
58 -See [[Move XWiki to a new server and upgrade it>>documentation.xs.admin.upgrade.move-xwiki-new-server-upgrade.WebHome]].
59 -{{/warning}}
60 -
61 -----
62 -
63 63  = Downgrading =
64 64  
34 +{{id name="HDowngrading"/}}
35 +
65 65  See [[Downgrade your Wiki>>documentation.xs.admin.downgrade-your-wiki.WebHome]].
66 66  
67 67  = Troubleshooting =
68 68  
69 -== XWiki won't start without any error in the log and stay stuck on Solr initialization ==
70 -
71 -See [[XWiki Startup Stuck during Solr Initialization>>documentation.xs.admin.upgrade.troubleshooting.xwiki-startup-stuck-solr-initialization.WebHome]].
72 -
73 -== XWiki startup failed due to previous errors ==
74 -
75 -If XWiki fails to start after an upgrade that requires an upgrade of the java version (i.e. when upgrading to 16.x, which requires a switch to Java17), and the servlet container only shows a failue when starting the webapp, like:
76 -
77 -{{code langugae="none"}}
78 - Context [/xwiki] startup failed due to previous errors
79 -{{/code}}
80 -
81 -then it might be the servlet container still uses the previous java version.
82 -For Tomcat the path to the java version in use is displayed soon after start in a line like:
83 -
84 -{{code langugage="none"}}
85 - [info] JVM Version: 11.0.21+9-post-Ubuntu-0ubuntu122.04
86 -{{/code}}
87 -
88 -Here the first number (the "11" of the "11.0.21+9-...") indicated that tomcat is still running Java11 instead of e.g. Java17
89 -
90 -This problem can be caused by various sources, like a hard wired ##JAVA_HOME## in some configuration file (like. ##/etc/default/tomcat9##).
91 -
92 -For Debian based distributions it seems one symbolic link in ##/usr/lib/jvm## is not changed an needs to be updated manually. If you get an output like:
93 -
94 -{{code language="none"}}
95 -# ls -l /usr/lib/jvm/
96 -lrwxrwxrwx 1 root root 25 Dec 30 2018 default-java -> java-1.11.0-openjdk-amd64
97 -lrwxrwxrwx 1 root root 21 Jan 17 2020 java-1.11.0-openjdk-amd64 -> java-11-openjdk-amd64
98 -drwxr-xr-x 7 root root 4096 Jan 24 15:49 java-11-openjdk-amd64
99 -lrwxrwxrwx 1 root root 21 Jan 31 00:08 java-1.17.0-openjdk-amd64 -> java-17-openjdk-amd64
100 -drwxr-xr-x 7 root root 4096 Feb 3 22:59 java-17-openjdk-amd64
101 -{{/code}}
102 -
103 -then you neeed to update the ##default-java## link explicitely e.g. by:
104 -
105 -{{code language="none"}}
106 -# cd /usr/lib/jvm
107 -# rm default-java; ln -s java-17-openjdk-amd64 default-java
108 -{{/code}}
40 +See [[Upgrade Troubleshooting>>documentation.xs.admin.upgrade.troubleshooting.WebHome]], [[XWiki Startup Stuck during Solr Initialization>>documentation.xs.admin.upgrade.troubleshooting.xwiki-startup-stuck-solr-initialization.WebHome]] and [[XWiki Startup Failure after a Required Java Upgrade>>documentation.xs.admin.upgrade.troubleshooting.xwiki-startup-failure-java-upgrade.WebHome]].

Edition of Upgrading from the Debian package

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.ThomasMortagne
1 +XWiki.elenicojocariu
Content
... ... @@ -1,25 +1,3 @@
1 -* Update packages index:(((
2 -{{code language="bash"}}
3 -sudo apt update
4 -{{/code}}
5 -)))
6 -* Package upgrade:(((
7 -{{code language="bash"}}
8 -sudo apt upgrade
9 -{{/code}}
10 -
11 -This will upgrade all packages, not just XWiki. If you want to avoid all the other packages and only update XWiki, you can use {{code}}sudo apt install xwiki-tomcat9-mariadb{{/code}} (change ##xwiki-tomcat9-mariadb## for the top level package you installed if you installed something else).
12 -
13 -==== Troubleshooting
14 -
15 -===== apt upgrade won't upgrade xwiki packages
16 -
17 -Sometimes (especially in case of new cycle), apt upgrade might report that it refuse to upgrade some xwiki packages.
18 -
19 -This is generally the sign that either:
20 - * a new dependency cannot be found: it generally means that XWiki starts requiring a more recent version of Java and the Debian repository you have don't have any implementation of this Java versions. See [[No package can be found for Java>>Documentation.AdminGuide.Installation.InstallationViaAPT||anchor="HNopackagecanbefoundforJava"]] for more details on how to resolve this situation.
21 - * some xwiki package name changed: this generally happen when XWiki stops supporting some version of Tomcat and you need to install a different xwiki-tomcat* package (for example XWiki 17 does not support tomcat9 and requires the tomcat10 package)
22 -)))
23 -* Pages upgrade:(((
24 -However after upgrading you still need to install the new UI; see next step [[Upgrading the flavor>>.||anchor="HPart2Upgradingtheflavor"]] below.
25 -)))
1 +{{info}}
2 +This documentation has moved to [[Upgrade XWiki Installed from the Debian Packages>>documentation.xs.admin.upgrade.distribution.upgrade-debian-package.WebHome]].
3 +{{/info}}

Edition of Upgrading the WAR

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.VincentMassol
1 +XWiki.elenicojocariu
Content
... ... @@ -1,20 +1,3 @@
1 -* The general strategy is to [[download the new WAR distribution>>xwiki:Main.Download]] and to replace your current installed WAR with it. However make sure you don't copy on top since this could leave some old files around which would make XWiki fail (like if old JARs are lying around in ##WEB-INF/lib##). In addition you would override some XWiki configuration files located in ##WEB-INF## (##xwiki.properties## and ##xwiki.cfg## to name just two).
2 -* Thus, before replacing your current WAR, make sure you [[back it up, including configuration and data files>>xwiki:Documentation.AdminGuide.Backup]].
3 -* Also you need to ensure that you use the same XWiki Permanent directory (configured in ##WEB-INF/xwiki.properties## using the ##environment.permanentDirectory## property).
4 -* Some additional operations may be required for upgrading and you must check the [[release notes>>xwiki:ReleaseNotes.WebHome]] for all the versions from the version you're upgrading from up to the new version you're installing. It's also possible that new features are available and that some configuration files need to be modified. If this is the case then it'll be specified in the release notes.
5 -* {{include reference="xwiki:Documentation.AdminGuide.UpgradeDatabase"/}}
6 -* (((
7 -**Invalid Extensions**
8 -
9 -Also note that when you upgrade, some extensions that were previously valid may become invalid (for example they may have been renamed, removed or have versions that do not match the version of the WAR you've installed as is the case with the example below). In this case you'll see in the console messages such as:
10 -
11 -{{code language="noformat"}}
12 -2013-12-02 11:43:01,688 [localhost-startStop-1] WARN ltInstalledExtensionRepository - Invalid extension [org.xwiki.enterprise:xwiki-enterprise-ui-common-5.2.1] on namespace [wiki:xwiki]
13 -2013-12-02 11:43:01,688 [localhost-startStop-1] WARN ltInstalledExtensionRepository - Invalid extension [org.xwiki.platform:xwiki-platform-workspace-ui-5.2.1] on namespace [wiki:xwiki]
14 -2013-12-02 11:43:01,688 [localhost-startStop-1] WARN ltInstalledExtensionRepository - Invalid extension [org.xwiki.enterprise:xwiki-enterprise-ui-mainwiki-5.2.1] on namespace [wiki:xwiki]
15 -2013-12-02 11:43:01,689 [localhost-startStop-1] WARN ltInstalledExtensionRepository - Invalid extension [org.xwiki.enterprise:xwiki-enterprise-ui-wiki-all-5.2.1] on namespace [wiki:workspacetemplate]
16 -{{/code}}
17 -
18 -These are just warnings and don't affect that stability of your instance. Actually the Distribution Wizard you get (see the next section on "Upgrading wiki documents") will ask you to upgrade those invalid extensions and will remove the old versions that became invalid.
19 -)))
20 -
1 +{{info}}
2 +This documentation has moved to [[Upgrade the XWiki .war Package>>documentation.xs.admin.upgrade.distribution.upgrade-war-package.WebHome]] and [[Invalid Extensions after an Upgrade>>documentation.xs.admin.upgrade.distribution.upgrade-war-package.invalid-extensions.WebHome]].
3 +{{/info}}

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.VincentMassol
1 +XWiki.elenicojocariu
Content
... ... @@ -1,1 +1,3 @@
1 -* If you've installed XWiki by using the official XWiki Docker image, [[follow the instructions there>>https://github.com/xwiki-contrib/docker-xwiki/blob/master/README.md#upgrading-xwiki]] for upgrading it.
1 +{{info}}
2 +This documentation has moved to [[Upgrade XWiki Installed in Docker>>documentation.xs.admin.upgrade.distribution.upgrade-xwiki-docker.WebHome]].
3 +{{/info}}

Edition of XWiki Startup Stuck during Solr Initialization

Summary

Details

Page properties
Content
... ... @@ -1,7 +5,3 @@
1 -{{warning}}
2 -WIP
3 -{{/warning}}
4 -
5 5  When starting XWiki, the application may appear to hang during startup while initializing [[Solr>>extensions:Extension.Solr Search Application]]. No clear error may be displayed in the logs, but the [[servlet container>>documentation.xs.admin.installation.methods.install-xwiki-war.configure-servlet-container.WebHome]] remains stuck during the Solr initialization phase.
6 6  
7 7  This can happen when Solr tries to initialize multiple cores at the same time, especially for cores created by older XWiki versions.

Summary

Details

Page properties
Content
... ... @@ -185,57 +185,10 @@
185 185  
186 186  == Upgrading ==
187 187  
188 -=== Update the packages index ===
188 +{{id name="HUpgrading"/}}
189 189  
190 -{{code language="bash"}}
191 -sudo apt update
192 -{{/code}}
190 +See [[Upgrade XWiki Installed from the Debian Packages>>documentation.xs.admin.upgrade.distribution.upgrade-debian-package.WebHome]].
193 193  
194 -=== [Optional] Uninstall conflicting version of tomcat packages ===
195 -
196 -In the case of the ##tomcat## based packages, if you are moving from one version of Tomcat to another (which is generally needed when XWiki increase its [[minimum supported version>>dev:Community.SupportStrategy.ServletContainerSupportStrategy.WebHome]]), you may need to first uninstall the previous version. This is because two different versions of Tomcat cannot run at the same time by default.
197 -
198 -Of course, you can skip this step if you are not using the Tomcat based package, not changing the version of Tomcat, or if you configured Tomcat specifically to allow having several versions running at the same time.
199 -
200 -* Stop the running instance of tomcat ({{warning}}change the version to match the previous version of Tomcat you are upgrading from{{/warning}}):
201 -
202 -{{code language="bash"}}
203 - sudo systemctl stop tomcat9
204 -{{/code}}
205 -
206 -* Uninstall Tomcat (which will also uninstall the xwiki packages which rely on this version of Tomcat):
207 -
208 -{{code language="bash"}}
209 - sudo apt remove tomcat9
210 -{{/code}}
211 -
212 -* Then you will need to install the new package ({{warning}}modify the package name to match the version of Tomcat you are upgrading to, and the database you were already using{{/warning}}):
213 -
214 -{{code language="bash"}}
215 - sudo apt install xwiki-tomcat10-mariadb
216 -{{/code}}
217 -
218 -=== Upgrade the packages ===
219 -
220 -{{code language="bash"}}
221 -sudo apt upgrade
222 -{{/code}}
223 -
224 -This will upgrade all packages, not just XWiki. If you want to avoid all the other packages and only update XWiki, you can use {{code}}sudo apt install xwiki-tomcat10-mariadb{{/code}} (change ##xwiki-tomcat10-mariadb## for the top level package you installed if you installed something else).
225 -
226 -{{warning}}
227 -Sometimes (especially in case of new cycle), apt upgrade might report that it refuse to upgrade some xwiki packages.
228 -
229 -This is generally the sign that either:
230 -
231 -* A new dependency cannot be found: it generally means that [[XWiki starts requiring a more recent version of Java>>dev:Community.SupportStrategy.JavaSupportStrategy||anchor="HByXWikiVersions"]] and the Debian repository you have don't have any implementation of this Java versions. See [[No package can be found for Java>>Documentation.AdminGuide.Installation.InstallationViaAPT||anchor="HNopackagecanbefoundforJava"]] for more details on how to resolve this situation.
232 -* Some xwiki package name changed: this generally happen when XWiki stops supporting some version of Tomcat and you need to install a different ##xwiki-tomcat*## package (for example XWiki 17 does not support tomcat9 anymore and requires the ##tomcat10## package so xwiki packages for this version have been renamed to ##xwiki-tomcat10-mariadb## for example, if you used ##mariadb##).
233 -{{/warning}}
234 -
235 -=== Upgrade the pages ===
236 -
237 -Like in the case of the install, you still have to go through the Distribution Wizard. See more details on [[Upgrading the flavor>>Documentation.AdminGuide.Upgrade||anchor="HPart2Upgradingtheflavor"]].
238 -
239 239  == Uninstallation ==
240 240  
241 241  If you want to remove XWiki from your system, you only have to uninstall the packages you've installed at the beginning of this documentation. For example:

Edition of Wikis vs Nested Pages

Summary

Details

Page properties
Content
... ... @@ -16,6 +16,6 @@
16 16  |Renaming of Wiki or Page|(x)|(/)|[[Page Rename>>xwiki:Documentation.UserGuide.Features.DocumentLifecycle.WebHome||anchor="HMove2FRename"]] updates backlinks automatically, but it's not the case across Wiki.
17 17  |Invite Users|(/)|(x)|You cannot invite users only for a Page, but you can [[invite users on a Wiki>>extensions:Extension.Wiki Application||anchor="HInvitesomeoneonasubwiki"]].
18 18  |Implement a "playground"|(/)|(x)|Nested Pages share [[XClasses>>xwiki:documentation.xs.dev.data-model.x-classes.WebHome]] 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.
19 -|Easiness of upgrades|(x)|(/)|Harder to [[upgrade XWiki>>xwiki:Documentation.AdminGuide.Upgrade.WebHome]]: 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).
19 +|Easiness of upgrades|(x)|(/)|Harder to [[upgrade XWiki>>documentation.xs.admin.upgrade.WebHome]]: 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).
20 20  |Easiness of creation|(x)|(/)|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>>extensions:Extension.Wiki Application||anchor="HRights"]], while creating a Page requires [[Edit rights>>xwiki:Documentation.AdminGuide.Access Rights.WebHome||anchor="HSettingRightsforaPageandItsChildren"]].
21 21  |Scalability|(x)|(/)|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)>>https://jira.xwiki.org/browse/XWIKI-16647]].

Edition of Installation

Summary

Details

DocApp.Code.DocumentationClass[0]
Related
... ... @@ -1,5 +1,5 @@
1 1  * [[Admin Guide>>Documentation.AdminGuide.WebHome]].
2 2  * [[Security>>Documentation.AdminGuide.Security]].
3 -* [[Upgrade Procedure>>Documentation.AdminGuide.Upgrade]].
3 +* [[Upgrade>>documentation.xs.admin.upgrade.WebHome]].
4 4  * [[Other Unofficial Installation Methods>>documentation.xs.admin.installation.methods.unofficial-methods.WebHome]].
5 5  * [[Release Notes>>xwiki:ReleaseNotes.WebHome]].
Aug 13, 2026, 3:13:56 PM

Approved by Eleni Cojocariu

Approvers

Approvers have not been explicitly defined for this Change Request. Approvers will be based entirely on approval rights.

About

About

Support

Platform

User Guide

Admin Guide

Developer Guide

Projects

XWiki

Extensions

Other

Contribute

Status

Practices

Under the Hood

Get Involved

Get Connected