$wgCategoryTreeDynamicTag totally broken displaying no results
Closed, ResolvedPublic

Description

Nothing is returned for categories. This is a new issue, separate from the well-known caching issues in other CategoryTree bugs.

Nothing is returned whether you're logged in or out.

This page is supposed to have multiple pages listed under _each_ of the sections in it. It is currently reproducibly empty for everyone.

https://meta.wikimedia.org/wiki/Grants:PEG/Index/Requests


Version: unspecified
Severity: blocker
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61097
https://bugzilla.wikimedia.org/show_bug.cgi?id=62325

Details

Reference
bz59798
bzimport set Reference to bz59798.
bzimport added a subscriber: Unknown Object (MLST).
Ijon created this task.Jan 7 2014, 10:26 PM
greg added a comment.Jan 7 2014, 10:28 PM
  • Bug 59799 has been marked as a duplicate of this bug. ***
Ijon added a comment.Jan 7 2014, 10:31 PM

This has rendered one of our grant programs completely invisible, to our community, our grantees, and our advisory committee members. While we at WMF can navigate the raw categories and have internal listings anyway, it is seriously damaging to the grant program's ability to serve the community. Hence the 'blocker' level.

We really need a response ASAP.

greg added a comment.Jan 7 2014, 11:36 PM

fixed, thanks Reedy

Reedy added a comment.Jan 7 2014, 11:36 PM

Should be fixed now.

Seems there were some javascript related inconsistencies after we moved to a newer mediawiki version and revert back.

Ijon added a comment.Jan 8 2014, 12:22 AM

Nope, not fixed.

See https://meta.wikimedia.org/wiki/Grants:PEG/Index/Reports where pages still don't show up. Note that in the meantime, we have switched from using CategoryTree to using DynamicPageList, which seems to meet our needs, on the Requests page (linked earlier).

We will leave it like this for another 24 hours or so, to allow you to investigate if you're actively working on this. (The requests page is working, thanks to DynamicPageList, the Reports page isn't, still using CategoryTree.)

If you can't or won't work on it this week, we'll just switch the Reports page to DynamicPageList as well, and then this bug can be de-prioritized, as far as we're concerned.

Reedy added a comment.Jan 8 2014, 1:18 AM

