Once again, great contributions by everyone. I love the Tek-Tips community!
spamjim said:
You appear to be engineering unnecessary complexity.
Whether at runtime or in a pre-processor to make a unique set of static CSS files for each client, it will be the same amount of complexity, and as far as I can tell it is not "unnecessary". And I don't do
everything wrong that was cited in that article you referenced - I'm not doing the insecure example, and I'm using the proper headers and such. Sure, it's faster to not invoke the PHP interpreter for one's CSS file, and caching is a help, but my files are really not that big (especially once I stop sending the stuff for other pages - the point of this thread). Without benchmarking it, I'm not sure whether the PHP engine use is more of a performance hit than having the browser ask for two files instead of one - if anyone has a gut feel on that, let me know, but there is a lot said about reducing HTTP requests (image sprites and such like that) but not much noise about minimizing PHP execution, so I wonder.
Anyway, there are far worse efficiency problems elsewhere in my code, and I plan a total rewrite at some point - I can work on tweaking this also at that time, and your idea of using the same PHP as a preprocessor to create a static CSS file is worth exploring. But right now the most limited resource in this whole thing is my time - I'm the sole developer of this monstrosity, and I'm only a missionary doing it as a part-time project, not a paid programmer (jpadie probably remembers this project, as he has helped me many times in the past).
vacunita: Thanks for the testing and info - you saved me struggling to figure that out. And the Firebug tip is helpful, too - I am a green novice when it comes to good use of Firebug.
jpadie said:
just remember to delete the variables in the session and explicitly close the session too (to avoid race conditions).
I already have a session that is used in every PHP file in my application (even the CSS one), for authentication and other information. I thought it closed at the end of script execution anyway - am I wrong? In this case I can close it when I have retrieved a few pieces of data at the beginning, but since it's not writing session data (only reading), I don't know how it would make any difference. I guess "race condition" is the how one puts into words that general unsettled feeling I had when I first thought of using the session for this. But I've tried to think of scenarios that could cause a collision, and I can't think of any - I don't do AJAX requests immediately upon pages loading (only in response to user actions). Plus, style.php will never write anything to the session - it will only read (unless I delete the variable after I read it). By the way, what is the purpose for your suggestion of deleting the variable each time (as opposed to just leaving it there and letting the next file overwrite its value)?
jpadie said:
also it might be a good idea to call the css file in the html with a normal css extension and then use mod_rewrite to redirect the call internally to the php resource. not sure exactly why but something piques my memory about this being a good idea.
Yeah, I need to learn more about how to utilize mod_rewrite - I think I'm missing out on simpler ways to do some things that it might be able to do, but that syntax always looks about as cryptic as regex expressions. Ah, so much to study! As to why that might be a good idea, perhaps its just a bit more security, not calling attention to the fact that my CSS file has code in it...