Page MenuHomePhabricator

Option to not display [+] if no sub-category exists
Closed, ResolvedPublic

Description

Author: webmaster

Description:
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.


Version: unspecified
Severity: enhancement

Details

Reference
bz11132

Event Timeline

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

robchur wrote:

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.

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.

webmaster wrote:

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?)

hsolbrig wrote:

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.

attachment CategoryTree.patch ignored as obsolete

ayg wrote:

Comment on attachment 4579
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.

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...

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.

To clarify: this is not live on wikipedia yet, but i hope it will be soon.