Hi koehler, unfortunately the general issue with special characters in page titles (as in CONF-24785 and CONF-24540) has not been fixed by this fix, but this was an important step on the way to fixing that. We'll be addressing this general issue in a later release.

Dear Richard, what if the renamed title contains a special character (CONF-24785)? That yieled error messages, too. Only if renamed pages always change the macro correctly, this bug fix here is really complete. Is it also possible to include pages from other spaces? Thanks, Henning

This is finally implemented, and will ship in OnDemand soon, and will be available in Confluence 5.3.

To update those watching, it is actually still in progress. There's no firm date of release I can give you yet unfortunately, only that it definitely will not be in the next release (5.2).

Good question. In which version of Confluence it will be resolved ???

Current version is 5.1.2 and this is still "In Progress", i.e. "Unresolved".

karie.kelly@phytel.com, this is a complex issue and we've been working on it for quite a while now.

Storage format doesn't use internal ids or tinylinks. It can't if it is to remain functionally equivalent to wiki markup (e.g. you can export a space, re-import it again on a restored instance, etc and still have all the links work). We also have other requirements, predominantly from tech writers which require support for taking pages from one space, copying them to another and having them continue to link relatively i.e. they should now link to their new space.

Essentially there are lots of current and legacy reasons why we use document title and space key where necessary for content links.

This is all a moot point at the moment though since macros do not represent links to content as links at all. This is also for legacy reasons where people used to be required to handcraft wiki markup representations of macros and so required a syntax that was actually understandable to humans. There were a number of other historic requirements that made this approach necessary at the time.

So firstly we need to find a compatible way to migrate the way we store macros which refer to other content. And again this is complex for a number of reasons. It means an upgrade task that will scan the entire content of your wiki. It also requires to be re-runnable. If certain macros are disabled at the point of upgrade then they will need to remain unconverted. If they are later enabled again, then the migration should re-run. In addition, not all macro authors have provided metadata about their macro parameters and so a re-migration would be ineffectual anyway.

Secondly we need to then ensure that macros are considered during refactoring operations. Luckily there isn't too much effort required for this step.

I'm not directly involved but have been assisting here and there since the start of September. Our initial approach to fixing this proved to be suboptimal. We then started a second attempt around the end of September. This is looking promising and is nearing the end of its review phase.

So that isn't the full picture but hopefully it gives you some insight into the effort required in dealing with this issue. The biggest remaining challenge now is to find a suitable code branch to land this complex and large piece of work upon. It certainly won't be able to land on a stable/bug-fix release e.g. not on 4.3.4 or 4.3.5.

It is more likely to land in a 5.x release. I'm not sure 5.0 will be possible due to the complexity of other parallel work that is being done in 5.0. 5.1 seems much more likely.

I am perplexed as to why this is such a complex issue. If the include or excerpt include originally references the internal ID or tinylink vs a space: page name, then renaming a page should not matter and you keep the referential integrity.

Thank you for fast answer. I will watch that issue which you recommend.

This issue is currently in progress, but there are some complexities around it that mean it might not be resolved for some time. Most of the work is being tracked in CONF-3649 so I'd recommend watching that issue too for any updates.