Question posted in
Some documentation to get you started can be found here.

PHP Caching stops my website from showing the actual files, and instead shows old files. I have tried everything and nothing works – Apache

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).

Tags:

2

Answers


  1. 0

    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:

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

    This means that all html tags have to be closed properly, like e.g.

    <head>
    <title>my webpage</title>
    <link rel="stylesheet" type="text/css" href="mystyles.css"></link>
</head>

    Note the </link> that I added in the third line. The easiest way to solve this would be to change the doctype to

    <!DOCTYPE html>

    That 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:

    <link rel="stylesheet" type="text/css" href="mystyles.css?ver01"></link>

    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:

    ExpiresActive On
ExpiresDefault “access plus 10 days”
ExpiresByType text/css “access plus 1 second”

    I hope this helps! If it does I would appreciate an accept to this answer.

    Login or Signup to reply.
  2. 0

    I do 3 things to make sure that dynamic data does not get cached:

    1. Set appropriate response headers;
    2. Include HTML meta tags;
    3. Add a timestamp to resource URLs that potentially change.

    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.

    Expires: Sat, 26 Jul 1997 05:00:00 GMT
Cache-Control: nocache, must-revalidate, no-store, max-age=0, private, max-stale=0, post-check=0, pre-check=0, no-transform
Pragma: no-cache

    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.

    <meta http-equiv="cache-control" content="no-cache" />
<meta http-equiv="cache-control" content="max-age=0" />
<meta http-equiv="pragma" content="no-cache" />
<meta http-equiv="expires" content="0" />
<meta http-equiv="expires" content="Sat, 26 Jul 1997 05:00:00 GMT" />

    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:

    // This is a simple example, it must be adapted to your environment.
// * $initialUrl is a URL like "//mystyle.css" without any get parameter.
// * $resourceUrl is the (relative) server path to that resource
//                 which could be "/var/www/mysit/mystyle.css"
// * filemtime gets the timestamp of the resource.
// * baseconvert gets a shorter representation of that timestamp.
// * The timestamp is appended to the URL by simple concatenation here.
// * $url can then be used to generate the HTML (echo ".... $url ...";).
// * This can (should) be wrapped in a function.  Personally I have integrated
//   it in the MVC Framework I use in an output filter and in a utility
//   class method.
$url=$initialUrl.'?ts='.base_convert(filemtime($resourcePath),10, 36);

    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.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search