Page MenuHomePhabricator

Optionally exclude subpages from Special:Allpages and Special:Prefixindex
Open, LowPublicFeature

Description

Listings generated from Special:Prefixindex and Special:Allpages tend to be messy, hard to
read, and unneccessary lengthy when many subpages are listed.

I suggest a checkbox: "[ ] exclude subpages"
or a pulldown or number input field: "include subpages up to level [___]".

in order to make listings more usable.

Arguably, the preset could be, not to include subpages, but although I usually would not want
them listed, my preference is to include them all, so as not to change default behaviour for
those doing nothing, and not to break programs using the pages.


Version: unspecified
Severity: enhancement

Details

Reference
bz7184

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:26 PM
bzimport set Reference to bz7184.
bzimport added a subscriber: Unknown Object (MLST).

*** Bug 9319 has been marked as a duplicate of this bug. ***

chughakshay16 wrote:

*** Bug 29073 has been marked as a duplicate of this bug. ***

chughakshay16 wrote:

It provides a checkbox to filter out the sub pages.

The changes made are :-
In SpecialAllPages.php

  1. $hideSubPages = $req->getBool('hideSub',false) - to get the value of checkbox
  2. change in SQL query

one more WHERE condition is added
'page_title NOT'.$dbr->buildLike($dbr->anyString(),'/',$dbr->anyString())
The same set of changes are made for SpecialPrefixIndex.php

In MessagesEn.php
'prefixhidesub' => 'Hide Sub Pages'

I havent added messages in other languages.

Attached:

Just 2 quick points:

  • Should it take into consideration which namespaces actually support subpages? For example on en.wikipedia.org the main article space does not have subpages enabled because articles like [[I/O]] naturally contain a slash but are not subpages. So this should check for [[mw:Manual:$wgNamespacesWithSubpages]]
  • I doubt %/% queries are using an index, which means they can't run on any major site.

A few points:

'prefixhidesub' => 'Hide Sub Pages'

Message key inconsistent with other messages on that special page, messages should use sentence case and consistent terminology ("subpages", not "sub pages").

Spacing is not compliant with our coding style.

Queries LIKE '%/%' are indeed impossible to be indexed, so a schema change would be required for this feature to work.

sumanah wrote:

Marking patch reviewed. Akshay, can you revise your patch to respond to Max's and Krinkle's feedback? Thanks.

chughakshay16 wrote:

(In reply to comment #5)

A few points:

'prefixhidesub' => 'Hide Sub Pages'

Message key inconsistent with other messages on that special page, messages
should use sentence case and consistent terminology ("subpages", not "sub
pages").

Spacing is not compliant with our coding style.

Queries LIKE '%/%' are indeed impossible to be indexed, so a schema change
would be required for this feature to work.

So , instead of changing the query , I could put if($hideSubPages) to prevent subpages from being displayed on the page, but i thought that would be too inefficient .

chughakshay16 wrote:

(In reply to comment #4)

Just 2 quick points:

  • Should it take into consideration which namespaces actually support subpages?

For example on en.wikipedia.org the main article space does not have subpages
enabled because articles like [[I/O]] naturally contain a slash but are not
subpages. So this should check for [[mw:Manual:$wgNamespacesWithSubpages]]

  • I doubt %/% queries are using an index, which means they can't run on any

major site.

Yes, i would rewrite the patch to take $wgNamespaceWithSubpages into account.

(In reply to comment #7)

So , instead of changing the query , I could put if($hideSubPages) to prevent
subpages from being displayed on the page, but i thought that would be too
inefficient .

That would make the UI confusing if you're expecting 50 results per page but you only seem to get 30.

At the risk of opening a huge can of worms, how about introducing a page_is_subpage or page_parent field? Easily indexable.

page_is_subpage is quite pointless just for such small feature, but page_parent could be interesting for many uses.

  • Bug 30964 has been marked as a duplicate of this bug. ***
Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:01 AM

I would propose to add a parameter "level=1" to the Special:PrefixIndex to e.g. limit the list to the first level (main subpages); level=2 would also show the sub-subpages, etc. When there are too many sublevels an unrestricted subpage list confuses the users. Then we could have the same list generating statement on the next sublevel, etc. making it more easy to easily navigate through subpages.

Example: {{Special:PrefixIndex/{{FULLPAGENAME}}/|stripprefix=1|level=1}}