Extension talk:SubPageList3

Difference between this extension and using the prefixindex special page
In an IRC discussion today, Splarka raised a good question about the difference between this extension and the prefixindex special page. In particular, he suggested using the following transclusion   to save about 500 lines of PHP! Here's an attempt to answer: In short, the SubPageList3 extension is a user-friendly little menu creator more finely attuned to the needs of people on Wikibooks and Wikiversity who need to create content tables for their multi-page projects. (I hope).
 * 1) The prefixindex special page cannot do bullets.
 * 2) The prefixindex special page cannot do inheritance indents (like a tree).
 * 3) The prefixindex special page cannot do a horizontal bar menu.
 * 4) The prefixindex special page cannot do something like the "kidsonly" option (i.e. show children but not grandchildren).
 * 5) The prefixindex special page cannot cope with pseudo-subpages - i.e. subpages on non-Wikimedia wikis where the admins don't understand that forward slashes aren't all it takes to make a "real" subpage. Coping with pseudo-subpages is more intuitive from the user perspective.
 * 6) I can't get Splarka's transclusion code to exclude the paths (i.e. option of just having the final name without the path).
 * 7) Probably a few other things too.
 * --McCormack 12:03, 26 February 2008 (UTC)

Further comment: if   can be used to recreate exactly what this extension does, perhaps someone could demo this below? Thanks! --McCormack 10:40, 28 February 2008 (UTC)

Pseudo-subpages and $wgNamespacesWithSubpages
See: $wgNamespacesWithSubpages. See also Category:Subpage variables just in case anyone ever thinks of any more.

Another point was raised here by Splarka: that by default, subpages are "disabled" in Mediawiki's main namespace but not in the other namespaces. The default settings are kept for most Wikimedia projects, but not for Wikibooks and Wikiversity. Subpage-"disabling" really just means that "/" is just any old character in a page title rather than a subpage indicator. The difference has no meaning at all for ordinary users, but internally the MediaWiki code makes a distinction, so the end result is that there are "real subpages" (where the internal code identifies them as such) and "pseudo-subpages" (where the internal code does not recognize any link with the parent, but where the user sees them as looking just like the real thing). Splarka raised the question whether or not this extension could or should respond just to "real" subpages or "pseudo" subpages. The answer is that the extension is indifferent to the internal code distinction: if it looks like a subpage, then the extension treats it as such. This means that the tag will always behave as a naive editor expects it too, which is perhaps more user-friendly. Imagine having to explain to your average editor that the tag worked in a namespace-dependent fashion on some wikis and not others, depending how the $wgNamespacesWithSubpages tag was set! Of course, this then opens the door to the danger that IF the extension was ever activated on (e.g.) Wikipedia (rather than Wikibooks or Wikiversity), then naive editors might start putting tags into articles and getting rather counter-intuitive results; in response to this: such uses of the tag would be obviously silly and quickly revertible - i.e. we probably don't need to be worrying about such things at the programmatic level. If the day comes when we do need to worry about such things at the programmatic level, then we can create a $wgIsSensitiveToNamespaceSubpageDisabling variable, set to false by default, which could then be set to true on projects such as Wikipedia in the event that they also adopt the extension. --McCormack 13:14, 26 February 2008 (UTC)

Namespace & "parent" param bug
I tried the following:  In my "User:" page and it didn't find any subpages, but when I put it in a different page, Sandbox2, it did find subpages. -Paul 18:01, 29 February 2008 (UTC)
 * I see now the bug listed, but it says it was fixed in the initial release. Either I have an old version of the bug is still there.  I pulled it from the SVN link.  Is there a new one else where? -Paul 18:45, 29 February 2008 (UTC)
 * I made a change to the code to fix the problem. On line 381, I changed: $nsi = $this->title->getNamespace; to $nsi = $this->ptitle->getNamespace; There seemed to be a missing 'p'.  -Paul 19:00, 29 February 2008 (UTC)

Hi Paul and thanks for your report. Where did you test this? I would like to look at how you set this up. --McCormack 06:05, 4 March 2008 (UTC)


 * Hi. I've looked at this further, and discovered that someone changed my code before uploading to SVN. At least 3 lines of code were changed, and this included the introduction of the bug you reported. --McCormack 07:28, 4 March 2008 (UTC)


 * This has now been corrected on SVN. Many thanks for reporting this, Paul. --McCormack 07:44, 4 March 2008 (UTC)