Extension talk:CategoryTree

Jump to: navigation, search

About this board


1 (2006/2007) - 2 (2008) - 3 (2009) - 4 (2010) - 5 (2011) (talkcontribs)

Is it possible to suppress the "Nothing Found" text displayed when a category doesn't have any sub-categories or articles (other than the main category article)? If so, could somebody point me in the right direction? Thanks...

Reply to "Suppress "nothing found" message?"
Benkhe (talkcontribs)

hi,I want to show a categorytree like this:

1 level

1.1 level

1.2 level

2 level

2.1 level

so,I input like this:

<categorytree mode=parents>1 level</categorytree>

<categorytree>1.1 level</categorytree>

<categorytree>1.2 level</categorytree>

<categorytree mode=parents>2 level</categorytree>

<categorytree>2.1 level</categorytree>

but , obviously, it's wrong, so could you pls give me the solution.THANK YOU!

Reply to "syntax about categorytree"
Heinrich krebs (talkcontribs)


when I unfold an entry, the tag appears

<span style="color:#0645AD;">►</span>

and it doesn't disappear, even if I fold the entry again.

Any thoughts on removing this behaviour.

Best regards,


Reply to "Tag appears when unfolding a category"
Marccreal (talkcontribs)

Sorry if this is a dumb question, but I do not find any possibility to display the whole category-tree of a wiki (not just all subcategories of a certain category). Is that possible?

Ciencia Al Poder (talkcontribs)

No, unless all categories have a parent category (except that parent category itself), in which case you can use that parent category and everything else will go below that. Of course you'll need to interact with the tree so it loads subcategories by clicking on them. Displaying the tree at once is probably not doable because there may be loops in the tree. (talkcontribs)

@Marcreal: this is possible in MW 1.27 and corresponding extension version if you use root category of the tree. Any higher version of MW and CategoryTree extension is messed up. I have no idea if it is due to core changes or extension. It messes up the trees on en:WP as well but either they did not notice or do not care.

Reply to "Display all categories"

submenus sometimes hidden, sometimes not

Hboetes (talkcontribs)

I tried with various browsers on various operating systems and the subtree sometimes shows up and sometimes does not. I can't pinpoint what exactly causes the change in behaviour. I downloaded and diffed the html from the same page on a browser where I got to see submenus and one where I didn't and... there is no difference, apart from the random hashes. I suspect the javascipt is not being accepted. In the dev-console I got these error messages:

jquery.treeview.js?303:256 Uncaught ReferenceError: jQuery is not defined at jquery.treeview.js?303:256

(anonymous) @ jquery.treeview.js?303:256

SelectCategory.js?303:1 Uncaught ReferenceError: $j is not defined at SelectCategory.js?303:1

(anonymous) @ SelectCategory.js?303:1

I hope someone can fix this.

Ken Roy (talkcontribs)
See Thread:Extension talk:CategoryTree/Fix to make CategoryTree working in sidebar again with MW 1.24.1 and Vector skin
which fixed my problem of using the CategoryTree in the sidebar
Hboetes (talkcontribs)

Hi Ken,

thanks for your answer, I tried it on my release but it didn't help. I think I'll wait for a proper fix released by the people who control the repo.

Reply to "submenus sometimes hidden, sometimes not"

Fix for making CategoryTree work in sidebar again with MW 1.24.1 and Vector skin

Bhuber (talkcontribs)

Hi all, I used to offer a CategoryTree in my MediaWiki sidebar with MW 1.20.4. Everything worked well, but since my update to MW 1.24.1 all appropriate releases of CategoryTree stopped working in the sidebar. This includes the REL1_24 version but also the development master version. The problem is, that the expandable symbols are not shown at all and no click handle is registered. Interestingly CategoryTree works perfect as part of a WikiPage in parallel to not work at all in the sidebar.

