Last modified: 2014-09-23 23:33:18 UTC
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.
*** Bug 9319 has been marked as a duplicate of this bug. ***
*** Bug 29073 has been marked as a duplicate of this bug. ***
Created attachment 10348 [details] 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.
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.
Marking patch reviewed. Akshay, can you revise your patch to respond to Max's and Krinkle's feedback? Thanks.
(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 .
(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. ***
