Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Options
Vanilla 2 In-Browser Speed Optimization?
Now, I'm not sure what the best way to handle this would be, but the most helpful way, from a theme-developer's perspective would be to do what SilverStripe and a couple other CMSes do, which is to have a production mode where all the CSS and JS is packed and cached with a versioned filename, so it can be served more quickly. Having said that, some JS really should run in the <head>, and still other JS could be cached by a browser from other webpages and hosted by Google. Google and Yahoo! both have great optimization tips and techniques and while I don't really care to optimize *yet*, I do think it's something I'll want to do down the road, and I'd rather not have to hack away at Joomla proper to do so.
Yet I wonder--is such automatic caching worth the time to develop, for most people? I'd say yes, but there could still be future edge cases--perhaps using a CDN or a cookie-less host for static content only? I could imagine someone in future trying to use memcached to squeeze every last inch of performance out of Vanilla/Garden, or taking advantage of Facebook's PHP compiler, Hiphop. Though for me this all came to a head just now as I'm starting to write a CKEditor plugin for Vanilla 2-- Do I really want to put all the JS in the <head> when some of it definitely won't be needed until later? Between that and hosting jQuery on Google, I figure there are some easy enhancements that could be made to speed up the in-browser performance of Vanilla without modifying or minifying the CSS and images in a theme.
As simple as it is, I can't see myself hacking away too much at this optimization as a plugin, especially if jQuery should be hosted by Google. At that point, I figure this should all be a part of Garden-proper instead. Other bits like using a CDN or static host, or more clearly separating on-load code from that which belongs before the closing body tag, could perhaps be enabled more manually using a plugin, though even there I feel as if Garden should eventually support this.
If I forked Garden and tried out some of these modifications, would that be acceptable? Or do you already have such caching plans written down somewhere?
Yet I wonder--is such automatic caching worth the time to develop, for most people? I'd say yes, but there could still be future edge cases--perhaps using a CDN or a cookie-less host for static content only? I could imagine someone in future trying to use memcached to squeeze every last inch of performance out of Vanilla/Garden, or taking advantage of Facebook's PHP compiler, Hiphop. Though for me this all came to a head just now as I'm starting to write a CKEditor plugin for Vanilla 2-- Do I really want to put all the JS in the <head> when some of it definitely won't be needed until later? Between that and hosting jQuery on Google, I figure there are some easy enhancements that could be made to speed up the in-browser performance of Vanilla without modifying or minifying the CSS and images in a theme.
As simple as it is, I can't see myself hacking away too much at this optimization as a plugin, especially if jQuery should be hosted by Google. At that point, I figure this should all be a part of Garden-proper instead. Other bits like using a CDN or static host, or more clearly separating on-load code from that which belongs before the closing body tag, could perhaps be enabled more manually using a plugin, though even there I feel as if Garden should eventually support this.
If I forked Garden and tried out some of these modifications, would that be acceptable? Or do you already have such caching plans written down somewhere?
0
Comments
Trouble cropped up with line breaks, so I temporarily commented out the function Html's regex for line breaks in the format class. And the post.js in the vanilla application seems to serialize() the form, which doesn't seem to warn ckEditor to update the hidden textarea with new content, unlike other uses of $().val() which was successfully overridden by ckEditor. So currently, edits don't work, and some of the CSS formatting looks odd, again particularly so when using an Edit popup. Oh and the ckEditor steals right-clicks from the popups, so a part of me is just thinking of disabling them entirely, or making my own Edit popups.
All in all, it's still been less work then I was afraid of. Either that or I've been hacking away at forums for more years than I can count. Sigh.