Created attachment 9917
Image showing test as a subcat, showing any pages when selected and expanded

Attached:

Created attachment 9918
Image showing test at top level, showing pages fine

Attached:

Created attachment 9919
And shown on 1.18wmf1

Attached:

i'll have a look now, but I can't spend a lot of time on this. According to svn blame, the interesting bits have been rewritten by siebrand and tstarling. And the change by johnduhart Sam mentioned is pretty massive, too. Not sure I understand the code any more :)

in my test, the page always made requests that had json looking like:
{"mode":0,"hideprefix":20,"showcount":true,"namespaces":false}

regardless of what mode was selected, so probably something with the js not reading the select dropdown properly.

Yes, I foudn the same thing:

mode is 0, which means "categories only". So no regular pages are
returned.

The code that generates the link that is used to expand the node was all
jquery-fied, and I wan't able to dig into it yet. Will looks some more later.

However, this has nothing to do with the dropdown - the dropdown only exists on Special:CategoryTree, but the JS code has to work also on category pages and any wiki page that embeds a category tree inline.

Basically: whatever code generates the parameters to be used in the ajax call for
retrieving the categories content must use the mode that was used to generate the parent node. When I first wrote this, the code that generated the HTML(!) that represents a category's content would include the HTML code for the expand bullets, which contained the javascript function call that would retrieve the node's content with the appropriate parameters (that is, the same mode, etc, used to generate the present output).

If the node's content is now returned as json, not html (as I think it is, if I understd the new code correctly), that json has to contain the full option set to be used to retrieve the content of further sub-categories. I suspect that this is not the case.

So, it's somehow related to ctOptions on the parent tag not being what they should be.

At some point, the PHP code generates a first, static, category tree node. ctOptions would have to be set on the HTML for that static node somehow by the PHP code, so it can be picked up from jQuery later, to be used when loading further (sub)nodes. I couldn't find any PHP code that does this. In stead, it seems that the jQuery code always falls back to mw.config.get( 'wgCategoryTreePageCategoryOptions' ) (line 93 in ext.categoryTree.js).

My impression is that johnduhart's work to make CategoryTree use jQuery is incomplete in that respect. I don't know jQuery or the resource loader framework well enough to really find out how exactly.

So, I give up and assign the bug to the list.

Generally: action=ajax should be deprecated and CategoryTree should be rewritten using the API.

We think this was introduced in r98500. That had a fixme on it, but was converted back to new, I think for unrelated reasons. John, what's the status on this? Do you need help getting this one figured out?

It seems reverting back to r98499 isn't enough, it seems to break other parts of it (which isn't actually unexpected with all the JS overhauling)...

Will give a look at that extension Monday under my 20% time. Will try to fix the PHP part / migrate to API usage if that is possible.

bsitu wrote:

fixed in r111218

(In reply to comment #11)

fixed in r111218

Aha! Nice one Benny.

Confirmed fixed :)

yay! 20% time success!

That was fast :-)