Last modified: 2008-07-02 08:16:37 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 11132 - Option to not display [+] if no sub-category exists
Option to not display [+] if no sub-category exists
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
CategoryTree (Other open bugs)
unspecified
All All
: Normal enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 1212
Blocks: 13326
  Show dependency treegraph
 
Reported: 2007-08-31 04:48 UTC by Jamie Hari
Modified: 2008-07-02 08:16 UTC (History)
1 user (show)

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


Attachments
Proposed patch for "+" expansion (7.12 KB, patch)
2008-01-25 15:20 UTC, Harold Solbrig
Details

Description Jamie Hari 2007-08-31 04:48:00 UTC
I have noticed it is quite the pain in the butt to click on a [+] expecting a sub-category to be there, but frequently being greeted by a 'no subcategories' message.

This is fine, and definitely should be available for those who like it. It is a bit of a click-waster though. I would imagine a smarter GUI would not display a [+] if no sub-categories existed. Instead, it would render as a bullet-point or a [-].

At least something should indicate to the user that clicking on this particular option is a waste of their time.

This, however, requires additional lookups to the database. I suppose this should be done after the tree has initially been drawn or else the tree might take a while to appear. For performance reasons this should be optional and off by default. I don't believe this should be terribly expensive, especially if implemented well on the page.
Comment 1 Rob Church 2007-08-31 10:08:38 UTC
I briefly experimented with a table that kept running tallies of the number of pages and categories within each category, updated during a LinksUpdate. It seemed quite efficient, and something like it might be feasible for applications such as this, as well as accurate totals on category pages, etc.
Comment 2 Daniel Kinzler 2007-08-31 10:33:19 UTC
Yes, would be nice to have, but it's too expensive without the table Rob mentioned (which would be very cool indeed, also for other things).

So... once the required data is readily available, i'll be happy to implement this.
Comment 3 Jamie Hari 2007-09-02 15:36:42 UTC
I think that would probably also take care of Bug 1212 and would make the following a cheaper/faster query too:

http://en.wikipedia.org/wiki/Special:Categories?offset=Living_peopla

(Or does this query grep this count(*) information in a different way?)
Comment 4 Harold Solbrig 2008-01-25 15:20:45 UTC
Created attachment 4579 [details]
Proposed patch for "+" expansion

A proposed patch to address this problem.  It adds a new global, "$wgCategoryTreeLookAhead", which must be set to true in order for this patch to take effect.  There is a very slight performance hit on the select statement on line 242 of CategoryTreeFunctions.php even when lookahead is set to "false", but it isn't measurable.

If Lookahead is set to true, we do a second query to determine whether there is at least one child.
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-03-10 01:54:57 UTC
Comment on attachment 4579 [details]
Proposed patch for "+" expansion

The technique used in the patch is too slow, at least on MySQL.  It would result in a 5-second lag for [[Category:Living people]].  The scalable solution is a category table, which I'm going to add for bug 1212 anyway.  Marking obsolete, not going to be committed.
Comment 6 Brion Vibber 2008-03-24 21:32:45 UTC
Should be able to be made reasonably efficient with the new category table.

The current query is a bit ugly as it seems to sometimes hit non-categories...
Comment 7 Daniel Kinzler 2008-07-02 08:16:00 UTC
Fixed as of r36886: empty categories now show a [x] instead of a [+]. There's also an option to show the number of children along with in the tree directly.
Comment 8 Daniel Kinzler 2008-07-02 08:16:37 UTC
To clarify: this is not live on wikipedia yet, but i hope it will be soon.

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


Navigation
Links