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

Migrate macros from org.radeox.macro.Macro to com.atlassian.renderer.v2.macro.Macro

XMLWordPrintable

    • 5
    • We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.

      Macros that implement org.radeox.macro.Macro get wrapped by a com.atlassian.renderer.macro.RadeoxCompatibilityMacro at runtime. This compatibility wrapper sets an attachment path in the render context which, once set, becomes fixed for the entire page render. Our embedded image renderer checks this context path and uses it without question once a value has been set. As the compatibility macro sets the path to be the attachment path for the current page, it breaks embedded images from other pages. In essence any macro that implements org.radeox.macro.Macro will break images embedded from other pages.

      We don't want to "fix" this behaviour as doing so would affect all macros that implement this interface and we would recommend that macros now implement the com.atlassian.renderer.v2.macro.Macro interface instead.

      In light of this we should migrate the macros that confluence ships with to use the new interface as well.

            [CONFSERVER-7316] Migrate macros from org.radeox.macro.Macro to com.atlassian.renderer.v2.macro.Macro

            Irina Tiapchenko made changes -
            Remote Link New: This issue links to "Page (Extranet)" [ 928129 ]
            Sen made changes -
            Workflow Original: JAC Suggestion Workflow 4 [ 3569223 ] New: JAC Suggestion Workflow 3 [ 4333332 ]
            Katherine Yabut made changes -
            Workflow Original: JAC Suggestion Workflow 2 [ 3174514 ] New: JAC Suggestion Workflow 4 [ 3569223 ]
            Status Original: RESOLVED [ 5 ] New: Closed [ 6 ]
            Katherine Yabut made changes -
            Workflow Original: JAC Suggestion Workflow [ 3031116 ] New: JAC Suggestion Workflow 2 [ 3174514 ]
            Owen made changes -
            Workflow Original: Confluence Workflow - Public Facing v4 [ 2533540 ] New: JAC Suggestion Workflow [ 3031116 ]
            Rachel Lin (Inactive) made changes -
            Workflow Original: Confluence Workflow - Public Facing v3 [ 2292637 ] New: Confluence Workflow - Public Facing v4 [ 2533540 ]
            Katherine Yabut made changes -
            Workflow Original: Confluence Workflow - Public Facing v3 - TEMP [ 2187198 ] New: Confluence Workflow - Public Facing v3 [ 2292637 ]
            Katherine Yabut made changes -
            Workflow Original: Confluence Workflow - Public Facing v3 [ 1913783 ] New: Confluence Workflow - Public Facing v3 - TEMP [ 2187198 ]
            Katherine Yabut made changes -
            Workflow Original: Confluence Workflow - Public Facing v2 [ 1752187 ] New: Confluence Workflow - Public Facing v3 [ 1913783 ]
            jonah (Inactive) made changes -
            Description Original: Macros that implement org.radeox.macro.Macro get wrapped by a com.atlassian.renderer.macro.RadeoxCompatibilityMacro at runtime. This compatibility wrapper sets an attachment path in the render context which, once set, becomes fixed for the entire page render. Our embedded image renderer checks this context path and uses it without question once a value has been set. As the compatibility macro sets the path to be the attachment path for the current page, it breaks embedded images from other pages. In essence any macro that implements org.radeox.macro.Macro will break images embedded from other pages.

            We don't want to "fix" this behaviour as doing so would affect all macros that implement this interface and we would recommend that macros now implement the com.atlassian.renderer.v2.macro.Macro interface instead.

            In light of this we should migrate the macros that confluence ships with to use the new interface as well.             		New: {panel:bgColor=#e7f4fa}
              *NOTE:* This suggestion is for *Confluence Server*. Using *Confluence Cloud*? [See the corresponding suggestion|http://jira.atlassian.com/browse/CONFCLOUD-7316].
              {panel}

            Macros that implement org.radeox.macro.Macro get wrapped by a com.atlassian.renderer.macro.RadeoxCompatibilityMacro at runtime. This compatibility wrapper sets an attachment path in the render context which, once set, becomes fixed for the entire page render. Our embedded image renderer checks this context path and uses it without question once a value has been set. As the compatibility macro sets the path to be the attachment path for the current page, it breaks embedded images from other pages. In essence any macro that implements org.radeox.macro.Macro will break images embedded from other pages.

            We don't want to "fix" this behaviour as doing so would affect all macros that implement this interface and we would recommend that macros now implement the com.atlassian.renderer.v2.macro.Macro interface instead.

            In light of this we should migrate the macros that confluence ships with to use the new interface as well.

              Unassigned Unassigned
              christopher.owen@atlassian.com Christopher Owen [Atlassian]
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: