Would it be a useful additional feature for this extension to optionally (i.e. via a config flag) follow redirects when looking for the display-title? i.e. if a link is to a redirected page, then rather than displaying the display-title of the redirect (which probably wouldn't have one), it would go to the target page and get the display-title from there.
Topic on Extension talk:Display Title
Done, implemented in Gerrit change 393350.
Admittedly the current behaviour not to follow redirects was a lifesaver for me to force a certain page tile. Now that task T180413 is basically solved thanks to Cindy's effort I think that this could be a nice enhancement. I am not sure if a configuration parameter is needed for this but in general I tend to appreciate the additional flexibility they provide for different setups.
This is a great suggestion. I think it should be the default behavior, although I'm not against adding a configuration parameter to disable this. Do you think this should follow only a single level of redirect, or should it follow redirects until it arrive at a real page (in which case it would need to detect redirect loops)?
I also think that it should be default behaviour. I do not think however it should follow redirect loops. These double redirects should be cleared while gardening the wiki.
Check out https://gerrit.wikimedia.org/r/#/c/393350/ and let me know what you think. I didn't add a configuration flag at this point. I could add one if you think it is important, but I'm not sure it would ever get used, and I prefer not to overwhelm the user with unnecessary flags (YAGNI).
That patch works great! Thank you so much for working on this so quickly.
One thing, though (and perhaps this is desired): if page doesn't have a display-title set, and there is a redirect to it, then links to the redirect don't display the title of the target page (but instead display the title of the redirect). I guess I'm sort of thinking that the display-title of a redirect should be considered to be the title (or display-title) of the target page.
And good point about the config option; I just wasn't sure if this change would be considered breaking for people already used to the current behaviour.
> I guess I'm sort of thinking that the display-title of a redirect should be considered to be the title (or display-title) of the target page.
In other words: The title of the target page should be shown no matter if this one was "manipulated" or was left unchanged.
Yeah, that's right. Do you think that makes sense?
Yes, since the behaviour will be consistent.
OK, I think I understand :-) I uploaded another patch set. Let me know if this is now working the way you both expect. Thanks!
Thanks for the new change set which is working as this sandbox page shows.
Excellent! @Samwilson, if you confirm that it is working for you as well, I will merge.
Looks good!!
The only tiny thing I notice is the slight confusion contained on Special:WhatLinksHere when the redirect pages are now shown with the same title as the page that one is viewing. But I don't think that's too worrying.
And there's also the message after a page is moved, e.g. "Test page 2" has been moved to "Test page 2" which might be a bit strange.
I guess there are more edge-cases to this than I'd thought of to start with! But all up I think it's a good feature. :)
Indeed but this behaviour was in there before (see this move v1.3). Moreover I do not think that is a big issue if at all since in the end you care about the target page. A matter of optimization in the end. If that's easy to code than ... else ... ;) This needs however to be documented on the extension's page.
Yes, I think you're right: it's good, but it can come as a surprise to people newly-installing the extension and so attention should be drawn to it in the documentation.
But mostly: the patch seems solid and correct in doing what it does, so huzza for merging it! :-)
Yay!!
I agree that the link text on move and Special:WhatLinksHere is unexpected and needs to be documented. I had the same surprise when I moved pages in testing, and I knew what was going on. I can't think of an approach to fix this that wouldn't break other desired behavior and for which enough contextual information exists in the hook. But, with the agreement to document the behavior, I will happily merge.
Works wonderfully. :-)
I've got a bit of code in Extension:Genealogy that does pretty much this same thing, and I'm thinking of now removing it and recommending people instead install this.