(In reply to comment #5)

Nope, not fixed.

See https://meta.wikimedia.org/wiki/Grants:PEG/Index/Reports where pages
still
don't show up. Note that in the meantime, we have switched from using
CategoryTree to using DynamicPageList, which seems to meet our needs, on the
Requests page (linked earlier).

We will leave it like this for another 24 hours or so, to allow you to
investigate if you're actively working on this. (The requests page is
working,
thanks to DynamicPageList, the Reports page isn't, still using CategoryTree.)

If you can't or won't work on it this week, we'll just switch the Reports
page
to DynamicPageList as well, and then this bug can be de-prioritized, as far
as
we're concerned.

For future reference, changing things like that after reporting bugs without mentioning it isn't exactly helpful

Reedy added a comment.Jan 8 2014, 1:26 AM

Broken on 1.23wmf8 too.....

Reedy added a comment.Jan 8 2014, 1:55 AM

Seems to work fine locally too. Even with

"Uncaught ReferenceError: categoryTreeExpandNode is not defined"

Reedy added a comment.Jan 8 2014, 2:01 AM

Adding hideroot="on" hideprefix="on" changes it from expandnode to loadchildren error

Ijon added a comment.Jan 8 2014, 2:49 AM

Thanks, it does work now as-is (i.e. without hideroot). We're fine with DynamicPageList, I think, so let us know when you're done investigating this (assuming CategoryTree won't suddenly become maintained code again), and we'll switch this page to DPL as well.

bugzilla.wikimedia wrote:

*** Bug 59887 has been marked as a duplicate of this bug. ***

bugzilla.wikimedia wrote:

The $wgCategoryTreeDynamicTag option is not working. See https://www.mediawiki.org/wiki/Extension:CategoryTree#Configuration When the javascript was refactored to use jQuery, some of the code did not get refactored.

In CategoryTreeFunctions.php

line 447 categoryTreeLoadChildren - old function name

line 846 categoryTreeExpandNode - old function name

Test page: https://en.wikipedia.org/wiki/User:Bamyers99/sandbox/LV

  • Bug 59896 has been marked as a duplicate of this bug. ***

bugzilla.wikimedia wrote:

Here is my analysis of what happened.

On January 6, 2014, CommonSettings.php was changed here: https://git.wikimedia.org/commitdiff/operations%2Fmediawiki-config.git/4de2857061bc79128dc429f2aac6964a86c8f38a

Before the change, CommonSettings.php looked like this:
$wgCategoryTreeDynamicTag = true;
require( $IP . '/extensions/CategoryTree/CategoryTree.php' );

Currently it looks like this:
require( $IP . '/extensions/CategoryTree/CategoryTree.php' );
$wgCategoryTreeDynamicTag = true;

Before the change, setting $wgCategoryTreeDynamicTag = true had no effect because it was set before the require statement and CategoryTree.php sets it back to the default of false.

Since the $wgCategoryTreeDynamicTag feature is broken, setting it to true has caused issues.

Can we get $wgCategoryTreeDynamicTag set back to false in CommonSettings.php until this bug is fixed?

Change 107008 had a related patch set uploaded by Reedy:
Remove $wgCategoryTreeDynamicTag = true

https://gerrit.wikimedia.org/r/107008

Change 107008 merged by jenkins-bot:
Remove $wgCategoryTreeDynamicTag = true

https://gerrit.wikimedia.org/r/107008

bamyers99: Thanks for your comment and investigation, this was very helpful!

https://gerrit.wikimedia.org/r/#/c/107008/ has been merged - closing as FIXED.

extensions/CategoryTree/CategoryTreeFunctions.php has this piece of code:

if ( $parser && $wgCategoryTreeDisableCache && !$wgCategoryTreeDynamicTag ) {
        $parser->disableCache();
}

(with $wgCategoryTreeDisableCache having a value of true, its default)

bugzilla.wikimedia wrote:

Sorry, I did not see this commit:
https://git.wikimedia.org/commitdiff/operations%2Fmediawiki-config.git/670fe932d04b948c1aa73033a00a722fc0269c9e

I thought that $wgCategoryTreeDisableCache = false;
was still in CommonSettings.php.

Reedy added a comment.Jan 13 2014, 6:39 PM

[17:08:10] <Reedy> I'm confused how CategoryTree didn't cause problems before
[17:08:11] <Reedy> https://github.com/wikimedia/operations-mediawiki-config/commit/4de2857061bc79128dc429f2aac6964a86c8f38a
[17:08:26] <Reedy> $wgCategoryTreeDynamicTag was set before the require
[17:08:32] <Reedy> So it wouldn't have had any effect at all
[17:08:48] <Reedy> I "fixed" that, which apparently broke some configurations
[17:09:01] <Reedy> But then removing it (so it was the same as original) and it causes major problems?

karmela.wikipedia wrote:

At hu.wiki the empty categorytree has been noticed too. Our mentor-system depends on it. Do we need to develop a workaround, or will the bug be fixed soon? ~~~~

bugzilla.wikimedia wrote:

I have implemented a workaround at https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Geographical_coordinates/to_do#Fix

Example:
<categorytree class="toccolours" namespaces="- Talk" style="margin:0 1ex;">Articles requiring geodata verification</categorytree>
:{{PAGESINCATEGORY:Articles requiring geodata verification|pages}} pages

We're in id.wp also noticed this, and we're going to watch this progress too. Fortunately no major damage is done.

Hi, I've made a use case in https://id.wiktionary.org/wiki/Pengguna:Bennylin/Categorytree, because id.wikt relies heavily on CategoryTree to display phrases that uses the lemma.

Any update on this bug?

Greg: Do you know if somebody in Engineering has expertise to give fixing this ticket another shot?

Spage added a comment.Feb 9 2014, 9:38 AM

renderNode() in CategoryTreeFunctions.php may insert a <script> tag that calls categoryTreeExpandNode(). See
https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FCategoryTree/05bafcafdbd3e5b959dba593b8656c24ef0d4a54/CategoryTreeFunctions.php#L846

but as Reedy notes there's no such function. categoryTreeExpandNode and categoryTreeLoadChildren used to be defined in CategoryTree.js, but that file was deleted in 2011.

This is indirectly causing a problem with Flow, see bug 61097. Flow can somehow render subst'd page content with this script tag and then JS processing halts with

ReferenceError: categoryTreeExpandNode is not defined

FWIW Flow boards don't load the JS module 'ext.categoryTree'. Maybe when that module is loaded it masks the problem. But it can't be good to invoke deleted functions :)

Change 114142 had a related patch set uploaded by Brian Wolff:
Unbreak this extension by killing $wgCategoryTreeDynamicTag

https://gerrit.wikimedia.org/r/114142

greg added a comment.Feb 19 2014, 10:31 PM

S: Can the Flow team take this on as a "help other parts of the ecosystem and also Flow at the same time" task? Or is Brian's "just kill it" solution acceptable?

(In reply to Greg Grossmeier from comment #32)

S: Can the Flow team take this on as a "help other parts of the ecosystem
and also Flow at the same time" task? Or is Brian's "just kill it" solution
acceptable?

To be clear, my solution doesnt actually remove any functionality, it just loads things statically in the page, instead of dynamically by ajax (for the first level, other levels still dynamic). This has some affect on how long cache works (so possibly stale entries, but only up to 6 hours), but ive been hearing rumours that the ajax response is also getting cached longer than expected (unconformed, might be totally untrue), so this solutiion might not even cause (new) problems in that regard.

Change 114142 merged by jenkins-bot:
Unbreak this extension by killing $wgCategoryTreeDynamicTag

https://gerrit.wikimedia.org/r/114142

(In reply to Gerrit Notification Bot from comment #34)

Change 114142 merged by jenkins-bot:
Unbreak this extension by killing $wgCategoryTreeDynamicTag

https://gerrit.wikimedia.org/r/114142

Is this bug fixed, then?

Yes, fixed and deployed.

If someone really wanted to they could still rewrite the old code to load entirely dynamically, but if anyone actually wants that they can file another bug.

Add Comment