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

HTML Export fails to redirect URL attachments to the "locally" exported directory structure

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: High High
    • 2.3
    • 2.1.2
    • None

    • Confluence 2.1.2 hosted at Atlassian

      When you export a confluence space in HTML format the attachments, althought they are packaged in the exported zip file, are not accessible since the HTML tag (in the exported HTML souce code) <a href=... points to an external URL and not to the new, relative file path on the locally exported repository.

      This also applies to images in the ../icons/emoticons directory. Once the space is exported to HTML the href for all these icons point to a wrong relative file path.

      This applies to all pages, no matter whether you are using unicode/high-bit characters in the page title or not.

            [CONFSERVER-5336] HTML Export fails to redirect URL attachments to the "locally" exported directory structure

            Tom Moore added a comment -

            This is still broken in 2.8

            Tom Moore added a comment - This is still broken in 2.8

            Agnes Ro added a comment -

            This should have been fixed with CONF-5143 (on head).

            Agnes Ro added a comment - This should have been fixed with CONF-5143 (on head).

            jd lima added a comment -

            This sounds suspiciously similar to our XML restore problem (http://jira.atlassian.com/browse/CONF-6134). In our case the restore process seems to bungle the attachment location when it tries to move the unzipped files to the restored hash directories – it seems to use the new hashes as the source directories, which don't exist of course.

            Does the HTML import produce external URLs with directories consistent with the contents of the zip file, or does it use new (rehashed) directories?

            jd lima added a comment - This sounds suspiciously similar to our XML restore problem ( http://jira.atlassian.com/browse/CONF-6134 ). In our case the restore process seems to bungle the attachment location when it tries to move the unzipped files to the restored hash directories – it seems to use the new hashes as the source directories, which don't exist of course. Does the HTML import produce external URLs with directories consistent with the contents of the zip file, or does it use new (rehashed) directories?

              Unassigned Unassigned
              a6b3957b101e Hernan Cunico
              Affected customers:
              6 This affects my team
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: