-
Bug
-
Resolution: Fixed
-
High
-
None
-
None
NOTE: This bug report is for Confluence Server. Using Confluence Cloud? See the corresponding bug report.
That is, [#foo] on a page called "Test Page" renders with an alias / link body of "Test Page#foo". In Confluence 3.5 we only displayed "foo" which is a lot nicer.
This was raised as regression in some of our documentation pages.
The second part of this issue is to make anchor links relative again in Confluence 4.0+, which isn't the case in the initial Confluence 4.0 release.
In other words, if a link leads to a target location on the same page (e.g. an anchor link), then in the XHTML storage format, don't store the page reference in the link itself. This was how Confluence 3.5 effectively used to work (in part because its content was stored in 'less sophisticated' wiki markup). However, since all links were treated as absolute links in the initial release of Confluence 4.0, this was causing all sorts of problems like:
- Displaying the page name and # character for relative anchor links
- https://studio.plugins.atlassian.com/browse/CPSP-45
For an initial discussion on how Confluence 4.0 should handle anchor links 'relatively', see this comment on CPSP-45
- causes
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
- mentioned in
-
Wiki Page Loading...
[CONFSERVER-23328] We display the page name and # character for relative anchor links + make anchor links relative (in the XHTML storage format for Confluence 4.0+).
Verified the embedded image and attachment links. Looks good.
Paul - can I resolve this? Is there a reason this is in tech review?
Can't reproduce the issue. Sorry for the false alarm.
I must have been looking at a link pointing to another space, in which case saving the space key is correct behaviour.
Joey, I can't reproduce this problem - I wonder if you can isolate the steps required? I'm testing as follows
1) Create a page which links to an anchor on another page in the same space
2) Copy the editor content and save the space
3) Create a new page within this same space and paste into it
4) Save the new page and check with 'view-storage'.
The anchor link does not have a space key.
I'll explain a little about what is supposed to happen behind the scenes in case that helps isolate the steps needed to reproduce the problem.
- The <a> in the editor representation has an attribute providing the database id of the content being linked to.
- The EditorUnmarshaller resolves this content to the appropriate page/blog.
- It then checks the context object which is a Draft in this case and if the Draft and the new page are within the same space then the space key is dropped.
ckhiel gave us the go ahead to start testing the anchor stuff.
The links remain relative through a copy space operation.
However links pointing to an anchor on another page become absolute (View Storage format: spacekey is defined) on copy and paste.
Paul do you want this managed in a separate issue?
Hi Joey,
If you're referring to the following workaround:
For the time being, in the 'Link' field of the 'Advanced' tab of the 'Create Link' dialog box, you need to prefix the anchor name with the original page title (followed by '#'). Don't specify anything in the 'Link Text' field.
The text of the new 'relative' anchor link will appear on the page as 'Page Name#name-of-anchor'.
When you copy the draft page content back to your original page (i.e. you publish the page update), the prefixed page title will miraculously 'vanish', such that the text of the new 'relative' anchor link will appear as 'name-of-anchor'.
Then the answer is yes.
Giles Gaskell [Atlassian]
added a comment - - edited Hi Joey,
If you're referring to the following workaround:
For the time being, in the 'Link' field of the 'Advanced' tab of the 'Create Link' dialog box, you need to prefix the anchor name with the original page title (followed by '#'). Don't specify anything in the 'Link Text' field.
The text of the new 'relative' anchor link will appear on the page as 'Page Name#name-of-anchor'.
When you copy the draft page content back to your original page (i.e. you publish the page update), the prefixed page title will miraculously 'vanish', such that the text of the new 'relative' anchor link will appear as 'name-of-anchor'.
Then the answer is yes. Hi Giles - can you verify that the anchors produced by the workaround specified work correctly?
Demoting this issue to 'critical'.
Because Confluence 4.0 does not handle relative anchor links, this means that anyone who:
- First does either of the following:
- Creates relative anchors (i.e. by specifying only '#name-of-anchor' in the 'Advanced' tab's 'Link' field of Confluence 4.0's 'Create Link' dialog box, without specifying any 'Link Text'), or
- Had created relative anchor links based on the wiki markup format [#name-of-anchor] in Confluence 3.5 or earlier (see http://confluence.atlassian.com/display/CONF35/Working+with+Anchors for details) and had upgraded to Confluence 4.0,
- Subsequently makes a copy of this page containing these relative anchor links (for draft purposes)...
...will see the text of these anchor links rendered as 'Page Name#name-of-anchor' (on their copied pages).
However, when they copy this draft page back to their originating page, the anchor link text will revert back to 'name-of-anchor'.
If you need to create new 'relative' anchor links on your copied draft pages - here's the workaround:
For the time being, in the 'Link' field of the 'Advanced' tab of the 'Create Link' dialog box, you need to prefix the anchor name with the original page title (followed by '#'). Don't specify anything in the 'Link Text' field.
The text of the new 'relative' anchor link will appear on the page as 'Page Name#name-of-anchor'.
When you copy the draft page content back to your original page (i.e. you publish the page update), the prefixed page title will miraculously 'vanish', such that the text of the new 'relative' anchor link will appear as 'name-of-anchor'.
Giles Gaskell [Atlassian]
added a comment - - edited Demoting this issue to 'critical'.
Because Confluence 4.0 does not handle relative anchor links, this means that anyone who:
First does either of the following:
Creates relative anchors (i.e. by specifying only '#name-of-anchor' in the 'Advanced' tab's 'Link' field of Confluence 4.0's 'Create Link' dialog box, without specifying any 'Link Text'), or
Had created relative anchor links based on the wiki markup format [#name-of-anchor] in Confluence 3.5 or earlier (see http://confluence.atlassian.com/display/CONF35/Working+with+Anchors for details) and had upgraded to Confluence 4.0,
Subsequently makes a copy of this page containing these relative anchor links (for draft purposes)...
...will see the text of these anchor links rendered as 'Page Name#name-of-anchor' (on their copied pages).
However, when they copy this draft page back to their originating page, the anchor link text will revert back to 'name-of-anchor'.
If you need to create new 'relative' anchor links on your copied draft pages - here's the workaround:
For the time being, in the 'Link' field of the 'Advanced' tab of the 'Create Link' dialog box, you need to prefix the anchor name with the original page title (followed by '#'). Don't specify anything in the 'Link Text' field.
The text of the new 'relative' anchor link will appear on the page as 'Page Name#name-of-anchor'.
When you copy the draft page content back to your original page (i.e. you publish the page update), the prefixed page title will miraculously 'vanish', such that the text of the new 'relative' anchor link will appear as 'name-of-anchor'.
@Joey
That issue is covered by
CONF-23332(not this one).I've reworded the summary of this issue by adding "+ make anchor links relative (in the XHTML storage format for Confluence 4.0+)" to the summary.
Hopefully this should make things clearer and explain why I've closed https://studio.plugins.atlassian.com/browse/CPSP-45 - unless of course there's a reason for re-opening CPSP-45 which I'm not aware of?