Last modified: 2010-05-15 15:38:16 UTC
This patch adds support for a new magic variable {{SUBPAGENAME}}. In namespaces allowing subpages, it returns the name of the subpage by stripping out text up to the last slash present. In namespaces that do not allow subpages, it returns the same text as {{PAGENAME}}. This patch has been reviewed by Brion Vibber.
Created attachment 1335 [details] patch to add support for {{SUBPAGENAME}}
(In reply to comment #0) > ... In namespaces that do not allow subpages, it returns the same text as > {{PAGENAME}}. Hallo Trey! In my opinion *all* namespaces allow subpages. Displaying the links to the "parent" pages is a configuration issue which may change. If such a configuration changes this patch (as specified) may brake links. Such changes happen quite often: See Bug 1353: Wikibooks should have enabled subpages on main namespace Bug 1467: Subpages don't work in Help_talk: and Category_talk: Bug 2509: Allow subpages in main namespace of Vietnamese Wikibooks Bug 4248: Enable subpages for 2 new namespaces (#4247) at Italian Wikipedia and Italian Wikisource Bug 4809: Enable subpages on Portal namespace in Swedish Wikipedia best regards reinhardt [[user:gangleri]]
Reinhardt, I don't understand your comment. This patch makes use of areSubpagesAllowed(), which should be definitive. It certainly follows configuration changes; I tested this. Could you demonstrate a case where this patch would break things? In none of the bugs you quoted would this patch break; $wgNamespacesWithSubpages was changed, which would change the return of areSubpagesAllowed(). Thanks, Trey
Hi Trey! Let's assume [[n:en:Crosswords/2005]] contains [[category:{{SUBPAGENAME}}]] or a template containing [[category:{{SUBPAGENAME}}]]. At this moment [[n:]] does not show parent pages in the main namespace. [[n:en:Crosswords/2005]] would be in n:en:category:Crosswords/2005 . I understand that {{SUBPAGENAME}} would change value *after* enabeling "show parent pages". [[n:en:Crosswords/2005]] will be then in n:en:category:2005 . This example is only theoretical. There is no life example because {{SUBPAGENAME}} is not available in HEAD / life. ---- Regarding Bug 2343: navigation to parent pages of a subpage url: [[user:Gangleri/sandbox/alef/bet/gimel/dalet]] which is marked by Brion as WONTFIX with the comment "User error: don't do that!" [[n:en:Crosswords/]] is a similar parent page which would *not / *never* show as parent page. *question* What value would be assigned to {{SUBPAGENAME}} at [[n:en:Crosswords/]]? Would {{SUBPAGENAME}} be "void" / "empty"? best regards reinhardt [[user:gangleri]]
It is false that all namespaces allow subpages. We went to a lot of trouble in 2001-2002 to get subpages disabled in article space so that the / character could be used without creating false subpages. Please stop spewing irrelevant comments all over bug reports.
Since subpages and parent-pages are not first-class entities in MediaWiki, this patch simply does a best-effort by trimming all text up to a final slash, if a slash exists. This would result in empty in pages ending in a slash. As Brion says, just don't do that in namespaces allowing subpages. This magic variable is meant to be convenient, not authoritative.
(In reply to comment #5) > It is false that all namespaces allow subpages. We went to a lot of trouble in 2001-2002 > to get subpages disabled in article space so that the / character could be used without > creating false subpages. Thanks Brion! I know about "false positives" as [[en:AC/DC]]. I understand that the MediaWiki configuration regarding the "/" character is just an interpretation / rendering issue. I assume (and please correct me if I am wrong) that adding a namespace to $wgNamespacesWithSubpages ([[meta:Help:Custom_namespaces]]) does not involve table changes / different handling. I did not create myself [[n:en:Crosswords/]] and have seen more similar pages. (In reply to comment #6) Thanks for the answer!
Added in SVN HEAD a long time ago.