I figured out that the way how the ext.CategoryTree.js works is that it uses a mw.hook to access the WikiPage content and to make CategoryTree working there. But obviously the sidebar is not part of the content which is access by this approach. I tested it by just removing the whole content in the ext.CategoryTree.js and literally just the inner section of my page disappeared but the sidebar was still there together with some other navigation content. So I am looking for a fix to have ext.CategroyTree.js to access the whole content including the sidebar.

I am no MediaWiki nor js nor php specialist, but after looking into the vector skin, I figured out how the skin accesses the whole content. I decided to give this appraoch a try, so I modified the beginning of ext.CategoryTree.js (which is located in extensions/CategoryTree/modules by the way) to make it look like this:

//( function ( $, mw ) {
//   mw.hook( 'wikipage.content' ).add( function ( $content ) {
jQuery( function ( $ ) {
                * Sets display inline to tree toggle
               function showToggles() {

and the end of ext.CategoryTree.js to look like this;

        // Register click events and show toggle buttons
        $( '.CategoryTreeToggle' ).click( handleNode );
   } );
//}( jQuery, mediaWiki ) );

From my understanding this gives the ext.CategoryTree.js access to the whole page content. So good news is, that everything works well after this modification, CategoryTree in the sidebar works like expected.

So now I have a question to all MediaWiki specialists: is this a valid approach to solve the problem? Or does it cause tremendous load to the system or break system concepts?

David6243 (talkcontribs)

I think a crucial change is missing from the js code you posted, something like:

jQuery( function ( $ ) { var $fullcontent = $(this);

And later, access fullcontent instead of content, e.g.

function showToggles() { $fullcontent.find( 'span.CategoryTreeToggle' ).css( 'display', 'inline' ); }

Anyway, the hints about the sidebar not being part of the content and looking at vector.js for reference were very helpful to me, and I can now show a category tree anywhere in the skin. Thanks!

As for your question: Don't know. I haven't noticed any problems.

Also, sorry about editing the subject of your post. Initially, I couldn't respond because of this:

This page can only be edited by users with the autoconfirmed right because it matches the following title blacklist entry: .*Make.*cat.* autoconfirmed

By now, my account is confirmed. Changing the subject hadn't helped either.

Bhuber (talkcontribs)


you are absolutely right, for some weird reason I missed to add two really important changes...

Generally speaking, you want to replace any use of the term $content.find by a single $, which refers to the whole DOM from my understanding. This needs to happen two time in the ext.categoryTree.js:

               function showToggles() {
                       $content.find( 'span.CategoryTreeToggle' ).css( 'display', 'inline' );

needs to be modified to look like this:

               function showToggles() {
                       $( 'span.CategoryTreeToggle' ).css( 'display', 'inline' );


               // Register click events and show toggle buttons
               $content.find( '.CategoryTreeToggle' ).click( handleNode );

needs to be modified to look like this:

               // Register click events and show toggle buttons
               $( '.CategoryTreeToggle' ).click( handleNode );

So there is absolutely no need to search or build another $content var, obviously you can work on the whole DOM like the skin sample does.

PS: There is absolutely no need to excuse for making my post usable to you and others by doing whatever is required...

Ken Roy (talkcontribs)
Thanks for providing this fix, which now allows the portlet to work correctly in the sidebar
Wonder how long it will take to get incorporated in the CategoryTree extension, since even 1.29 is still broken and their troubleshooting hints do not work. (talkcontribs)

Brilliant !! Many Thanks !

Reply to "Fix for making CategoryTree work in sidebar again with MW 1.24.1 and Vector skin" (talkcontribs)

When I use parents mode, the depth value doesn't seem to do anything-- my parent trees always render with a depth of 2, even when set to 4:

  | mode=parents
  | depth=4

How can I fix this?

Reply to "depth value in parents mode?"

$wgCategoryTreeMaxChildren don't show more than 200

Guindelo (talkcontribs)


I've a problem using $wgCategoryTreeMaxChildren, in my Localsettings i put a line wiith the number of pages to show $wgCategoryTreeMaxChildren= 400; but the categorytree only show's 200,

Any suggestions?



Reply to "$wgCategoryTreeMaxChildren don't show more than 200"

Setting $wgCategoryTreeMaxDepth doesn't work as expected

Summary by Ciencia Al Poder
Darek07 (talkcontribs)

I just found it that when I put in LocalSettings.php:

$wgCategoryTreeMaxDepth = array(CT_MODE_PAGES => 6, CT_MODE_ALL => 6, CT_MODE_CATEGORIES => 6);

and then on wiki

<categorytree mode=categories depth=4>Manual</categorytree>

it won't do any effects while setting it this way:

$wgCategoryTreeMaxDepth = 6;

will work! I'm using:

  • CategoryTree: master 2017-08-07T21:02:18 5474152
  • MediaWiki 1.30.0-alpha (26b883a)
  • PHP 7.0.21 (apache2handler)
  • MariaDB 5.5.52-MariaDB
  • ICU 50.1.2
Ciencia Al Poder (talkcontribs)

The code is checking if it's an array appropriately. Maybe in the new extension registration system the constants aren't accessible in LocalSettings.php yet?

define( 'CT_MODE_CATEGORIES', 0 );
define( 'CT_MODE_PAGES', 10 );
define( 'CT_MODE_ALL', 20 );
define( 'CT_MODE_PARENTS', 100 );

Try to use the constant values instead of the constant names, in case this is the problem.

Ciencia Al Poder (talkcontribs)

This is indeed the cause, as reported in task T152294

Reply to "Setting $wgCategoryTreeMaxDepth doesn't work as expected"

problem while loading data

Summary by Ciencia Al Poder

Extension:LockDown can cause issues when $wgGroupPermissions['*']['read'] = false;

Paul Hema (talkcontribs)

Moin moin.

The CategoryTree didn't find any subcategories. I hope the following image will show the problem:

While clicking "Erosion durch Wasser" (see the image) the correct pages an the subcategory appears.


Tacsipacsi (talkcontribs)

On which wiki did this occur? Is it persistent (have you tried it again as it told)?

Paul Hema (talkcontribs)


There are no changes when reloaded

Tacsipacsi (talkcontribs)

I meant can you give a URL for debugging?

Paul Hema (talkcontribs)

no sorry. It's under construction yet.

The CategoryTree version is

Paul Hema (talkcontribs)

I have updated the wiki from version 1.24. Maybe there is an old stuff of the previous version?

Tacsipacsi (talkcontribs)

Then please check your browser console. It can usually be accessed with the F12 key and/or Ctrl+Shift+I (if you can't find it, write me what browser you use and I try to find it out).

Tacsipacsi (talkcontribs)

If it's under construction, can't you delete the whole wiki and install the most recent versions with a clean installation?

Paul Hema (talkcontribs)
{"error":{"code":"readapidenied","info":"You need read permission to use this module","docref":"See https://fbs01/MethodenWiki/api.php for API usage"}}

The given link throws a 500 error.

Paul Hema (talkcontribs)

Oops. Here is the cmd answer:

What's wrong?

Tacsipacsi (talkcontribs)

The web error message says that you don't have read permission through the API (while you obviously have through the normal HTML interface). This can be somehow CategoryTree's code error if your wiki's private (i.e. anonymous users can't read pages). It was designed for Wikipedia, where read access is not a problem. The command line error is OK, api.php isn't designed for command line access (it wants to access $_SERVER which I think is an empty array or something like that). For development, you can set $wgShowExceptionDetails = true; in LocalSettings.php (it's not recommended for production use!), although it won't produce any error message in this case, since it's not an error in PHP level.

Paul Hema (talkcontribs)

Ok, it is a private wiki. So it can be a code error in CategoryTree. I think i have to live with this problem.


Tacsipacsi (talkcontribs)

No, the developers should fix it. I reported here.

Ciencia Al Poder (talkcontribs)

Maybe you're using Extension:LockDown? (would be a dupe of task T148582 in that case)

Paul Hema (talkcontribs)

Yes :-(

The problem is the restriction with

$wgGroupPermissions['*']['read'] = false;