Details
-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
11.10.10, 12.6.2
-
None
-
Unknown
-
Description
How to reproduce:
- create an xwiki page (terminal or non terminal), A
- create a second page, B, terminal
- add, in the content of A, a link to B, using wiki syntax, using the following syntax:
[[Sandbox.B]]
The link will display just fine, the backlink of A will be found on B (not impacted by XWIKI-17933 because of the order of creation of pages).
- rename page B to another page (terminal or non-terminal)
In the rename screen, you will see the question about the backlink, proposal to refactor it. If you click on the link, page A will show up correctly. Make sure the refactor backlinks checkbox is checked upon rename
Expected result:
- the link in A is refactored to point to the page in which B was renamed
Actual result:
- the link in A stays pointing to B and is now a broken link
Note: this issue may happen a lot on "legacy content" , from an older XWiki, where default link type was doc: and so no-one was putting that in the links.
It will also probably appear frequently if the favorite editor of users is wiki editor, since I doubt anyone will put doc: in links when creating them manually.
On 12.6.2, the Wysiwyg editor appears to be generating typed links, prefixed by doc: , thus the issue won't reproduce anymore for refactoring of the links created from Wysiwyg.
Attachments
Issue Links
- is related to
-
XWIKI-17933 Untyped links to terminal pages are not stored properly as backlinks if the target page is created after the creation of the link
- Open
-
XWIKI-19285 Links refactoring of renamed pages does not work when referencing root spaces
- Open
-
XWIKI-12920 Hiding WebHome in wiki link syntax
- Closed
- relates to
-
XWIKI-18634 Image references are broken when contained in a renamed terminal page
- Open