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?

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

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.

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

In T137812#2774203, @IKhitron wrote:

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

• When at https://en.wikipedia.org/wiki/Special:CategoryTree
• You enter in Wikipedia requests related to admins which creates this:
• https://en.wikipedia.org/wiki/Special:CategoryTree?target=Wikipedia+requests+related+to+admins&mode=categories&namespaces=&title=Special%3ACategoryTree
• At that page, you want it:
  1. To hide the categories that are (empty)
     • and you have a script [link?] that will do this, but it needs [what?] changed in order to do so
  2. To default to &mode=all so that it shows pages
     • (instead of having to click the dropdown menu and reload the page, or hack the URL)
     • However, if you always use it for the same page, it might be easier to just link to the resulting URL (with &mode=on already selected) ?
  3. To auto-expand all (??) of the subcategories, so that all pages within the subcategories can be seen immediately.
     • Do you need just the 1st level of subcategories to be opened, or multiple (infinite?) levels deep?

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

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

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.

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.

In T137812#2774522, @IKhitron wrote:

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.

In T137812#2778542, @MZMcBride wrote:

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.

In T137812#2778581, @Legoktm wrote:

No, those are created by the CategoryTree extension.

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

In T137812#2778542, @MZMcBride wrote:

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.

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 ?

@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

While working on T271011, I noticed that the "mode" parameter does not seem to be working correctly on Category pages: it does affect the initial output (e.g. the little triangles turning blue and clickable for categories that only contain pages and no subcategories when mode=all is set) but the mode doesn't propagate to the dynamic calls, so when the user clicks to expand the subcategory, the default mode is used. In the case of category with no subcategories but only pages, this results in the message "nothing found". This is also the case for SpecialCategoryTree.

I suppose this has been the case for quite a while, and nobody noticed or complained. Perhaps the mode option can just be removed for category pages. For the special page, it should probably be fixed.