Merge the css (and/or js) files

[GoogleCodeExporter]

we have a lot of HTML requests when we load style.css and any JS framework
or file. As we know it our clients could send only two concurrent requests
to a single server. auto merging all our files (directly on the server, not
on the client) could be a possible way to improve the speed of a
thematic-powered blog? 

if you think that it is an important improvement I will start working on an
algorithm to include this feature but I will need help for coding.

cheers.

Original issue reported on code.google.com by dannydam...@gmail.com on 25 Jan 2009 at 2:45

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I’d welcome the feature for the CSS. Thematic’s and its themelets’ 
modular CSS structure is a boon to the 
developer, but handles badly when it comes to HTTP requests. The only extension 
I am aware of that purports to 
concatenate @import’ed CSS files, WP CSS, fails when handling Thematic 
themelets (you’ll end with the Thematic 
styles instead of the themelet ones). Adding a mechanism to merge the diverse 
CSS files on the fly would be 
helpful.

Original comment by martin.k...@gmail.com on 28 Jan 2009 at 10:57

[GoogleCodeExporter]

Hey Danny, Hey Martin,

let me work a bit with WP CSS, I have it running here on my test machine with a 
fixed
path. And it does an excellent job. I'm pretty sure, that I can fix the code to 
work
with child themes. 

As soon as I have a working copy, I would like to contact the author. I think 
that he
agrees to implement my changes. If not .. I can still implement this technology 
into
Thematic.

Cheers,

Chris

Original comment by chris.gossmann@googlemail.com on 30 Jan 2009 at 3:39

[GoogleCodeExporter]

if need help, just asking Chris!

Original comment by dannydam...@gmail.com on 30 Jan 2009 at 4:34

[GoogleCodeExporter]

Hey Chris, great to know you are working on fixing WP CSS for child themes! 
While you are doing this, do you 
think you could convince its author to make gzipping the CSS a selectable 
option? I’d rather use mod_deflate() to 
compress CSS on the fly than have to rely on the PHP engine. 

Original comment by martin.k...@gmail.com on 30 Jan 2009 at 4:39

[GoogleCodeExporter]

I fixed WP CSS. Now it'll work with child themes. A copy is on its way to 
Danny. Next
step will be the additional option to switch off gzipping for Martin. 

Send a mail to chris (at) wupperpiraten.de, if you would like to have a working 
copy
of WP CSS.

Will contact Halmat Ferello and inform him about these changes.

Original comment by chris.gossmann@googlemail.com on 30 Jan 2009 at 6:45

[GoogleCodeExporter]

Sent a mail to Halmat Ferello .. now let's grab a coffee or two and wait for 
his reply.

Original comment by chris.gossmann@googlemail.com on 31 Jan 2009 at 1:26

[GoogleCodeExporter]

Hey Chris, do you think it may works even on a local server? because I've 
forgot that
on my online server I've already use a single(manually merged) css file. I'm not
really into this kind of things (on and offline servers)...

Original comment by dannydam...@gmail.com on 31 Jan 2009 at 1:47

[GoogleCodeExporter]

Hey Danny,

I have it running on my local server (XAMPP). Works perfect!

Cheers,

Chris

Original comment by chris.gossmann@googlemail.com on 31 Jan 2009 at 2:13

[GoogleCodeExporter]

well, i'm going to try it on my WAMP.

Original comment by dannydam...@gmail.com on 31 Jan 2009 at 2:20

[GoogleCodeExporter]

Testing WordPress 2.8 .. the handling of scripts will change. With 2.8 the 
plugin
developers will be able to decide, where the script will be loaded (header or
footer). In addition the core will concatenate and compress the scripts 
(switchable).
Andrew Ozz mentioned CSS too, but I haven't found anything 'bout this in the 
core
'til now.

So .. at the moment it doesn't make much sense to take care of script 
compression. If
you provide a full blown child theme with a lot of own scripts (not the ones 
loaded
by plugins using wp_enqueue_script()) you can contact me for a fixed version of 
the
WP-JS plugin.

Original comment by chris.gossmann@googlemail.com on 31 Jan 2009 at 2:26

[GoogleCodeExporter]

it works perfectly.

only a thing: in my opinion, it could be useful to add a character encoding
declaration. IE has some known issues if it is missing.

Original comment by dannydam...@gmail.com on 31 Jan 2009 at 2:30

[GoogleCodeExporter]

js can wait. the most important "issue" is about HTML requests generated by 
loading
at least 8 css files by default.

Original comment by dannydam...@gmail.com on 31 Jan 2009 at 2:33

[GoogleCodeExporter]

Hey Danny,

good to hear that WP-CSS is working for you. Thanks for your help!

The character set declaration for external CSS should be done inside the css 
file.
For instance you can have a @charset "utf-8"; on top of your CSS file. It's up 
to the
designers to include this declaration.

Cheers,

Chris

Original comment by chris.gossmann@googlemail.com on 31 Jan 2009 at 3:05

[GoogleCodeExporter]

Yes, but what about IE issues. it could be useful if the plugin itself checks 
for the
declaration and add it if missing. the thematic "standard" user doesn't know 
about
this kind of things. in my opinion, a great framework provides also this kind 
of things.

what do you think???

Original comment by dannydam...@gmail.com on 31 Jan 2009 at 3:29

[GoogleCodeExporter]

Looking into the W3C specs .. there's only one case where I need a character set
declaration inside the CSS. If the designer uses non-ASCII values for the 
content
property, or refers to non-ASCII element or attribute names or values. In this 
case
he would run into trouble without the declaration even without using WP-CSS. So 
he
should already have fixed this problem. 

And .. how should I find out which declaration is needed. By setting a standard 
UTF-8
I could make it even worse for the designer.

Original comment by chris.gossmann@googlemail.com on 1 Feb 2009 at 9:58

[GoogleCodeExporter]

Ok, there's no problem.

Original comment by dannydam...@gmail.com on 1 Feb 2009 at 1:36

[GoogleCodeExporter]

Hey Chris, could you send  me a version too ? Turns out mod_deflate() is 
unsupported on one of the hosts I want 
to use it… Thanx!

Original comment by martin.k...@gmail.com on 1 Feb 2009 at 6:34

[GoogleCodeExporter]

WP-CSS is on its way to you. Btw.: Halmat sent a reply today. He'll add me to 
his
project. After reviewing my code, it'll be included into the next release.

Original comment by chris.gossmann@googlemail.com on 2 Feb 2009 at 9:26

[GoogleCodeExporter]

That's great. The new version works just fine on the Acamas themed site I have 
set up. Too bad I had to disable 
it again because it messes with the style files of WP-Touch (it seems to inject 
the Acamas styles into WP-Touch, 
which looks odd on the iPhone, to say the least) – seems it will still need a 
plugin specific sub theme switch, not 
just your excellent fix for child themes...

Original comment by martin.k...@gmail.com on 2 Feb 2009 at 2:49

[GoogleCodeExporter]

.. I love it  ;-) 
.. will check it the next days .. so .. stay tuned for the upcoming 
fixes.

Original comment by chris.gossmann@googlemail.com on 2 Feb 2009 at 7:16

[GoogleCodeExporter]

Will close this issue because it is purely WP-CSS related

Original comment by chris.gossmann@googlemail.com on 5 Feb 2009 at 1:46

• Changed state: WontFix