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

Using color macro inside headings in Wiki Markup results in double headings

      Using color macro inside headings in Wiki Markup results in double headings

      Steps to reproduce

      1. Create a new page
      2. Insert Wiki Markup macro
      3. Copy and paste the following wiki markup (there is an unknown macro inserted here to prevent the wiki markup to be automatically converted on the fly in the Editor):
        h1. {color:red}Test{color}
        {nonexistentmacro}test{nonexistentmacro}
        
      4. Save the page

      Workaround
      Create a heading in the Editor and change its color manually (without using wiki markup)

            [CONFSERVER-26596] Using color macro inside headings in Wiki Markup results in double headings

            Matt Ryall added a comment -

            Unfortunately, we won't be able to fix this issue, so I'm going to close it as Won't Fix.

            The wiki markup macro and our entire legacy wiki pipeline is now only a backwards compatibility mechanism, and we aren't actively enhancing it. In this case, the interaction between the heading anchor generation and legacy colour macro is causing the problem.

            In fact, frequent bugs around colours inside headings like this was one of the main reasons that spurred us to write the XHTML editor and move away from wiki markup in the first place!

            So customers who hit this problem will have to manually fix it by using the rich text editor. If affected customers have hundreds of pages affected, please contact our support team with details and they can help you work out a way to fix it in bulk.

            Matt Ryall added a comment - Unfortunately, we won't be able to fix this issue, so I'm going to close it as Won't Fix. The wiki markup macro and our entire legacy wiki pipeline is now only a backwards compatibility mechanism, and we aren't actively enhancing it. In this case, the interaction between the heading anchor generation and legacy colour macro is causing the problem. In fact, frequent bugs around colours inside headings like this was one of the main reasons that spurred us to write the XHTML editor and move away from wiki markup in the first place! So customers who hit this problem will have to manually fix it by using the rich text editor. If affected customers have hundreds of pages affected, please contact our support team with details and they can help you work out a way to fix it in bulk.

            Robin Toop added a comment -

            Sorry not sure what the last comment here was supposed to convey.

            1) this is some internal unit test jira dev's are supposed to run after builds?

            2) this is some windows notepad ++ regex that will match some thing and replace it with something else, that should fix this situation? if so Why? this functionality was reverted to original functionality on on demand ~2 wks ago

            3) ?

            I really appreciate help and comments from engineers etc, but kinda need to figure out what message you are trying to get across to your audience and how to best present it.

            You need to remember that most end users use the JIRA suite as a tool to get our jobs done, and actually focus most of our times on those jobs, thus when slightly cryptic responses pop up, it takes us a bit of time to try and figure out what is trying to be said. Thus at least for me the format of

            I) here is the problem as I see it
            II) here is the verification of that (if needed)
            III) here is what you need to do to work around the problem (temporally or permanently)
            III) this is when the issue will be fixed if iii) is not a permanent fix.

            Thx

            Robin Toop added a comment - Sorry not sure what the last comment here was supposed to convey. 1) this is some internal unit test jira dev's are supposed to run after builds? 2) this is some windows notepad ++ regex that will match some thing and replace it with something else, that should fix this situation? if so Why? this functionality was reverted to original functionality on on demand ~2 wks ago 3) ? I really appreciate help and comments from engineers etc, but kinda need to figure out what message you are trying to get across to your audience and how to best present it. You need to remember that most end users use the JIRA suite as a tool to get our jobs done, and actually focus most of our times on those jobs, thus when slightly cryptic responses pop up, it takes us a bit of time to try and figure out what is trying to be said. Thus at least for me the format of I) here is the problem as I see it II) here is the verification of that (if needed) III) here is what you need to do to work around the problem (temporally or permanently) III) this is when the issue will be fixed if iii) is not a permanent fix. Thx

            childnode added a comment -

            annoying workaround: replace / remove by

            (h\d+\. )\{color:#[^\}]*\}((?:(?!\{color\}).)*)\{color\}
            \1\2
            

            e.g. via Notepad++

            childnode added a comment - annoying workaround: replace / remove by (h\d+\. )\{color:#[^\}]*\}((?:(?!\{color\}).)*)\{color\} \1\2 e.g. via Notepad++

            Robin Toop added a comment -

            So I just wanted to add my comment, and ask a question.

            We have run across this issue starting I think with the 6.0 series of Jira OnDemand.
            We are currently running V 6.2-OD-03, build 6206.

            It is logged under JST-81268

            So for the last ~2+ years we have been programatically creating our deployment reports using Conflunce.(we actually always created our deployment reports in confluence just programatically for the last few years)

            After I logged this I received the answer below as a work around. Apparently you have changed the url parameters now requiring them to be url encoded.

            ----------------------------------------------------------------------
            Running the same search that you used and then choosing Export > XML gives the following URL

            https://dating.jira.com/sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?jqlQuery=project+%3D+DB+and+issuetype+%3D+%22Deployment+Task%22+and+resolution+in+%28Unresolved%2C+Fixed%2C+%22Verified+-+On+Test%22%29+and+fixVersion+in+%28%22DB28+%28family%29%22%2C+DB28A%2C+DB28B%29&tempMax=1000

            Apparently you can't just copy the URL from the navigator and past it into the macro because the format of the URL will break the page - notice that the characters in the URL above are all encoded. Sticking that URL into the jiraissues macro and pasting the whole shebang into the Insert Markup page.

            ...works fine!

            ----------------------------------------------------------------------

            So my Response to this is, this is a definite work around .

            However my concern is the code producing this report, has not changed in at least 2 years, parameter wise. So this is a regression test failure on your side.

            We can fix the code generation to be uuencoded, however this will not fix our ~ 2 years of reports. (which don't get updated that much, but sometimes do get updated)

            ------------------------------
            My question to you is are you going to ?
            ------------------------------

            A) fix the code so that it works as it did before

            or

            B) this new format is the standard, and you will not be changing away from the uuencoded
            inserts again?

            If you could make a decision and let us know,
            would appreciate it. Thanks.

            ps. your test suites seem to be pretty bare, every time you do a major update, you break a LOT of stuff you don't seem to be aware of.

            Robin Toop added a comment - So I just wanted to add my comment, and ask a question. We have run across this issue starting I think with the 6.0 series of Jira OnDemand. We are currently running V 6.2-OD-03, build 6206. It is logged under JST-81268 So for the last ~2+ years we have been programatically creating our deployment reports using Conflunce. (we actually always created our deployment reports in confluence just programatically for the last few years) After I logged this I received the answer below as a work around. Apparently you have changed the url parameters now requiring them to be url encoded . ---------------------------------------------------------------------- Running the same search that you used and then choosing Export > XML gives the following URL https://dating.jira.com/sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?jqlQuery=project+%3D+DB+and+issuetype+%3D+%22Deployment+Task%22+and+resolution+in+%28Unresolved%2C+Fixed%2C+%22Verified+-+On+Test%22%29+and+fixVersion+in+%28%22DB28+%28family%29%22%2C+DB28A%2C+DB28B%29&tempMax=1000 Apparently you can't just copy the URL from the navigator and past it into the macro because the format of the URL will break the page - notice that the characters in the URL above are all encoded. Sticking that URL into the jiraissues macro and pasting the whole shebang into the Insert Markup page. ...works fine! ---------------------------------------------------------------------- So my Response to this is, this is a definite work around . However my concern is the code producing this report, has not changed in at least 2 years, parameter wise. So this is a regression test failure on your side. We can fix the code generation to be uuencoded, however this will not fix our ~ 2 years of reports. (which don't get updated that much, but sometimes do get updated) ------------------------------ My question to you is are you going to ? ------------------------------ A) fix the code so that it works as it did before or B) this new format is the standard, and you will not be changing away from the uuencoded inserts again? If you could make a decision and let us know, would appreciate it. Thanks. ps. your test suites seem to be pretty bare, every time you do a major update, you break a LOT of stuff you don't seem to be aware of .

            Is there some reason we can't edit Confluence issues any more?

            Please add 5.1 to the list of affected releases.

            Bob Swift (personal) added a comment - Is there some reason we can't edit Confluence issues any more? Please add 5.1 to the list of affected releases.

            DanielA added a comment -

            This applies to the linking macro as well. A quick test with the code macro yields similar duplication. I would wager that this applies to other macros as well.

            DanielA added a comment - This applies to the linking macro as well. A quick test with the code macro yields similar duplication. I would wager that this applies to other macros as well.

              matt@atlassian.com Matt Ryall
              asanusi AmaliaA
              Affected customers:
              8 This affects my team
              Watchers:
              24 Start watching this issue

                Created:
                Updated:
                Resolved: