Customizing SMF > SMF Coding Discussion

Running JS and CSS through PHP?

(1/1)

MrPhil:
Another discussion somewhere (I can't find it at the moment) had someone mentioning that they had their .htaccess running .js and .css files through PHP. I'm curious about this -- presumably they have some <?php ... ?> segments mixed in to set various parameters or whatever. Have you seen this in use before? Does it work well? I'm assuming that the browser still sees conventional-looking .js and .css files and has no idea what's going on behind the scenes.

I haven't tried it, but I would suppose any settings could be passed in to the PHP code via $_GET from the <link> or <script> tag pulling in the file. Or, build an include file to embed, rather than passing settings through the command line. Any security issues that you can think of? The settings would be visible in the browser code, and might be changed. What about browser caching of JS and CSS files -- could the wrong (old) version of the file ever be included?

If you want to vary your JS and CSS based on PHP variables, would a better alternative be to use conventional JS and CSS files (no embedded PHP), and set variables in the PHP <script> section (before the .js file) or override CSS settings in a <style> section (after the .css file)? The main (PHP) script would build the appropriate <script> and <style> sections to control or override JS and CSS.

Arantor:
Well, I've done this in the past - set up an .htaccess to intercept the request through rewriting the URL, and diverting it to a PHP file.

It's usually not recommended for performance reasons, in my case I had to do it to protect the JS files from guests on the site.

It actually doesn't matter what the browser sees, though, whatever URL is requested via script or link tag will work, provided the return response also indicates its type as being JS or CSS respectively.

It depends mostly on the settings at work - either way they will be exposed to the user, be it directly in that file or inline into the page, either way the user will be able to see that.

Browser caching etc. is of course a problem and ideally you'd create a new file with a new name to get around that.

A better alternative would be to put the bulk of stuff into static files and let the server serve them as static, and either have that handled automatically somehow or to inject per-use variations into the page.

I'm going to talk about what Wedge does, because it sort of does this automatically (and I'm not talking about it out of promotion but as one solution to the problem at hand) - Wedge doesn't use standard CSS, it uses a LESS type syntax and parses that into CSS files, including browser-specific headers as required, and then it saves the file so it can be served statically. There are specific cases where variables will also be injected - theme paths, for example - so that the result CSS is more compact, even though it was generated via PHP.

I see no reason why a similar approach couldn't be used for what you're looking at doing, though if it really is per-page variable use, inlining it into the page would likely be cleaner.

MrPhil:
Thanks for the thoughts. I don't have a specific project in mind, but more of something to add to my website design bag of tricks. As I said, someone else had mentioned embedding PHP code in their JS and CSS files, and this got me to thinking about how I could do "dynamic" JS and CSS in a browser-independent manner (cf. MS's dynamic CSS). Of course, detecting different browsers and tuning JS and CSS to them could have its advantages, rather than packing in all sorts of funky codes to handle different kinds of browsers. Once the browser is detected, this information could be kept in the session information so detection only needs to be done once per session. I'll have to go back and look at 52framework and Bootstrap to see if they're doing something like this to accommodate different browsers.

It sounds like the simplest and most efficient way is to output a <script> section with any functions or variables defined before specifying a static .js file using that information, or to specify normal static .css files and then override properties with a dynamically built <style> section on the page. You say that browser caching of .js or .css files might cause problems (browser assumes they're static?) -- I don't want to get into spinning out a bunch of new file names.

With your Wedge implementation of generated CSS files, would they get unique .css file names? This would tune .css files to a visitor's specific browser and theme? What happens when they decide to change either the browser or the theme -- is this detected and new files generated automatically? Is there some advantage to this over what I described above (static .css with a customized in-line <style> section)?

Arantor:

--- Quote ---With your Wedge implementation of generated CSS files, would they get unique .css file names?
--- End quote ---

Yes, they do. The result CSS file is based on the names of all the composite files (index, sections, admin etc.), plus browser suffix, plus timestamp, so caching is sort of built in already.

If the browser changes, a different suffix (e.g. webkit, gecko, ie) is generated, or if the files change, the timestamp changes (since it's the latest file out of the entire set)

There are advantages to this approach, you only end up with the files you actually need, they're automatically cached while being cache proof (the file is static, served statically, but the requested file always has the most recent file timestamp on it, so the files are cached by browsers correctly and auto-expiring, as it were)

There are still also advantages to having static CSS with customised in-line CSS, namely if it's solely on one page or a few pages, there's no need to clutter the same CSS files up for everyone in the process, optimised or not. It's really about having a collection of techniques and using the right one for the right job.

Navigation

[0] Message Index