I have a php website on localhost, and it always worked fine, but now it just shows old css files and old js files. When I edit the files and refresh the page nothing changes.
especially the css layout file does not want to update
I use:
XAMPP and
APACHE
I have read many articles on stackoverflow about this problem, but nothing works for my I’ve tried adding:
<?php
header("Cache-Control: no-cache, must-revalidate");
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Content-Type: application/xml; charset=utf-8");
?>
But that gave an error:
This page contains the following errors: error on line 44 at column 8:
Opening and ending tag mismatch: link line 0 and head Below is a
rendering of the page up to the first error.
and then it handles the page as a document and just shows plain text.
I tried using .htaccess files, but those did nothing.
I really don’t know how to deal with this, I can’t continue on the website because it just doesn’t want to update and it is stuck on an old page.
Can anyone please help me solve this problem, because I am getting kind of hopeless.
EDIT:
So I fixed the error, but it is still not updating
I changed the PHP to:
<?php
header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");
?>
Since it else showed my page as XML, but this still doesn’t update the layout.
How can I let my page automaticly reload the files, so no (CTRL + F5).
2
Answers
This error should only occur when the document type of your html page is XHTML. You can check this by having a look at the first line of your document, this declares a XTHML doctype:
This means that all html tags have to be closed properly, like e.g.
Note the
</link>
that I added in the third line. The easiest way to solve this would be to change the doctype toThat means that your document wouldn’t have to be well-formed.
The alternative would be to close all html tags.
I would suggest that you try this and if the cache problems should persist come again and ask for that.
And do not cache stylesheet files
The easiest way to do this is to just add a new parameter (like e.g. ?ver with a version number) to the stylesheet document whenever you change something in your styles:
That should do, you don’t have to change anything with the stylesheet’s file name.
Another, more sophisticated way would be to install mod_expires and define this in your apache2 configuration:
I hope this helps! If it does I would appreciate an accept to this answer.
I do 3 things to make sure that dynamic data does not get cached:
1. Set appropriate response headers
Basically these header set expiration in the past, sets many directives to avoid that services in between you PHP output and the end client modify or cache your source.
2. Include HTML meta tags
Some proxies and the web client will parse the HTML (which should be avoided it the “no-transform” directive above). So adding directives to the HTML output further reduces the risk of caching.
There are two “expires” specifications in this html excerpt – as far as I understood some web clients will not parse the date.
3. Add a timestamp to resource URLs that potentially change.
Static resources (or equivalent) like images, css files, but also xml files, text files, fonts, etc, should be cached for performance, but you still want to avoid the cache when you update them.
By adding a timestamp to the URL, the URL will depend on the resource timestamp itself and it will prevent intermediate servers from serving a cached version.
You could replace the timestamp with a static “tag” like “v1”, “v2”, etc. However I prefer a computed timestamp as I do no longer have to think about updating it. In fact almost all of my resources are timestamped automatically.
Here is a PHP example:
Note
Some of the directives may be redundant, but it is better to be redundant than to have a particular user that experiences issues. The above is the result of actual field experiences. For example, “no-transform” was added after remotely debugging a user’s environment where the proxy of his mobile operator inserted javascript and css resources directly into the HTML. That was pretty much unexpected and it created a unwanted behavior at the time.
Browser capabilities also vary over time and when you have some users that still use old browsers, some will not understand some of the directives.
So I recommend playing safe and simply add as many countermeasures as you can.