views:

214

answers:

4

I have a unique problem, which is proving difficult to solve using google. I am consolidating all of my javascript and css into separate php files, which use require_once() to pull the contents of the files in. The javascript file looks something like this:

<?php
header('Content-Type: text/javascript');
require_once('jquery.form.js');
require_once('jquery.jqtransform.js');
require_once('jquery.validate.js');
?>

My specific problem is that web browsers will 'see' that this is a dynamic page, because of the php file extension, and then request the content anew each time a page on the site is loaded. What I am trying to do is get the time of last request from the browser, and then check each file modification time to see if I really do need to send the file contents again. It is proving difficult to find the time of last request by the user. Also, I have not yet started to tackle the problem of finding the last modified date of the files that are included, so if there is information regarding finding the file details of a file on the server, that would also be appreciated.

Just to be clear, the reason I am doing this is because (I think) it takes advantage of the gzip compression better than individually gzipped files.

Thanks in advance

A: 

You can enable auto-gzipping of files using apache mod_deflate.

You can also use apache mod_rewrite to refer to these files in the html as js files and redirect the request to the php files, avoiding your server caching issues.

Something like this:

RewriteEngine On
RewriteRule (.*).js $1.php

Put this code in a .htaccess file in your directory.

adam
The actual problem is nothing to do with the file extension, which is an opaque part of the URL browsers don't care about. It's the cache-control/expires/etag headers that matter.
bobince
+1  A: 

Your premise is incorrect. Browsers don't "see" the PHP file extension and decide not to cache things. See http://www.enhanceie.com/redir/?id=httpperf for information on how browsers really work.

You should set an ETAG on your response, and then you can simply check the If-None-Match request header and return a 304 if the content is unchanged.

EricLaw -MSFT-
+1. Though easier still would be to avoid serving scripts and stylesheets through PHP. There's no real advantage to it.
bobince
@bobince: Sure there is. Fewer HTTP requests.
Mark
Mark has it right. I want to take advantage of the compression and fewer http requests
Scott M.
JS-min (http://github.com/rgrove/jsmin-php) can be set to concatenate, zip and store the final version on disk, outputting it as required, and rebuilding the cache if required.
Alister Bulman
A: 

Browsers don't determine if a page or a file is dynamic or static by its extension. Its headers do. Just set the proper headers so the browser knows it can cache the results.

Also, ditch the closing ?>. It's not required and is bad practice.

Htbaa
Why is `?>` bad practice? How else will you close PHP code?
Steven
Unless you embed big parts of HTML, or whatever, you don't. If you include a file which has a space after the closing tag it can lead to some annoying "headers already sent" errors.
Htbaa
"For files that contain only PHP code, the closing tag ("?>") is never permitted. It is not required by PHP, and omitting it´ prevents the accidental injection of trailing white space into the response. "Source: http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html
Htbaa
I disagree with ?> being bad practice. Though I agree with your answer to the OPs question. I think it's far cleaner to explicitly delineate your PHP code, even if it can be done implicitly.
Myles
?> is NOT REQUIRED however I also 100% dissagree in calling it bad. IT will not speed up your page at all by not using it. And as for whitespace slipping in, I haven't had that problem yet in 5-6 years
jasondavis
@Myles: There's nothing to delineate if it's 100% PHP.
Mark
I consider it bad practice if the file is 100% PHP. As for it not happening to you in the last couple of years I can understand that with your own code. But when using someones else library this error can slip in rather easily. It's just a pain in the ass kind of bug to find.
Htbaa
A: 

I wrote a series of posts about this issue specifically. See Supercharging Javascript in PHP and Supercharging CSS in PHP. These cover:

  • Combining files;
  • Gzipping best practices;
  • Caching best practices; and
  • Versioning output.
cletus