Stupid Plone portal_javascripts

I just spent the last day or so of my life tracking down what the fuck was wrong with Plone v3.1.7's portal_javascripts (part of Plone's resource registries). I had tried replacing Plone 3.1's default jQuery v1.2.6 with v1.3.2 in order to use the latest jQuery UI which has fixes for IE8 (plus, it's a LOT faster). I did the usual: customise 3rd_party/jquery.js and upload the new content.

It all worked fine in portal_javascripts debug mode i.e. with compression, merging and caching turned off. Unfortunately it certainly didn't work when debug was off - it would merge the first file only and forget the rest in its merge group. Needless to say this completely wankered this website.

The fix which most people on the internet use for this problem is to permanently disable caching and merging - with the obvious performance penalties for end users. Needless to say, I wasn't happy with that idea, so after MUCH trial & error it turns out that there is a bug in Zope's file upload mechanism. If you choose a javascript text file and upload it, something subtly breaks inside Zope such that the resource registries silently die during parsing - you can tell this because if you turn on compression in portal_javascripts and then choose the "Merged JS Composition" tab and open the keycache file, you'll see that the one single file in there hasn't been compressed. I don't think it is UTF-8 (a common Python 2.x problem) nor Windows format CR/LF as I tried stripping these before file upload. Who knows?

Anyway, the workaround is as follows: simply don't upload the file and just create an empty one, then open it up in the web browser view where it gives you a textarea to type into, and now simply copy and paste the javascript into the textarea and save.

And voila! Plone works! I hope this saves some of you lots of heartache like me. I have submitted a bug report to Plone at http://dev.plone.org/plone/ticket/9087