We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
MODX Community Forums Archive

Answered http caching headers - how to change?

    • 34016
    • 3 Posts
    HSquared Reply #1, 13 years, 8 months ago
    Hi all,

    on one of my sites I get the following http headers in Firebug:
    Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache


    How can I change these values in MODx? I checked with the server guys, seems the values are set by PHP which means MODx Revo in this case. Desired behaviour would be caching for 2 weeks (<meta http-equiv="Cache-control" content="public" />, <meta http-equiv="expires" content="1209600" /> but set in PHP of course).

    Any ideas?

    Regards,

    Henning

    P.S.: my first try, setting the headers in the index.php file before the context load, failed. (what somehow makes sense ;-))

    This question has been answered by hsquared. See the first response.

      • 40045
      • 534 Posts
      exside Reply #2, 13 years, 8 months ago
      if you're on Apache you could try it via .htaccess file in the root directory of your site, something like this:

      # Browser caching using Apache's "mod_headers"
<IfModule mod_headers.c>
	# 2 WEEKS
	<FilesMatch "\.(html|htm|xml|txt)$">
		Header set Cache-Control "max-age=1209600, public, must-revalidate"
	</FilesMatch>
</IfModule>
        • 18373 ☆ A M B ☆
        • 3,141 Posts
        Mark Hamstra Reply #3, 13 years, 8 months ago
        Could use the php header() function in a plugin triggering on OnHandleRequest.
          Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

          Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
          • 34016
          • 3 Posts
          HSquared Reply #4, 13 years, 8 months ago
          Yep exactly, thanks. Apache config is likely no way on a shared host and so, as Mark also suggests, I discussed a plugin with Jason on the IRC (he was of the opinion that caching is against the nature of a dynamic scripting language but in this case PHP/MODx delivers mostly SEO texts - which can be cached for some time).

          If I wanted to use a TV to finetune the caching time (off, 7, 14 days) http://rtfm.modx.com/display/revolution20/OnLoadWebDocument might also be the choice because $modx->resource is present then.

          Any good, additional arguments for the one or the other system event?
          • discuss.answer
            • 34016
            • 3 Posts
            HSquared Reply #5, 13 years, 8 months ago
            O.k., new plugin, system event "OnLoadWebDocument"; here comes the code:

            <?php
//code extended from http://www.electrictoolbox.com/php-caching-headers/

$days = 7;
$seconds_to_cache = $days*86400;
$ts = gmdate("D, d M Y H:i:s", time() + $seconds_to_cache) . " GMT";
header("Expires: $ts");
header("Pragma: cache");
header("Cache-Control: max-age=$seconds_to_cache, public");


            Works like a charm, new cache values confirmed with Firebug (no effect on the MODx-Manager).
              • 18373 ☆ A M B ☆
              • 3,141 Posts
              Mark Hamstra Reply #6, 13 years, 8 months ago
              Thanks for sharing your solution smiley

              If OnLoadWebDocument works (and having access to the resource is a very good reason to use that one), than that's fine. OnHandleRequest is my swiss army knife of plugin events and from memory I was pretty sure you could use it to set the proper headers hence the suggestion wink

              That plugin would be great use for RSS resources too, to give some sort of indication for RSS readers as to how often they should ping back.
                Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

                Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
                • 36816
                • 109 Posts
                clareoconsulting Reply #7, 13 years, 4 months ago
                Greetings,

                I really like Mark's note that this could be a good technique for RSS feeds, and have another use case that might help someone.

                I arrived at this thread via search for a use case that's a little bit different (mobile-first responsive), but the header-setting tips in this thread helped me deal with my particular use case, so I thought I'd add-on here in the hope that it assists others who come across it in the future.

                I'm working on a mobile-first responsive design site (pretty much all I do any more), but this particular client has some pretty bandwidth-challenged content (big 'accent' images, photo galleries that don't add value to the mobile user, etc.) that they want to use on the larger devices, but agreed to let them be kept off the mobile device output.

                Use Case
                To solve this I'm using a variant of what Filament Group labeled the Ajax-Include-Pattern (https://github.com/filamentgroup/Ajax-Include-Pattern). It goes like this in my MODX use-case:


                1. Page template has an empty HTML element that will contain the bandwidth-expensive content for devices that should display it
                2. That HTML element has an HTML5 data attribute that specifies the URL that'll provide that content via Ajax load
                3. That Ajax-fetched content is a non-menu MODX HTML resource that has no template
                4. Front-end JS, when DOM's ready, checks a media query to see if running on a device that should display the content
                5. If on a device that shouldn't show that content, stops there; saving much time for mobile by not downloading extraneous stuff
                6. If on a device that will show the content, JS does an Ajax fetch to the url in the data attribute and places what it gets into the DOM

                The Reason I Wanted to Cache
                The above does a great job for performance for the mobile visitor, but the large device visitor has to go through the HTTP request(s)in #6 each time the visitor gets to a URL that calls that Ajax load (even on re-visits in the same browser session), and the resulting visible lag compared to if that content had been served directly from the template in #1 (and thus cached by the browser).

                While the bandwidth-expensive content being loaded via that Ajax call in this case is dynamic, it is infrequently updated, so I can set an HTTP header expiration date to something like an hour or a day, and when the browser looks at that Ajax call the second and subsequent times, it doesn't bother to make the HTTP request, and the Ajax content comes out of browser cache.

                So.. im my case, I put the HTTP future expires cache headers code in a snippet that is called by the Ajax-included page, keeping the browser from re-accessing it until it expires. Voila - large device browsers see performance benefits too.

                Hope this helps someone else that comes across it.
                  • 36816
                  • 109 Posts
                  clareoconsulting Reply #8, 13 years, 4 months ago
                  Quote from: clareoconsulting at May 09, 2013, 08:25 AM


                  I arrived at this thread via search...

                  And, then, just an hour later, browsing latest forum posts, I came across Jason Coward (Opengeek)'s week old post about a new cache-control plugin he released two weeks ago. Timing's everything.

                  Here are his note about the plugin, and the plugin in Extras:

                  https://forums.modx.com/thread/84232/cache-101#dis-post-464893

                  http://modx.com/extras/package/microcache