Hey MediaWiki devs!
TL;DR: When including a SpecialPage (e.g. Special:PrefixIndex), how can the code access the Title of the page currently being rendered?
I'm sure I'm missing sometthing as I track down this issue, so maybe this plea for help will result in my enlightenment.
For T373259[1], I thought it would be straight-forward to get the page that is the the parser is currently including the results of a special page into. Once I had that, I thought, it would be simple to address the issue since that page could be compared to the links that are included from PrefixIndex, but it looks like the context contains the SpecialPage that is being included and not the page that its output is being included into.
In my attempt to resolve the problem I was trying to solve, I refactored Special:PrefixIndex into something I could more easily digest[2].
After that, I'm left with renderRow()[3] where I used my l33t print-debug skills to fail to find any instance of the calling page--the page whose wikitext had the {{Special:PrefixIndex}} that was currently being expanded.
Maybe this is all documented somewhere or maybe it is common knowledge.
Perhaps it is just a limitation of the way the parser and/or transclusions works.
I know I'm ignorant. Can someone please enlighten me?
Thanks!
Mark
Footnotes: [1] https://phabricator.wikimedia.org/T373259
[2] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1069649 -- reviews welcome!
[3] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/6d33307d7908...
Hi Mark,
On 9/1/24 00:36, Mark A. Hershberger via Wikitech-l wrote:
TL;DR: When including a SpecialPage (e.g. Special:PrefixIndex), how can the code access the Title of the page currently being rendered?
I don't think it's possible, SpecialPageFactory::capturePath() goes to great lengths to hide the real title from code, including overwriting $wgTitle and IContextSource::getTitle().[1]
For T373259[1], I thought it would be straight-forward to get the page that is the the parser is currently including the results of a special page into. <snip>
Perhaps it is just a limitation of the way the parser and/or transclusions works.
I think special page transclusion has always been in a weird spot because people expect it to behave like the special page (and share code) but also be embedded in page context.
Personally I think implementing prefix index support in Lua, aka T49137[2], is a better way to go for customizing the output, but that has its own obstacles of course.
[1] https://gerrit.wikimedia.org/g/mediawiki/core/+/4a955432794ab5f6a609e23b18c9... [2] https://phabricator.wikimedia.org/T49137
-- Legoktm
Hi Kunal,
Kunal Mehta legoktm@debian.org writes:
Personally I think implementing prefix index support in Lua, aka T49137[2], is a better way to go for customizing the output, but that has its own obstacles of course.
Thanks for the pointer. It gives me some hope.
I spent a few hours confirming everything else you said ("SpecialPageFactory::capturePath() goes to great lengths to hide the real title from code") before I actually saw your email.
Mark.
Le 01/09/2024 à 06:36, Mark A. Hershberger via Wikitech-l a écrit :
Hey MediaWiki devs!
TL;DR: When including a SpecialPage (e.g. Special:PrefixIndex), how can the code access the Title of the page currently being rendered?
I'm sure I'm missing sometthing as I track down this issue, so maybe this plea for help will result in my enlightenment.
For T373259[1], I thought it would be straight-forward to get the page that is the the parser is currently including the results of a special page into. Once I had that, I thought, it would be simple to address the issue since that page could be compared to the links that are included from PrefixIndex, but it looks like the context contains the SpecialPage that is being included and not the page that its output is being included into.
<snip>
When transcluding a special page, you can think about it as using an iframe. The transclusion is merely including what the special page would have output, with some tweak such as removing the submittable form.
So as much as Special:PrefixIndex does not have a TITLE context, it does not have one either when it is being transcluded.
I think the primary use case for Special:PrefixIndex is to list subpages and I don't think there is much point in listing the root page in the listing when you are already on the root page. So that if you are on a page *Book* and have subpages *Book/Chapter_1 *and *Main_Page/Chapter_2* you would use:
{{Special:PrefixIndex/Book/|stripprefixindex=1}}
Which would exclude *Book* (since it does not match *Book/* ) and remove the common prefix of *Book/* which yields:
Chapter_1 Chapter_2
That is most probably going to be used in an infobox template. That in turns would probably be decorated with a link to *Book* which would not be linked when showing up on the Book page thanks to the magic of the MediaWiki parser.
See also https://gerrit.wikimedia.org/r/c/mediawiki/core/+/71911
So as much as I agree with the perceived consistency, I don't think that one has to be resolved since it is unlikely to be of any use.
Antoine "hashar" Musso
Antoine Musso hashar@free.fr writes:
I think the primary use case for Special:PrefixIndex is to list subpages and I don't think there is much point in listing the root page in the listing when you are already on the root page. So that if you are on a page *Book* and have subpages *Book/Chapter_1 *and *Main_Page/Chapter_2* you would use:
{{Special:PrefixIndex/Book/|stripprefixindex=1}}
So, the uses case I have is similar, but it this is in a template that is used on subpages so that if you are reading a sub page, you can easily skip ahead into different chapters.
Specifically, the use case is a list of countries, so that someone reading about, say, Argentina, they can use the infobox to jump to France easily.
To provide a concrete demonstration that demonstrates this using the countries listed, a top-level page is titled "List of Countries whose official languages are a romance language" and it uses a template to display its list of sub pages. Meanwhile, each sub-page could use the same template in the infobox to provide a navigation aid.
In this case, the page being viewed should not link to itself in the list of pages in the infobox. It would result in confusion.
So as much as I agree with the perceived consistency, I don't think that one has to be resolved since it is unlikely to be of any use.
I hope I've shown a useful use case. This is about more than just foolish consistency[1].
Mark.
Footnotes: [1] "A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines." -- Ralph Waldo Emerson https://www.goodreads.com/quotes/353571-a-foolish-consistency-is-the-hobgobl...
wikitech-l@lists.wikimedia.org