Last modified: 2011-10-01 03:14:44 UTC
Wikis like wikimediafoundation.org and payments.wikimedia.org allow the use of javascript in wikitext - for things like dynamic forms and fundraising thermometers. Now that jQuery isn't loaded until the end of the page, however, all the jQuery pieces are broken. Obviously, there are several workarounds available, but I would like to argue for including jQuery in the head if $wgRawHtml = TRUE. It's only 100K of overhead and having it available for wikitext seems like a very useful feature--maybe not for most foundation wikis, but for intranet and private wikis especially. Would it be difficult to add in a switch so that jQuery was included in the head if $wgRawHtml = TRUE?
Maybe we could have a separate setting for that, instead of just doing it when $wgRawHtml is on?
Trevor has also mentioned that there is a possibility that jQuery will be moved back to the head anyway. Which would make this bug moot.
Fundraising is gearing up for workflow testing, so we need to know if this bug is going to be fixed in the near future or not. If not, we to start re-coding all the pages currently using jQuery in wikitext.
This is fixed in trunk, because jQuery is back in the <head>
Looks like this didn't make it into the final 1.17.0 release, which puts us back in the same boat for fundraising. Any chance of a 1.17.1 release? We'd rather not run development code on the payments server.
(In reply to comment #5) > Looks like this didn't make it into the final 1.17.0 release, which puts us > back in the same boat for fundraising. Any chance of a 1.17.1 release? We'd > rather not run development code on the payments server. Hmm. It is in 1.17wmf1, 1.18 and 1.18wmf1. Surely you'd feel comfortable running code that has been running on the live site for half a year (1.17wmf1)? :)
Fair enough. We'll upgrade to 1.17wmf1 rather than 1.17.0. Thanks for the advice.
May as well go to 1.18wmf1 since the rest of the cluster is going to be running it in about a week.
We'll probably hold off on 1.18 for the fundraiser. It's a bit of a process to update and we've held off 'bleeding edge' and new deployments for hidden gotchas or security holes that could cause issues and then take a while to port over, test with the fundraising infrastructure and deploy.
(In reply to comment #9) > We'll probably hold off on 1.18 for the fundraiser. It's a bit of a process to > update and we've held off 'bleeding edge' and new deployments for hidden > gotchas or security holes that could cause issues and then take a while to port > over, test with the fundraising infrastructure and deploy. As for the security holes, You might actually be at a disadvantage after this week when the last projects are pushed to 1.18wmf1, because not much (if any) attention will be payed to 1.17wmf1 due to almost no one using it (It's not recommended for people to use this outside WMF but a small number do/have) and I don't think anyone will spend that much time backporting fixes to it when its not really being used/supported on the cluster for the projects.
