Closed Bug 858844 Opened 11 years ago Closed 10 years ago

Sortable tables on wiki no longer sortable

Categories

(Websites :: wiki.mozilla.org, defect)

Product:
Websites
Component:
wiki.mozilla.org
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
2014-Q2

People

(Reporter: davidwboswell, Assigned: nmaul)

References

Details

(Keywords: regression) 

I noticed that a sortable table that had been working on the wiki is no longer sortable after the recent wiki updates.

In particular, the table at the following link had been sorted and isn't now and is still set as class="wikitable sortable".

https://wiki.mozilla.org/Contribute/Funnels#By_Locale
Keywords: regression
In the js console: mw.loader::execute> Exception thrown by jquery.tablesorter: $.escapeRE is not a function
From wikimedia:

"This was fixed in master and released in 1.20.0.

Pushed a backport to 1.19 LTS for review."
This used to work fine on wiki.mo, but an update months ago must have broke this. Do we need to upgrade wiki.mo?
I have a big table with many languages. It's really important that the sorting function works.
Looks like it's included starting at MW 1.19.8 and wikimo is on 1.19.7. Who can upgrade?
I can do help with this, but I believe have a point release coming out in a couple of weeks and I'd like to do it then.
If someone could help us, we're preparing a point release with some security for 2014/01/13 and would like to deploy this here.  Could someone who has power to deploy contact myself?
I have added Alison to this for her approvel as she is in charge of the wiki project now
Flags: needinfo?(tech)
Jason: "You are not authorized to access bug #957319. " - Could you add me so that I can see the dependence tree please.

On the general point we MediaWiki version, yes we are very behind and there have been a number of bugs raised over the last year asking for features or bugfixes which we could get by upgrading. Each time though, as I recall, questions have been raised over the availability / capability / accessibility of people able to access the particular systems which need to be upgraded, there being multiple front and back-ends in the wiki.m.o case as I understand? 

Unlike when I want to upgrade my personal installation, we will need to co-ordinate the upgrade across multiple machines *and have a roll-back capability in case of failure at any point*. This might be our major issue?
Flags: needinfo?(tech)
I added you to the bug in question.

I will be coordinating the upgrade process when we are ready to push it to the prod infra. In the interim we will be testing in dev once hexmode has the new point release ready.

Regards
Mark, 1.19.12 came out 2014-02-27, that's two security releases after the one we had been waiting for?

I don't think we should wait for 1.19.13.

Also, dev seems to be running 1.19.11?
Flags: needinfo?(mah)
Seems that prod is actually running 1.19.11 as well, but the fix isn't the fix.

jquery.mwExtension is loaded, and extends $, but not jQuery, according to my use of devtools?

