Wikimedia Bugzilla is closed!

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

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.

fixed, thanks Reedy

Should be fixed now.

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

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.

(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

Broken on 1.23wmf8 too.....

Seems to work fine locally too. Even with

"Uncaught ReferenceError: categoryTreeExpandNode is not defined"

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

https://meta.wikimedia.org/w/index.php?title=Grants%3APEG%2FIndex%2FReports&diff=6992040&oldid=6770087

It's still throwing errors, but it works too...

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.

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

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

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.

Reverted: https://gerrit.wikimedia.org/r/#/c/107158/

https://gerrit.wikimedia.org/r/#/c/107008/ was emergency reverted by Mark moments ago (2014-01-13 15:12 UTC). It produced a massive poolcounter contention, as well as database contention on s6, causing jawiki & ruwiki to spew errors for many hours yesterday and for the most part today.

https://graphite.wikimedia.org/render/?title=PoolCounter%20Client%20Average%20Latency%20%28ms%29%20log%282%29%20-1week&from=-1week&width=1024&height=500&until=now&areaMode=none&hideLegend=false&logBase=2&lineWidth=1&lineMode=connected&target=cactiStyle%28MediaWiki.PoolCounter.Client.*.tavg%29

&

http://ganglia.wikimedia.org/latest/?c=MySQL%20eqiad&h=db1006.eqiad.wmnet&m=cpu_report&r=hour&s=descending&hc=4&mc=2

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

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

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

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.

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

For the records, the empty categorytree has been noticed at it.wiki too. https://it.wikipedia.org/w/index.php?title=Aiuto:Sportello_informazioni&oldid=63532785#Problema_con_il_categorytree_per_le_segnalazioni_automatiche_ai_progetti

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

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?

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

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.