Page MenuHomePhabricator

ProofreadPages: Allow <pages/> tag on index pages
Open, Needs TriagePublic

Description

Currently this is disallowed in PagesTagParser.php:

		// abort if the tag is on an index or a page page
		if (
			$pageTitle->inNamespace( $this->context->getIndexNamespaceId() ) ||
			$pageTitle->inNamespace( $this->context->getPageNamespaceId() )
		) {
			return '';
		}

@Tpt Is there a technical reason for this? The code dates way back to 2009:

commit 85b903a0d937be50012765f41d46ba1a19925ddc
Author: ThomasV <thomasv@users.mediawiki.org>
Date:   Thu Sep 24 21:48:02 2009 +0000

    do not allow 'pages' command on index pages

diff --git a/ProofreadPage.php b/ProofreadPage.php
--- a/ProofreadPage.php
+++ b/ProofreadPage.php
@@ -714,0 +714,4 @@
+       # abort if the tag is on an index page
+       if ( preg_match( "/^$index_namespace:(.*?)(\/([0-9]*)|)$/", $wgTitle->getPrefixedText() ) ) {
+               return "";
+       }

It would be more consistent for users if we could use <pages/> on index pages too, since pages are often transcluded for TOCs in indexes.

Misuse of direct {{page:}} transclusion is a constant thing, and fewer legitimate uses of {{page:}} makes messaging clearer. Plus, it's easier to use ranges than copy-pasting n pages.

Event Timeline

@Tpt Is there a technical reason for this?

The <pages> tag implementation fetches the Index: page content from the database. Using it in the actual index that is used by the <pages> tag will lead to the use of the currently saved version of the index page on e.g. preview. So, to avoid strange bugs for the Wikisource contributors, enabling <pages> in the index pages requires a bit more than just removing this validation check.

@Tpt Is there a technical reason for this?

The <pages> tag implementation fetches the Index: page content from the database. Using it in the actual index that is used by the <pages> tag will lead to the use of the currently saved version of the index page on e.g. preview. So, to avoid strange bugs for the Wikisource contributors, enabling <pages> in the index pages requires a bit more than just removing this validation check.

Will it cause strange bugs in the predominant case, 99% of the time ? We just neeed to fetch a couple of pages, no weird tricks or anything clever. you're not fetching anything strange from the Index, just a <pages from=xx to=xx>

I assume this also breaks (via the quoted code) when <pages/> tag is included to an Index page indirectly (e.g., Xyzzy/ToC has <pages/> and an Index transcludes such via something like: {{Xyzzy/ToC}}. Incidentally, is this an across the board restriction or just one for prevent circular transclusion? Meaning can I use a <pages/> tag in an Index so long as the <pages/> tag refers to a different Index (e.g., a ToC in one volume of a multivolume work where volumes not containing the ToC could still include the ToC in their Index pages using a <pages/> tag` because it is not a circular reference)?