Last modified: 2010-05-15 15:38:16 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 4804 - patch to add support for {{SUBPAGENAME}} magic variable
patch to add support for {{SUBPAGENAME}} magic variable
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.5.x
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch-reviewed
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-31 06:04 UTC by Trey Harris
Modified: 2010-05-15 15:38 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
patch to add support for {{SUBPAGENAME}} (1.98 KB, patch)
2006-01-31 06:05 UTC, Trey Harris
Details

Description Trey Harris 2006-01-31 06:04:19 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.
Comment 1 Trey Harris 2006-01-31 06:05:09 UTC
Created attachment 1335 [details]
patch to add support for {{SUBPAGENAME}}
Comment 2 lɛʁi לערי ריינהארט 2006-01-31 19:32:46 UTC
(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]]
Comment 3 Trey Harris 2006-01-31 20:17:27 UTC
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
Comment 4 lɛʁi לערי ריינהארט 2006-01-31 20:55:34 UTC
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]]
Comment 5 Brion Vibber 2006-01-31 20:58:38 UTC
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.
Comment 6 Trey Harris 2006-01-31 21:03:29 UTC
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.
Comment 7 lɛʁi לערי ריינהארט 2006-01-31 22:46:26 UTC
(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!
Comment 8 Rob Church 2006-04-02 23:26:12 UTC
Added in SVN HEAD a long time ago.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links