The way I see it, there is no easy fix since we can't really process all links?! Or is this a bug?
Maybe if we provide a transclusion syntax like this { Wagn on Apache+public folder symlink prior to 1.13 | LINK: whatever text one may want to appear in the link } for creating links we can support this scenario easier?
PS. It would be nice to have it just the way it is now and have it rename.
links are supposed to auto-rename, too. I'll have to check, but I think the issue may be relative vs absolute references?
It's supposed to work on relative and absolute links, right? There should even be tests for both scenarios.
I note that it won't work on external links or free links, and you have a link to this same page as a free link (always external) in the +example part of this issue. That one shouldn't rename, but the others should.
I think we have some brokenness. I renamed Wagn on Apache to Wagn one Apache and it did not rename the inclusion that had this as part of the name. The link is relative, so doesn't include the part I renamed. I'm going to try a couple more cases. (and rename things back)
Now the link is absolute. Could that have happened in the rename process?
I think maybe there is an issue with renaming a part, but links vs. inclusions seem to be ok.
You'll have to make sure with your own testing (or try to assign this to one of your expanding team :) ), but there definitely are some oddities here. I think it is only links that do the relative to absolute change (when you rename the +X part of the whole name).
The short reply is that there are clearly bugs, but most of the handling of links and inclusions is shared, so I would expect problems to be shallow, not systemic.
(So I'll go ahead and mark this "answered", but we do need to do a system review of renaming cases and related test coverage)
Great! I thought this behavior was a design decision.
I've renamed the title from systemic to shallow.