Leaving the needinfo open for Mark, just a different info this time.
I am actually putting together a new point release for 1.19 today to fix up some mistakes from the last one.  That said, I'll have to defer the q to Timo, the MW JS guru.  I've asked him to look in here.
Flags: needinfo?(mah)
Apologies for the previous comment.  I was just replying to the latest without checking the history on this bug.  I'll investigate more why this doesn't work on current wikimo.
(In reply to Axel Hecht [:Pike] from comment #16)
> Seems that prod is actually running 1.19.11 as well, but
> the fix isn't the fix.

Do you have a page where this is still happening?  It looks like the one in Comment #0 doesn't have a table any more.
(In reply to Mark A. Hershberger (hexmode) from comment #19)
> (In reply to Axel Hecht [:Pike] from comment #16)
> > Seems that prod is actually running 1.19.11 as well, but
> > the fix isn't the fix.
> 
> Do you have a page where this is still happening?  It looks like the one in
> Comment #0 doesn't have a table any more.

Right here: https://wiki.mozilla.org/L10n/Community
Timo tracked this down to a second jquery that wikimo is loading.  I'll make a pull request unless someone beats me to it.
I found https://wiki.mozilla.org/Labs/Ubiquity/Usability/Usability_Testing/Fall_08_1.2_Tests myself.

(In reply to Axel Hecht [:Pike] from comment #16)
> jquery.mwExtension is loaded, and extends $, but not jQuery, according to my
> use of devtools?
> 

You're probably looking at a local variable instead of the actual reference. The jquery.mwExtension module extends the global jQuery, and other modules use that exclusively. The $ is a local closure reference.

It is broken because MozillaWiki loads another jquery.js which redefines the jQuery and $ globals and with that also the jQuery.fn prototype where plugins reside.

<script src="/extensions/Bugzilla/web/jquery/1.6.2/jquery.min.js?303"></script>


As of MediaWiki 1.17 jQuery is loaded by default[1] and this can be relied upon, extensions should not ship or load their own.

MediaWiki also ships jQuery UI, which isn't loaded by default, but extensions can load it[2]. Though nothing uses MediaWiki's copy of jQuery UI on MozillaWiki at this point, I'd highly recommend fixing that one as well to avoid similar conflicts.

[1] https://www.mediawiki.org/wiki/jQuery
[2] https://www.mediawiki.org/wiki/ResourceLoader/Developing_with_ResourceLoader#Loading_module
So, it seems that to fix this issue we need to:

1. review all MediaWiki extensions currently installed to identify which ones are including jQuery and jQuery UI
2. either patch or update those extensions so they aren't re-including jQuery/jQuery UI

Does that sound about right?
Sounds like https://github.com/mozilla/mediawiki-bugzilla is a good first start, that certainly does both.
This should fix the issue in the bugzilla extension:
https://github.com/christi3k/mediawiki-bugzilla/commit/7c7c9a3d8c4122d42139b319bebd7e7fe575bc9b

I don't currently have a dev environment for wiki setup so I haven't tested. One thing I'm unsure about is if the local css files need to be included regardless of wikimedia version. 

Does anyone have time to review?
This is a crippling regression that makes wikimo unusable for one of my projects. When is this likely to be fixed?
(In reply to Christie Koehler [:ckoehler] from comment #25)
> This should fix the issue in the bugzilla extension:
> https://github.com/christi3k/mediawiki-bugzilla/commit/
> 7c7c9a3d8c4122d42139b319bebd7e7fe575bc9b
> 
> I don't currently have a dev environment for wiki setup so I haven't tested.
> One thing I'm unsure about is if the local css files need to be included
> regardless of wikimedia version. 
> 
> Does anyone have time to review?

Brandon, can you take a look?

Christie, might be good to turn that changeset into a PR, and attach the URL here and request review explicitly.
Brandon's not employed here anymore, so I'm not sure when he'd have time to look into this. 

@Christie, if you can send a pull request back to the main repo I can merge it. That seems like a reasonable commit to me. We can test it on our own wiki dev instance.
I've manually applied this patch on the dev server temporarily, and it doesn't seem to work as expected. The extra extensions/Bugzilla jQuery files still appear in the console when loading the page in comment 22.

However, I can simply comment out the offending lines from that same file (extensions/Bugzilla/Bugzilla.php) and the scripts are no longer called. Unfortunately, the page still doesn't have sortable tables. :(

For the time being I have disabled the "Bugzilla" extension on wiki-dev.allizom.org. Testing can proceed there.

https://wiki-dev.allizom.org/Labs/Ubiquity/Usability/Usability_Testing/Fall_08_1.2_Tests

To recap, I don't see the duplicate jQuery stuff here, but I also don't see sortable tables. Anyone have any ideas on our next move?
:ckoehler found the problem with her Bugzilla extension patch and fixed it... I've tested it and it works.

That plus some formatting problems she also fixed, plus a non-deployed commit to the GMO skin, have resulted in working sortable tables on dev!

https://wiki-dev.allizom.org/Labs/Ubiquity/Usability/Usability_Testing/Fall_08_1.2_Tests
https://wiki-dev.allizom.org/Contribute/Areas

Once her PR lands, we'll re-deploy it all to dev and stage, and then if it doesn't break horribly, to prod. The end is nigh!
With Christie's help, this is now deployed and resolved!

3 things to note that fixed this:

1) Incorrect table formatting. The header rows should begin with "!", not "|". If "|" is used, Mediawiki doesn't recognize it as a header row and does not present the sort buttons. See the table syntax used here if your table isn't working:
https://wiki.mozilla.org/Contribute/Areas

2) The GMO skin had a bug fix that was not deployed in all environments. Looks like prod and stage had it, but dev did not. This is fixed everywhere now.

3) The Bugzilla extension was loading its own jQuery data, as discovered by Timo up in comment 22, which was overriding the built-in one. This is fixed now.



I repeat, if your tables are not working, double-check the syntax is correct (#1 above). If it is and it's still not working, please let us know and point out the affected page(s). Thanks!
Assignee: nobody → nmaul
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
I just tried and it works for me.  Very exciting :)
(In reply to David Boswell from comment #33)
> I just tried and it works for me.  Very exciting :)

Works for me too! Thanks everyone
Blocks: 1001710
Anyone else seeing similar behavior to bug #1001710?
Blocks: 1004616
Target Milestone: --- → 2014-Q2
You need to log in before you can comment on or make changes to this bug.