$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

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz59798.
Ijon created this task.Via LegacyJan 7 2014, 10:26 PM
greg added a comment.Via ConduitJan 7 2014, 10:28 PM
  • Bug 59799 has been marked as a duplicate of this bug. ***
Ijon added a comment.Via ConduitJan 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.Via ConduitJan 7 2014, 11:36 PM

fixed, thanks Reedy

Reedy added a comment.Via ConduitJan 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.Via ConduitJan 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.Via ConduitJan 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.Via ConduitJan 8 2014, 1:26 AM

Broken on 1.23wmf8 too.....

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

Seems to work fine locally too. Even with

"Uncaught ReferenceError: categoryTreeExpandNode is not defined"

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

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

Ijon added a comment.Via ConduitJan 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.

bzimport added a comment.Via ConduitJan 11 2014, 2:56 PM

bugzilla.wikimedia wrote:

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

bzimport added a comment.Via ConduitJan 11 2014, 3:11 PM

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

duplicatebug added a comment.Via ConduitJan 11 2014, 8:00 PM
  • Bug 59896 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitJan 11 2014, 11:05 PM

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?

gerritbot added a comment.Via ConduitJan 12 2014, 12:01 AM

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

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

gerritbot added a comment.Via ConduitJan 12 2014, 12:03 AM

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

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

Aklapper added a comment.Via ConduitJan 13 2014, 10:21 AM

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

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

faidon added a comment.Via ConduitJan 13 2014, 3:39 PM

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

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

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

bzimport added a comment.Via ConduitJan 13 2014, 4:04 PM

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.Via ConduitJan 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?

bzimport added a comment.Via ConduitJan 20 2014, 3:10 PM

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? ~~~~

bzimport added a comment.Via ConduitJan 20 2014, 4:13 PM

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

Bennylin added a comment.Via ConduitJan 22 2014, 9:05 AM

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

Bennylin added a comment.Via ConduitFeb 4 2014, 6:52 PM

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?

Aklapper added a comment.Via ConduitFeb 5 2014, 3:16 PM

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

Spage added a comment.Via ConduitFeb 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 :)

gerritbot added a comment.Via ConduitFeb 19 2014, 12:15 PM

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.Via ConduitFeb 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?

Bawolff added a comment.Via ConduitFeb 19 2014, 11:26 PM

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

gerritbot added a comment.Via ConduitFeb 20 2014, 1:15 AM

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

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

MZMcBride added a comment.Via ConduitMar 3 2014, 5:18 PM

(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?

Bawolff added a comment.Via ConduitMar 3 2014, 5:46 PM

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