Last modified: 2012-05-03 02:45:57 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 33989 - Trunk CategoryTree doesn't list pages of sub categories
Trunk CategoryTree doesn't list pages of sub categories
Product: MediaWiki extensions
Classification: Unclassified
CategoryTree (Other open bugs)
All All
: High normal (vote)
: MW 1.19 version
Assigned To: Antoine "hashar" Musso (WMF)
: javascript
Depends on:
Blocks: 31217
  Show dependency treegraph
Reported: 2012-01-27 15:33 UTC by Sam Reed (reedy)
Modified: 2012-05-03 02:45 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Image showing test as a subcat, showing any pages when selected and expanded (22.36 KB, image/png)
2012-01-27 15:36 UTC, Sam Reed (reedy)
Image showing test at top level, showing pages fine (14.86 KB, image/png)
2012-01-27 15:36 UTC, Sam Reed (reedy)
And shown on 1.18wmf1 (45.51 KB, image/png)
2012-01-27 15:37 UTC, Sam Reed (reedy)

Description Sam Reed (reedy) 2012-01-27 15:33:05 UTC
May be related to r98563

Will upload some screenshots
Comment 1 Sam Reed (reedy) 2012-01-27 15:36:14 UTC
Created attachment 9917 [details]
Image showing test as a subcat, showing any pages when selected and expanded
Comment 2 Sam Reed (reedy) 2012-01-27 15:36:43 UTC
Created attachment 9918 [details]
Image showing test at top level, showing pages fine
Comment 3 Sam Reed (reedy) 2012-01-27 15:37:22 UTC
Created attachment 9919 [details]
And shown on 1.18wmf1
Comment 4 Daniel Kinzler 2012-02-07 09:58:39 UTC
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 :)
Comment 5 Bawolff (Brian Wolff) 2012-02-07 10:05:06 UTC
in my test, the page always made requests that had json looking like:

regardless of what mode was selected, so probably something with the js not reading the select dropdown properly.
Comment 6 Daniel Kinzler 2012-02-07 10:46:52 UTC
Yes, I foudn the same thing:

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

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.
Comment 7 Daniel Kinzler 2012-02-07 11:33:36 UTC
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.
Comment 8 Rob Lanphier 2012-02-10 00:33:21 UTC
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?
Comment 9 Sam Reed (reedy) 2012-02-10 01:28:52 UTC
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)...
Comment 10 Antoine "hashar" Musso (WMF) 2012-02-10 18:04:59 UTC
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.
Comment 11 bsitu 2012-02-10 23:54:47 UTC
fixed in r111218
Comment 12 Sam Reed (reedy) 2012-02-11 00:09:52 UTC
(In reply to comment #11)
> fixed in r111218

Aha! Nice one Benny.

Confirmed fixed :)
Comment 13 Mark A. Hershberger 2012-02-11 02:25:07 UTC
yay! 20% time success!
Comment 14 Antoine "hashar" Musso (WMF) 2012-02-11 09:56:50 UTC
That was fast :-)

Note You need to log in before you can comment on or make changes to this bug.