Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-37710

Confluence remigrates Wiki Markup content on restart if a plugin is updated

XMLWordPrintable

      Issue Summary

      The recent fix in Confluence 5.7.4 ( CONF-35004 ) means that on each restart following a plugin update/upgrade/install, Confluence attempts to re-migrate all our "unmigrated" pages (1,800 pages and their attachments) because we have some unknown macros in those pages. These pages seem to get re-migrated again if we update any plugin, enable/re-enable plugins followed by a restart.

      This is polluting the change history of the pages because it adds another version on each page. It also appears that the attachments on those pages are getting re-indexed.

      I understand the fix may have been intentional but it's having some bad side-effects.

      Also related:

      Steps to Reproduce

      1. Set up a 8.5.20 instance.
      2. Install a third party plugin such as the Content Formatting for Confluence plugin version 7.2.4.
      3. Identify an affected page with a section of Wiki Markup.
      4. Upgrade the third party plugin (for example, Mosaic (new owner) version 8.10.0).
      5. Upgrade Confluence 8.5.20 to 9.2.1
      6. Restart the instance.

      Expected Results

      No unexpected messages displayed in the UI or application logs and no new, unnecessary versions created.

      Actual Results

      See notes below.

      Notes on re-opening the bug

      When this issue occurs, one or two symptoms will be present:

      1. First, Confluence will display a Migration of unmigrated content due to installation of a new plugin message for an affected page within the All updates landing page.  
      2. Second, the following message may appear in the application logs once directly during the first startup of Confluence after an upgrade of the instance. Here's an example: 
        2025-03-27 10:59:07,358 INFO [macro-migration:thread-1] [render.xhtml.migration.ErrorReportingV2Renderer] render Unable to render content on page BIN:My Test\nWrapping content in unmigrated wiki markup macro due to system error: index -1, length 0

      Workaround

      A workaround has been added to the description of related ticket CONF-32837, which provides a method via SQL to disable the remigration job on restarts. As with all database manipulation tasks, please be sure to test this on a non-Production environment first.

      In the release of 5.10.8, a system variable is added to turn off the remigration behavior during startup. To use this feature:

      1. Open CONF_INSTALL_FOLDER/bin/setenv.sh (setenv.bat or service under Windows)
      2. Locate "CATALINA_OPTS" and add the below line to the file:
        CATALINA_OPTS="-Dconfluence.startup.remigration.disable=true ${CATALINA_OPTS}"
      3. Save the file and restart Tomcat.

      This workaround has been verified to work for Confluence 9.x and would need to be present in the setenv file prior to the first restart of Confluence after an upgrade.

        1. image-2025-03-27-12-51-37-279.png
          image-2025-03-27-12-51-37-279.png
          29 kB

          Form Name

            [CONFSERVER-37710] Confluence remigrates Wiki Markup content on restart if a plugin is updated

            Steve Shaw added a comment -

            Hello All,

            This issue has been both reported and confirmed on a recent version of Confluence and therefore has been subsequently re-opened. It will be monitored for further activity and continue to be reviewed in accordance to our Bugfix Policy. Please note the workaround provided above in the meantime if this issue is run into.

            Steve Shaw added a comment - Hello All, This issue has been both reported and confirmed on a recent version of Confluence and therefore has been subsequently re-opened. It will be monitored for further activity and continue to be reviewed in accordance to our Bugfix Policy . Please note the workaround provided above in the meantime if this issue is run into.

            Robert Chang added a comment -

            A workaround has been added to the description of related ticket CONF-32837, which provides a method via SQL to disable the remigration job on restarts. As with all database manipulation tasks, please be sure to test this on a non-Production environment first.

            Robert Chang added a comment - A workaround has been added to the description of related ticket CONF-32837 , which provides a method via SQL to disable the remigration job on restarts. As with all database manipulation tasks, please be sure to test this on a non-Production environment first.

            Richard Atkins added a comment -

            The migration code triggers when a plugin with a xhtml-macro is installed, in case it used to only be a regular wikimarkup macro, or in case that macro wasn't present at all, but now is.

            We can make the code a lot smarter about how it chooses what content to migrate, and which macro installs should trigger it. This can include:

            • if we're doing a plugin upgrade, and the old version had xhtml-macro "foo", and the new version has xhtml-macro "foo", then don't migrate anything
            • if we're doing a plugin upgrade, and the old version had wikimarkup macro "foo", and the new version has xhtml-macro "foo" - check (via the search index) if there are any usages of "foo" in unmigrated content. If there are none, then don't migrate anything
            • if we're doing a plugin upgrade, and the old version didn't have any macros, but the new version has xhtml-macro "foo" - check (via the search index) if there are any usages of "foo" in unmigrated content. If there are none, then don't migrate anything

            We can also be smarter about whether we store a new version of a page when migrating. If we didn't actually change anything, then we shouldn't store the new version. Note that as of Confluence 5.8, we inject a macroId into the content for each xhtml-macro, so any check for changes to save will need to ignore that. There is also a known issue around remigration inserting redundant empty paragraphs around block-level macros that can ruin padding on some tables and comments (or any place where we don't do a great job of collapsing adjacent newlines) - any fix should address this issue as well.

            Richard Atkins added a comment - The migration code triggers when a plugin with a xhtml-macro is installed, in case it used to only be a regular wikimarkup macro, or in case that macro wasn't present at all, but now is. We can make the code a lot smarter about how it chooses what content to migrate, and which macro installs should trigger it. This can include: if we're doing a plugin upgrade, and the old version had xhtml-macro "foo", and the new version has xhtml-macro "foo", then don't migrate anything if we're doing a plugin upgrade, and the old version had wikimarkup macro "foo", and the new version has xhtml-macro "foo" - check (via the search index) if there are any usages of "foo" in unmigrated content. If there are none, then don't migrate anything if we're doing a plugin upgrade, and the old version didn't have any macros, but the new version has xhtml-macro "foo" - check (via the search index) if there are any usages of "foo" in unmigrated content. If there are none, then don't migrate anything We can also be smarter about whether we store a new version of a page when migrating. If we didn't actually change anything, then we shouldn't store the new version. Note that as of Confluence 5.8, we inject a macroId into the content for each xhtml-macro, so any check for changes to save will need to ignore that. There is also a known issue around remigration inserting redundant empty paragraphs around block-level macros that can ruin padding on some tables and comments (or any place where we don't do a great job of collapsing adjacent newlines) - any fix should address this issue as well.

              zzhou Zhenhuan Zhou (Inactive)
              a38518e05741 David Yu
              Affected customers:
              3 This affects my team
              Watchers:
              20 Start watching this issue

                Created:
                Updated: