Page MenuHomePhabricator

Add preferences ability to view categorytree with "all" mode.
Open, Needs TriagePublic

Description

  • Currently it is possible to navigate to category and append ?mode=X (where X is the categorytree mode)
  • As URL hacking is inconvenient, please add an ability to choose in preferences between CT_MODE_CATEGORIES and CT_MODE_ALL, for users that prefer this kind of view.

Details:
Hello. When you open a category, you see its subcategories, but they can't be extended by triangle button to see their content, only subcategories. It is very unconvinient to work this way in the last couple of weeks, after this change was made in our wiki (T132972). Please add an ability to choose in preferences between CT_MODE_CATEGORIES and CT_MODE_ALL, for users that prefer this kind of view.
Thank you.

Event Timeline

IKhitron created this task.Jun 14 2016, 3:24 PM
Restricted Application added a subscriber: Zppix. · View Herald TranscriptJun 14 2016, 3:24 PM
Arseny1992 added a subscriber: Arseny1992.EditedNov 5 2016, 1:09 AM

There's a difference between viewing subcategories and pages outright on the category page itself (the default is indeed to expand only subcategories) and viewing the subcategories via the category view link that goes to Special:CategoryTree/desiredcategory that shows also included pages when the All pages viewing mode is selected on the same page.

Is this request would be still relevant as no one else seem to be affected by this or not care about a preferences option?

Arseny1992 assigned this task to TheDJ.Nov 5 2016, 2:48 AM

Default is to show only categories. Per ^ a preferences option is wanted for user own override from site default option so that the user won't have to select view mode on Special:CategoryTree every time you open that special page.

This is not a Wikimedia-Site-request, but a general request for any mediawiki site with CategoryTree extension.

  • Currently it is possible to navigate to category and append ?mode=X (where X is the categorytree mode)
  • The request ask to enable this setting from user preferences rather then by URL hack
eranroz updated the task description. (Show Details)Nov 5 2016, 5:59 AM

A user preference here seems like poor design.

Are there links to examples where this feature would be useful? I'm wondering whether we can add markup to let category tree default behavior be more explicit for all users.

Arseny1992 removed TheDJ as the assignee of this task.Nov 5 2016, 8:47 PM
Arseny1992 added a subscriber: TheDJ.
eranroz added a comment.EditedNov 5 2016, 9:46 PM

@MZMcBride , good point. The user preferences is quite complex and we should avoid making it even more complex :)
I think @IKhitron use different category modes for some maintenance categories.

Unfortunately, you are right. I can't think about another example when somebody will need this at all except my own one - I need it as dom for javascript. If there was, for example, some different invisible css class for "0 pages", I wouldn't ask.

If there was, for example, some different invisible css class for "0 pages", I wouldn't ask.

I'm not sure what you're asking for. We obviously control the HTML output of the CategoryTree extension and can modify it as warranted. :-)

Is there a link to the use-case you're describing? I keep scanning this task looking for a link to a demonstration or example of the problem. I'm trying to better understand the context here.

Ok, I'll describe you one possible example. We have a category that includes 51 sub-categories, each of them is a tracking category for immediately need to fix. There is a very simple script that hides dom elements with empty categories. So we can see only those that need to be fixed now. But js need an ability to know which category is empty. The script also used by some users for all category pages they open, because it's better for them.

@IKhitron Please could you link to exactly the page you are using now (or an English equivalent), and then also describe what bits of it you want to display differently? A step-by-step breakdown of the problem, and then a step-by-step explanation of your suggestion of one possible way to resolve it.

It has been hard to understand what you're trying to do, because we can't see what exact pages/examples you're talking about. Hence the 2 (now 3!) requests for an exact link. That will help everyone to understand the problem you're trying to solve, and thus potentially think of unique solutions, instead of just implementing the solution you suggest.

E.g. I think you're asking for this (Enwiki equivalent):


If you only need this for a single instance (the same category every time), there's a possible solution using the <categorytree> tag in a page and a userscript/gadget. E.g.

  • I've put <categorytree mode=all hideroot=on showcount=on>User interface</categorytree> in a sandbox
  • I've put $(window).load(function() { $('.CategoryTreeToggle').click(); }); in my global.js
    • This code will autoclick the first level of triangle buttons.
    • However it does not work with multiple levels of category. (test with mode=categories and depth=2).
    • It also requires hideroot=on, otherwise the first level (which initially loads in 'expanded view') gets collapsed.
    • Drawback: this creates the major problem that the script will affect the categorytree triangle buttons at all pages across the wiki(s). Whereas you (probably) want to limit it to just the 1 page.
    • Drawback: this would only work for one person (or whoever copied the script, or used it as a gadget).

This is all just to demonstrate that other solutions are possible, once we more clearly understand what you are trying to accomplish. :-)

Not at all, @Quiddity. I'm impressed of your answer, but it's wrong from the first line. So I did not read the rest. I never spoke about category tree, but about regular category page. You asked about a link - any category in any wiki will fit.

@IKhitron: So please provide a specific link to "any category in any wiki".

IKhitron added a comment.EditedNov 7 2016, 10:56 AM

Here you are: the first one in enwiki search autocomplete:
here.

TheDJ added a comment.EditedNov 7 2016, 11:22 AM

Right, so to summarize:

The default behavior is that on Category pages, when a subcategory has no subcategory of it's own, the category tree disclosure triangle does not allow you to expand the category and show it's sub-articles and/or files. It is only expandable if it has subcategories of its' own.

You find this inconvenient and would either like to change it, or to have a user option to change this, or a specific hook that would allow you to create a gadget or user script to modify this behavior.

A suggestion is that an indication in the HTML that the subcategory is 'empty' (not sure what empty means in this context, totally empty, empty of subcategories or empty of pages and or files ?) would be enough to build your own script to handle this ?

Are we getting closer now ?

Thank you, @TheDJ, absolutely. And empty means nothing at all - no pages, no files, no subcategories.
Indeed, I ask for ability that js will know that the category is empty. It could be triangle, or some css class for empty word, or anything. Thanks again.

Arseny1992 added a comment.EditedNov 7 2016, 11:47 AM

So to summarize, @IKhitron wants to user-override the categorytree expanders (mode=all) while browsing a category page (on the page, and not the special page, although it has the same default behavior) without setting it (mode=all) as site default for all users on the wiki while the default is mode=categories , without having to URLhack the page every time. Normal browsing case across categories.

Ok, I'll describe you one possible example. We have a category that includes 51 sub-categories, each of them is a tracking category for immediately need to fix. There is a very simple script that hides dom elements with empty categories. So we can see only those that need to be fixed now. But js need an ability to know which category is empty. The script also used by some users for all category pages they open, because it's better for them.

Breaking that down:

  • Category 1 is some root category.
  • Contains 51 subcategories.
  • Some of those subcategories have some number of pages. Some of the categories are empty. Or do contain even more subcategories with even more pages or are empty or are not empty some levels deep.

User script or gadget is used to hide the DOM elements for categories that are shown as empty (0 pages). And does not run if category is detected as not empty. So only the maintenance categories that are not empty but contain subcategories or pages or both are displayed.

Since the site-wide default is mode=categories this no longer works as expected because normal browsing shows only subcategories without included pages, and would require the user to URLhack the pages to mode=all on each page navigate if he browses several (or even all) category pages. Even if the category does contain pages, the expander display the empty category element because the default is to expect a subcategory to exist, not a page or file.

That's why a userpref, or a hook etc, is proposed.

Edit:
Uh. Already summed up.

I think a lot of the confusion here is coming from the fact that Wikimedia wikis have a MediaWiki extension called "CategoryTree" installed. That extension may not be related to this task.

People are using "category tree" in a generic sense. The subcategories with the triangles at https://en.wikipedia.org/wiki/Category:Redirects_from_alternative_spellings#mw-subcategories are completely unrelated to the CategoryTree extension, as far as I know.

The CategoryTree extension may have behavior outside of its parser function and the Special:CategoryTree page, though this point remains unclear. I still do not understand what ?mode= in the task description is referring to. https://en.wikipedia.org/wiki/Category:Redirects_from_alternative_spellings?mode=CT_MODE_ALL doesn't do anything different for me.

Legoktm added a subscriber: Legoktm.Nov 8 2016, 2:17 AM

People are using "category tree" in a generic sense. The subcategories with the triangles at https://en.wikipedia.org/wiki/Category:Redirects_from_alternative_spellings#mw-subcategories are completely unrelated to the CategoryTree extension, as far as I know.

No, those are created by the CategoryTree extension.

No, those are created by the CategoryTree extension.

Oh, right. The subcategories themselves come from MediaWiki core. The extension adds the triangles and expandability.

Arseny1992 added a comment.EditedNov 8 2016, 5:10 AM

The CategoryTree extension may have behavior outside of its parser function and the Special:CategoryTree page, though this point remains unclear. I still do not understand what ?mode= in the task description is referring to. https://en.wikipedia.org/wiki/Category:Redirects_from_alternative_spellings?mode=CT_MODE_ALL doesn't do anything different for me.

https://en.wikipedia.org/wiki/Category:Redirects_from_alternative_spellings?mode=all

While the site-wide default, when not having the switch or any other params appended to each category page navigate request, equivalents to https://en.wikipedia.org/wiki/Category:Redirects_from_alternative_spellings?mode=categories

The userpref or sript/gadget hook for "empty category" is wanted to avoid setting mode=all or mode=pages as site-wide default , as it previously was in years, since some hewiki users got used to that special site-wide default done in T13776 and reverted in T132972 and so wish to continue working with T13776 's behavior.

TheDJ added a comment.Nov 8 2016, 8:06 AM

Why didn't we just flip the showcount flag in T132972, and left the mode in place ?

CategoryTreeCategoryPageOptions' => [
	'default' => [ 'mode' => null, 'showcount' => true ],
	'hewiki' => [ 'mode' => 10 /*CT_MODE_PAGES*/, 'showcount' => true ],
]

Seems like it would have been a whole lot less controversial ?

Arseny1992 added a comment.EditedNov 8 2016, 8:26 AM

@TheDJ because the initial point of T132972 was to revert this site-wide special default behavior. If we're going to revert this back to T13776 's way, then it'll be as if T132972 didn't happen.

Since this is the default behavior now in all wikis hewiki would like to behave the same way...

However some hewiki users been used to in years to that special site-wide default that is not consistent with other wikis. So it's wanted to have ways to user-override this to whatever categorytree configuration the user wants (so all, pages, 10 etc) without touching that for the entire site for all users including anons, as otherwise its inconsistent with the other 900 wikis.

Flipping showcount to false will hide counts and so that's not desired