Last modified: 2014-09-23 23:33:18 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 7184 - Optionally exclude subpages from Special:Allpages and Special:Prefixindex
Optionally exclude subpages from Special:Allpages and Special:Prefixindex
Status: NEW
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Low enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-reviewed
: 29073 30964 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-31 11:00 UTC by Purodha Blissenbach
Modified: 2014-09-23 23:33 UTC (History)
7 users (show)

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


Attachments
It provides a checkbox to filter out the sub pages. (10.06 KB, patch)
2012-03-29 10:05 UTC, akshay chugh
Details

Description Purodha Blissenbach 2006-08-31 11:00:10 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.
Comment 1 Carl Fürstenberg 2007-03-17 16:19:28 UTC
*** Bug 9319 has been marked as a duplicate of this bug. ***
Comment 2 akshay chugh 2012-03-29 09:43:12 UTC
*** Bug 29073 has been marked as a duplicate of this bug. ***
Comment 3 akshay chugh 2012-03-29 10:05:45 UTC
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.
Comment 4 Krinkle 2012-03-29 11:12:11 UTC
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.
Comment 5 Max Semenik 2012-03-29 21:16:34 UTC
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.
Comment 6 Sumana Harihareswara 2012-03-30 04:45:48 UTC
Marking patch reviewed. Akshay, can you revise your patch to respond to Max's and Krinkle's feedback?  Thanks.
Comment 7 akshay chugh 2012-03-30 12:55:28 UTC
(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 .
Comment 8 akshay chugh 2012-03-30 12:58:02 UTC
(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.
Comment 9 Chad H. 2012-03-30 13:00:34 UTC
(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.
Comment 10 Max Semenik 2012-03-30 17:20:55 UTC
page_is_subpage is quite pointless just for such small feature, but page_parent could be interesting for many uses.
Comment 11 db [inactive,noenotif] 2012-08-06 20:27:47 UTC
*** Bug 30964 has been marked as a duplicate of this bug. ***

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


Navigation
Links