Not signed in (Sign In)
Categories
Vanilla 1.1.4 is a product of Lussumo. More Information: Documentation, Community Support.
Help keep Vanilla free:Welcome Guest!
Want to take part in these discussions? If you have an account, sign in now.
If you don't have an account, apply for one now.
Want to take part in these discussions? If you have an account, sign in now.
If you don't have an account, apply for one now.
Fixes & Updates: protoculous-packer.js.gz - Prototype AND Aculous @ 32,8KB
Bottom of Page1 to 36 of 36
-
see http://groups.google.com/group/prototype-core/files and download latest .zip
then go to protopacked_v2.16b.zip\files\compressed\protoculous\version (1.5.1.1 + 1.7.1_beta3)\gzipped
(or whatver version you got) and there you have the protoculous-packer.js.gz file<script src="protoculous-packer.js.gz"></script>
and you are good to go. apart from being years newer than the files included with vanilla, this is also 100KB smaller
//edit: include code:<script src="/protoculous-packer.js<? if(strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') !== false) echo '.gz'; ?>"></script>
maybe this is also required, I don't know:!preg_match('/MSIE (5\.5|6\.0(?!.*\bSV1\b))/i', $_SERVER['HTTP_USER_AGENT'] -
nice! but is it backwards compatible?
-
Try it an find out? :D
-
not sure, so far I'm using it only for some other sites / scripts
not tested with vanilla yet. so whoever finds out tell us :) -
AlexL, have you got a "gz.php" (or equivalent) which you serve it with? If so, I would quite like to have it please :)
-
Stash, i think that would be handled by apache and mod_gzip.
-
All I have is <script src="protoculous-packer.js.gz"></script>, nothing else
demo (still not vanilla, sry didn't find the time yet): http://www.baldursoft.de/DropDown/
// edit: AFAIK mod_gzip is NOT required since it is already .gz -
if i were to propose using this in the vanilla core, which i think could be a good idea, i'd have to add some kind of test to find whether the user's
webserverbrowser supports gzip (this is easy enough to do, just check the Accept-Encoding header), and serve the non-gzipped file if it doesn't.
this would actually increase the size of the vanilla download (we'd have to include both the gzipped and non-gzipped versions of the file), but could potentially save quite a bit of bandwith for forum admins, since almost everybody's browser supports gzip these days. (protoype is huge, that's my only complaint about it.) -
alex, you're right. what i'd have to do is check the browser, not the server, but that would still require packaging both versions of the file with vanilla.
-
actually on further thought, mod_gzip should take care of all of this automatically... i'll have to read more about it.
-
yeah mod_gzip could zip on the fly. but that's a *really* bad idea!!
1. I beleave all browsers that support prototype also support gzip?
2. even if you include both files the vanilla download size would still be smaller than it is right now -
Will Windows browsers support .gz'd files?
-
no Alex, i meant that if there are two versions of the file on the server, one named file.js and one named file.js.gz, i believe that mod_gzip can pick the correct one to send. i'm not talking about on-the-fly compression.
yes, windows browsers support gzipped content. -
Bah, typed the wrong word :P I meant will Windows servers? *sigh*
-
oh yes, iis supports it and of course apache for windows does.
-
yeah, here it is, from the mod_gzip site:
######################################
### statically precompressed files ###
######################################
# ---------------------------------------------------------------------
# let mod_gzip perform 'partial content negotiation'?
mod_gzip_can_negotiate Yes
# (if this option is active and a static file is to be served in com-
# pressed for, then mod_gzip will look for a static precompressed
# version of this file with a defined additional extension - see next
# directive - which would be delivered with priority. This would allow
# for avoiding to repeatedly compress the same static file and thus
# saving CPU time.
# No dynamic caching of this file is provided; currently the user
# himself is responsible for creating and updating the precompressed
# file's content.
# From version 1.3.19.2a mod_gzip automatically recognizes whether
# a statically precompressed file is older than its uncompressed
# original and in this case will serve the content of the original
# file in uncompressed form - as to rather serve correct data than
# outdated ones ...)
we could do this via the .htaccess file, but since lussumo already provides a .htaccess in the form of FriendlyURLs, we'd have to be careful not to get those streams crossed. -
I've been using the ob_gziphandler in this mannor:
ob_start("ob_gziphandler");
echo $thefile; // or include("if_ya.want")
ob_flush();
the ob_gziphandler takes care of checking the browser for gzip and doesn't compress the content if the client wont accept it.
If your gonna make a core file change you should add something simmilar to this script:
http://www.ejeliot.com/samples/combine/combine.phps
it takes an array of files so you could just pass the arrays of css and javascript files to a js and css version of it and it cashes them and serves the compressed cashe file to the users whenever possible.
I made a plugin for wordpress to do that(only way I had to get both the wordpress and the vanilla css/javascript) and it works really well, bringing total page size(main page) from like 300k to ~150k and the page load speed from ~12 seconds to ~6 seconds and http requests from an ungodly 47 to like 12
if I remember correctly for css/javascript specifically:
css: ~54k >> 11k
js: ~190k >> ~130k(jsmin) >> 48k
(values according to YSlow and www.websiteoptimization.com)
so this would be a worthwhile add-on to the core and alot of the code is already done in packer, then you could just include the uncompressed new version of prototype, and it will gzip it on the first pageload then serve the combined/jsmin'd files. -
come on people. its a simple if(browser_support_gzip) .gz else .js
it can be done in one line. don't behave like you all never coded php before
btw: this has absolutly(!!!!!!!) nothing to do with mod_gzip or the server you use! -
alex, don't be a dick. my point was that it can be done in mod_gzip with 0 lines of php.
(!!!!!!!!) -
yeah sry, but you have to agree that 1 line in php is better than a required mod :)
(allthough it is always included?)
and for mod_gzip to work your way you have to change a php.ini var AFAIK.
Then you got the problem that on ALL sites on the server flush() won't be working.
Well maybe it can be set with a simple ini_set(), never tried it.
Sorry again for my tone, wasn't intended that way
Btw. .gz support:
IE4+, FF, Opera 5.12+, Netscape 6.02+
that makes what? 100% of all used browsers? :) -
i think it's a great idea (the gz file you proposed) and i'll see about getting it into vanilla. i have to make sure that the new version is going to behave well with the older function calls in the vanilla core.
-
Quote: AlexL
Btw. .gz support:
IE4+, FF, Opera 5.12+, Netscape 6.02+
that makes what? 100% of all used browsers? :)
And where does Safari fit into your 100%?Posted: Saturday, 25 August 2007 at 8:16AM
-
In the bottom 1.5%-4%?
-
As do all things fine, stylish and with any sense of style...
Posted: Saturday, 25 August 2007 at 10:09AM
-
you know what? not every single thread needs to be a mac vs. pc debate.
-
He started it, I simply asked a simple question.
Posted: Saturday, 25 August 2007 at 5:06PM
-
well... if this is mac vs pc than pc wins :p
-
alright, for the mac users here ;-)
<script src="/protoculous-packer.js<? if(strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') !== false) echo '.gz'; ?>"></script> -
Quote: AlexL
well... if this is mac vs pc than pc wins :p
Whatever the competition, if pc wins, it's a boobie prize and you're welcome to it!
Posted: Monday, 27 August 2007 at 11:20AM
-
To serve js.gz you always need some apache directive like:
<files *.js.gz>
ForceType application/x-javascript
Header set Content-Encoding: gzip
</files>
that can be done with a .htaccess inside the js folder - that would need more rules to be sure it works on servers without mod_header or the ones that don't allow the use of .htaccess file.
Also, even without compression, we have to think on how to keep the extension that use the old prototype and scriptaculous file working. They will still try add the old file to script list and won't add the new one. -
Dinoboff, I would be willing to go through the old protaculous extensions to update them to the new one if it's as easy as you say to "fix" servers that don't support .gz files natively. I'll give that directive a bash in my .htaccess and report back (could be a few days).
-
1) it should be noted that I didn't have to do anything at all to be able to serve .js.gz files on any of my servers except localhost. also I can't find anything similar in my apache config on a server where this is working just fine.
so I guess this really is just a fix (maybe old apache?)
2) even without gz compression this version is smaller and much newer than the current one
3) one could write a php script that checks for prototype and aculos references in head->scripts[] (not sure what the exact names are right now) and replaces them
maybe it's even possible to make a protoculouspackerjs extension that does what I tried to describe in my 3rd point. but including it into the core would be much better, since then new extensions could depend on a new prototype and aculos version -
From the protoculouspacked readme:
"To load gzipped files you need to go through a server side language such as PHP.
Some have used the .gz file directly but that’s not universally supported."
And using xampp, it couldn't make it to work without the directive that I mention earlier.
I agree that the package should be in core - you can't load two difference version of prototype. That can't be done in Vanilla 1.1.3 since it will break some extension. We will see with the extension authors what they want us to do with prototype in Vanilla 1.2. -
I'll see how many extensions use proto and if I can update it before 1.1.3. If I could, would you include it in 1.1.3?
-
When I try to use the packed (just packed no compression), it try to add:<code><script src="http://localhost/vanillaDev/js/.js" type="text/javascript"></code>
I know scriptaculous try to add script tags on the client side to load the different component.
Here, all the component are packed, so why does it try to add js/.js?
except that, it seems to work. -
you are right, very strange bug. I have exactly the same file as .gz and the error does not appear if .js.gz is used
1 to 36 of 36