Contao SeitenCache -> ClearCache Button, wenn etwas geändert wurde.

[Metis77]

Feature Wunsch: Wenn der SeitenCache aktiviert ist und wenn etwas irgendetwas geändert wird, sollte ganz oben ein Hinweis und ein Button erscheinen, um den SeitenCache direkt zu löschen.

Ich weiß nicht wie es anderen geht, aber bei mir melden sich regelmäßig Kunden mit der Beschwerde, dass Änderungen im Frontend nicht angezeigt werden. Und da kann ich noch so auf darauf hinweisen, dass sie bitte den Cache leeren sollen.

[Aybee]

Das sollte meiner Meinung nach automatisch passieren, wenn man im BE eingeloggt ist und etwas verändert, dass der Cache dann diesbezüglich verändert wird. Bei Typo3 musste ich immer so 300 mal am Tag den Cache leeren, wenn ich Inhalte eingepflegt habe oder entwickelt habe. Das sollte mit Contao nicht auch so sein.

Hast du denn auch Probleme wenn der Cache-Modus auf "nur Servercache" steht? Denn ich denke, dass das normal ist, wenn du auch den Browsercache aktiviert hast.

[Metis77]

Stimmt, ich habe BrowserCache und ServerCache aktiviert. Allerdings funktioniert es immer sobald man den unter User den SeitenCache löscht.

Mir ist tatsächlich aufgefallen, dass viele nur den ServerCache aktivieren. Sollte es nicht aber auch mit beidem funktionieren, zumal es geht sobald man den Cache löscht?

[Aybee]

Ich bin nicht so der Cache-Fachmann, aber wenn dein Browser eine Seite cached in der ein Ablaufdatum in der Zukunft liegt, dann fordert er erst gar keine Seite an, sondern nimmt die aus dem Cache, auch wenn der Server eine neue hat.

Es kommt auch darauf an, wie dein Browser eingestellt ist. FF ist z.B. default auf browser.cache.check_doc_frequency = 3 (Check when the page is out of date) eingestellt, checkt also das Ablaufdatum. 1 wäre "check every time". Manche Entwickler-Erweiterungen stellen das während des Entwickelns von 3 auf 1.

Wenn du in Contao den Browsercache nicht aktivierst, sollte der Server also eine Seite ausliefern mit einem Ablaufdatum in der Vergangenheit, wenn du sicherstellen möchtest, dass alle Browser die Seite direkt vom Server holen. Mit Shift F5 kann man im FF die Seite auch direkt vom Server holen.

[Metis77]

@Aybee eben leider nicht. Da hilft auf Reload (F5 oder CMD+R) nichts. Wenn es so wäre, wie du beschreibst wäre es ja super.

Dieses Verhalten fällt mir bei allen Browsern auf, und eben immer wieder meinen Kunden. Erst wenn wenn man den Contao Seiten Cache leert, wird per reload die veränderte Seite geladen.

Einfach mal mit Contao Server+Browser Cache testen. Dazwischen auch ausloggen, damit der HTML Page Cache von Contao aufgebaut wird. Sonst lässt sich das nicht nachvollziehen.

[Toflar]

Zur Klarstellung:

• Server-Cache Ist eine Contao-spezifische Implementation. Wenn er aktiviert ist, versucht Contao beim ersten Besucher einer Seite (wir nennen sie mal beispiel.html) das generierte HTML zu speichern. So kann die Last für die Ausführung von Contao verringert werden, weil der 2. Besucher dann zwar ganz normal Contao abfragt, aber Contao intern nur noch das zuvor generierte HTML ausliefert. Alles andere was ggf. aufwändig ist (wie bspw. das Generieren des Navigationsbaums) wird übersprungen. Es liegt in der Natur dieses Caches, dass er ein shared Cache ist - also für alle Besucher gilt.
• Browser-Cache Ist die Implementation eines der Caching-Features von HTTP. Das HTT-Protokoll verfügt über sehr mächtige Caching-Mechanismen, mit denen man sich lange beschäftigen kann (und sollte). Im Prinzip ist es aber so, dass man zwei Möglichkeiten hat: Entweder man sagt dem Browser wie lange er eine Datei cachen darf (Expires) bevor er wieder neu nachfragt oder man kümmert sich selbst um Cache-Invalidation. Beide beziehen sich (da auf dem Client) natürlich nur auf einen Besucher.
  • Expires: Die einfachere Variante des Cachings sagt dem Browser einfach "bitte behalte diese Datei für 24h im Cache und dann frag mich erneut für das File". Dies ist die Methode die Contao implementiert.
  • Cache-Invalidation: Ist die sehr viel bessere, aber auch sehr viel schwierigere Caching-Methode. Beim ersten Anfragen der Webseite liefert der Webserver nebst dem Inhalt der Webseite auch einen Hash bzw. eine "Identifikationsnummer" für den Content mit. Bekannt ist der unter ETag :) Bei der nächsten Anfrage des gleichen Clients sendet der Browser automatisch den vorher erhaltenen ETag mit dem If-None-Match Header mit. Der Webserver kann nun - wenn er weiss dass der Inhalt immer noch der selbe ist wie derjenige den er damals mit dem erhaltenen ETag generiert hat - einen 304 Not Modified header ohne Inhalt zurücksenden und der Browser nimmt die Daten aus dem Cache. Ansonsten kriegt der Browser ein 200 OK mit neuem Inhalt und neuem ETag. Diese Methode reduziert natürlich den Traffic und kann - wenn der Webserver (durch welchen Mechanismus auch immer) in der Lage ist, zu bestimmen ob sich der Inhalt verändert hat ohne ihn bereits wieder komplett zu generieren - zu weniger Last auf dem Webserver führen. Contao nutzt das aufgrund der Komplexität nicht und deaktiviert in der .htaccess standardmässig sogar das Senden des ETag.

Caching kann allerdings sehr oft nicht für ganze Seiten vorgenommen werden. Nehmen wir mal an ihr würdet ein Login-Modul in der rechten Spalte platzieren. Es wäre ja schon komisch, wenn immer noch das Formular angezeigt würde auch wenn ihr eingeloggt seid, nur weil der Browser die Seite gecached hat. Da gibt es dann Methoden, die Seite in einzelne Subelemente aufzuteilen und daraus mehrere HTTP-Requests (welche wiederum gemäss obenstehender Erklärung gecached werden können) zu machen. Stichwort für's Weiter-Googeln wer mag: Edge-Side-Includes. Auch da reden wir von komplexem und professionellem Caching. Es ist sehr schwierig bzw. fast unmöglich das generell zu implementieren, weshalb Contao auch das nicht macht.

Lange Rede kurzer Sinn: Wenn ihr Caching aktiviert, versucht zu verstehen wie er funktioniert. Wenn der Server-Cache geleert wird, heisst das noch lange nicht, dass der Browser die Resource neu anfragen wird. Hoffe das bringt ein bisschen Licht ins Dunkel am Morgen früh :-)

Weiterer Lesestoff: RFC 2616 (das ist im Prinzip unsere Bibel, sie ist nicht einfach zu lesen, aber jeder Webentwickler sollte es tun ;-))

[frontendschlampe]

sehr gut @Toflar ... dankeschön ... kannst du das auch gleich so ins Wiki schreiben? ;-)

[Metis77]

@Toflar super Anleitung, herzlichen Dank dafür.

Nichts desto trotz ändert das nichts an dem Problem. Bitte steinigt mich wenn es wirklich nur an mir liegt.

1.) Contao nur Server Caching an. (mit Server + Browser Caching ist das Verhalten aber identisch) 2.) Irgendeine Änderung machen. 3.) Anderer Browser oder Coockies löschen. 4.) keine Änderung im Frontend sichtbar, solange nicht in Contao der Cache gelöscht wird.

D.h. man muss IMMER den Cache löschen (was ja irgendwie logisch ist), wenn man möchte dass anderen noch innerhalb der Cachevorhaltezeit diese Änderungen sehen. Deshalb halte ich einen Hinweis / Button für sinnvoll, der direkt die Redakteure erinnert und den Cache mit einem Click leeren lässt.

[Toflar]

Ja logisch. Solange der Server-Cache an ist, kriegst du nie eine Änderung im Frontend. Das habe ich ja erklärt :) Aber ich denke es ist falsch den Kunden darüber zu informieren, dass er den Cache leeren muss. Entweder er versteht wozu er da ist (und ist dementsprechend einverstanden damit, dass seine Änderungen erst in z.B. 4 Stunden ersichtlich sind) oder er will das nicht, was soviel heisst wie: die Cache Zeit ist falsch oder überhaupt sollte kein Caching stattfinden.

[Metis77]

@Toflar Ja das erkläre ich den Kunden auch immer. Sind sind auch jedes mal davon überzeugt, vergessen dann aber doch wieder den Cache zu leeren und fragen dann verwundert nach.

Inzwischen bin ich der Überzeugung, dass hier ein Hinweis (mit direkter Möglichkeit zum Cache leeren) für die Usability wichtig wären.

[Toflar]

Und dann kommt noch hinzu, dass das ja eigentlich gar nicht geht. Du müsstest ja wissen, welcher Inhalt auf welcher Seite ausgegeben wird. Wenn z.B. die News auf einer nicht-gecachten Seite ausgegeben werden, dann muss diese Meldung ja nicht erscheinen, da ja nix passiert. Das herauszufinden ist fast unmöglich, weil das Modul im Seitenlayout, im Artikel, per InsertTag etc. eingebunden werden kann. Insofern bleibt die Möglichkeit bei jeder Änderung eine Nachricht à la "Hallo, Sie haben was geändert, evtl. müssen sie den Cache löschen" auszugeben, was aber nutzlos und somit Unsinn wäre.

[Metis77]

@Toflar das Stimmt natürlich. Mir geht es letztendlich darum, einfach eine schnellere / einfache / direktere Möglichkeit zu haben, den Cache zu leeren.

Mein Vorschlag kommt im Grunde eher von meinem Kunden, welche die aktuelle Situation als "Umständlich" empfinden. Vielleicht sind sie auch einfach nur die immer präsenten Cache Leeren Buttons von anderen System gewöhnt.

[Aybee]

@Toflar danke für den Artikel

Aber Contao ist doch so intelligent, dass es den serverseitigen Cache aktualisiert sobald ich eine Änderung irgendwo vornehme, oder etwa nicht?

Ich habe das gerade mal in der Demo auf Contao 3.3.3 getestet. Nur Servercache eingestellt. Seite Home 30 min Cachezeit eingestellt. Überschrift in einem CE geändert.

Die geänderte Überschrift ist bei mir im FE sofort sichtbar.

Das ganze funktioniert bei mir sogar mit "Server und Browsercache". Und auch auf anderen Seiten. D.h. bei mir bekomme ich das überhaupt nicht simmuliert, dass im FE was altes aus irgendeinem Cache angezeigt wird.?

ps Mein "interner Cache" ist deaktiviert, aber der hat damit doch nichts zu tun, oder?

[Toflar]

Aber Contao ist doch so intelligent, dass es den serverseitigen Cache aktualisiert sobald ich eine Änderung irgendwo vornehme, oder etwa nicht?

Nein. Nur wenn du es manuell machst. Die einzigen Ausnahmen dazu sind:

• Bildercache leeren, leert auch den Seiten-Cache (Bilder sollen ja neu geladen werden)
• Scriptcache leeren, leert auch den Seiten-Cache (Skripte sollen ja neu geladen werden)
• XML-Dateien neu schreiben, leert auch den Seiten-Cache (wegen ungültigen Links)

Wobei du ausserdem den Cache nicht zu Gesicht bekommst im Frontend wenn du:

• POST-Daten sendest (Formulare abschickst)
• Im Frontend eingeloggt bist
• Im Backend eingeloggt bist
• Den Debug-Modus aktiviert hast

ps Mein "interner Cache" ist deaktiviert, aber der hat damit doch nichts zu tun, oder?

Nein :)

[tsarma]

I have some kind a solution to it, by giving a visual feed back of cached page and making it possible to remove cache individually instead of purging the whole website.

I have implemented it this as shown below in my own dca/tl_page.php. This is just to give you an idea, it may not work as i have this since long time back and never reviewed it.

<?php

/**
 * Add fields to tl_page
 */

// This finds out home page ID and store it in session
$GLOBALS['TL_DCA']['tl_page']['config']['onload_callback'][] = array('tl_page_bus', 'myOnload') ;

array_insert($GLOBALS['TL_DCA']['tl_page']['list']['operations'], 0, array (
    'cached'  => array(
        'label'               => &$GLOBALS['TL_LANG']['tl_news']['feature'],
        'icon'                => 'blank.gif',
        'button_callback'     => array('tl_page_bus', 'pageCacheIcon')      
    )
)); 


/**
 * Class tl_page_bus
 *
 * Provide miscellaneous methods that are used by the data configuration array.
 */
class tl_page_bus extends \Backend
{

    public function myOnload()
    {
        /* This is here just because home page url can be only the domain name, or domain + home.html */
        if($this->Session->get('HOME_PAGE') == '')  {
            // there no Model for finding first published root page.
            $objHomeRoot = $this->Database->prepare("SELECT id, language FROM tl_page WHERE pid=0 AND published=1 ORDER BY sorting")->execute();
            $objHomePage = \PageModel::findFirstPublishedByPid($objHomeRoot->id);
            $this->Session->set('HOME_PAGE',  $objHomePage->id);
            $this->Session->set('HOME_LANG',  $objHomeRoot->language);
        }

    }

    /**
     * Return the "cached" button
     * @param array
     * @param string
     * @param string
     * @param string
     * @param string
     * @param string
     * @return string
     */
    public function pageCacheIcon($row, $href, $label, $title, $icon, $attributes)
    {

        if( in_array($row['type'], array('regular', 'error_403', 'error_404') ) ) {
            // Get the default URL      
            $objPage = \PageModel::findWithDetails($row['id']);

            $strCacheKey = \Environment::get('base') . $this->generateFrontendUrl($objPage->row()); 

            // HOOK: add custom logic // This is copied from FrontendTemplate.php, as it is
            if (isset($GLOBALS['TL_HOOKS']['getCacheKey']) && is_array($GLOBALS['TL_HOOKS']['getCacheKey']))
            {
                foreach ($GLOBALS['TL_HOOKS']['getCacheKey'] as $callback)
                {
                    $this->import($callback[0]);
                    $strCacheKey = $this->$callback[0]->$callback[1]($strCacheKey);
                }
            }           

            $hashed = md5($strCacheKey);

            $strCacheFile = TL_ROOT . '/system/cache/html/' . substr($hashed, 0, 1) . '/' . $hashed . '.html';

            /* only for the home page compare the row id with stored home ID*/
            if($row['id'] == $this->Session->get('HOME_PAGE')) {
                $homeHashed = md5(\Environment::get('base') . 'empty.' . $this->Session->get('HOME_LANG'));
                $strHomeCacheFile = TL_ROOT . '/system/cache/html/' . substr($homeHashed, 0, 1) . '/' . $homeHashed . '.html';
            }


            //execute delete action
            if (strlen(\Input::get('rid')) && strlen(\Input::get('paged')) )
            {
                @unlink(TL_ROOT . '/system/cache/html/' . substr(\Input::get('paged'), 0, 1) . '/' . \Input::get('paged') . '.html');

                /* only for the home page */                
                if($row['id'] == $this->Session->get('HOME_PAGE')) {
                    @unlink( TL_ROOT . '/system/cache/html/' . substr($homeHashed, 0, 1) . '/' . $homeHashed . '.html');
                }

                $this->redirect($this->getReferer());
            }

            // check if file is cached
            if (file_exists($strCacheFile) OR (($row['id'] == $this->Session->get('HOME_PAGE')) AND  file_exists($strHomeCacheFile)) )
            {
                 $icon = 'cache.gif';  
                 $href .= '&amp;rid='.$row['id'].'&amp;paged='. $hashed;

                // return icon with link    
                 return '<a href="'.$this->addToUrl($href).'" title="delete '.specialchars($title).'"'.$attributes.'>'. \Image::getHtml($icon, $label).'</a> ';
            }  else{
                 // return passive icon
                 return $this->generateImage($icon, $label);                 
            }
        }   // end if;      
    }

}

?>

[Aybee]

@Toflar Nur wenn du es manuell machst.

Ok, habe das FE jetzt in einem 2. Browser getestet und da sehe ich dann tatsächlich die Veränderungen nicht.

Ist das zu schwer zu realisieren? Oder warum macht Contao das nicht (Servercache aktualisieren bei Veränderung)?

Ich bin bis jetzt immer davon ausgegangen, dass andere die Veränderungen auch sehen, da ich sie ja auch sofort in meinem FE sehe. Aber wenn das daran liegt, dass ich im BE eingeloggt bin, dann wäre ich auch dafür sogar einen Button in den Header zu bringen, mit dem man den Seitencache sofort aktualisieren kann. Sonst ist das immer doof wenn man dem Kunden sagt "ich habe es korrigiert" aber er sieht es nicht.

Mir ist das ganze Cachingverhalten noch nicht so bewusst geworden, weil ich die Seiten meistens nicht cache. Die Kunden stellen meistens auch nur "Server und Browsercache" in den Einstellungen ein, ohne zu wissen, dass nichts gecachet wird, solange die Seiten nicht auch eine Cacheeinstellung bekommen.

[Toflar]

Ist das zu schwer zu realisieren? Oder warum macht Contao das nicht (Servercache aktualisieren bei Veränderung)?

Wie gesagt, Contao weiss nicht welche Änderungen (News, Events, Artikel etc. pp.) sich auf welche Seiten auswirkt. Insofern müsste es ja bei jeder Änderung irgendwo in Contao den gesamten Seiten-Cache leeren. Dann kannst du ihn ja gleich bleiben lassen.

@tsarma: Indicating that a page is being cached is indeed a nice addition. However, it does usually not affect the regular editors. They will most likely not have access to the site structure because they are only editing articles and news and stuff. So I stick with my opinion: either editors fully understand the caching mechanism and do not care if their content is only visible after 4 (or whatever) hours or they don't want it to be cached which means you as a site administrator should disable it. It's a matter of training, not of Contao doing cache magic.

[Ruudt]

I would find it acceptable if the entire page-cache is emptied whenever I manually need it to. A button to quickly do that would be great. Showing important content quickly trumps efficiency of the system. But it shouldn't popup at the top because the system can't possibly know when cache clearing is desired.

How about a core setting/module/extension so a button can be enabled and configured per user, to set which cache to clear when pressed?

@Toflar: I think the customer should not need to understand caching. Most barely understand adding content, and unfortunately almost none appreciate waiting for content to show.

@tsarma: There is already an extension by aschempp for that, but it isn't well maintained unfortunately: cacheicon (https://contao.org/en/extension-list/view/cacheicon.10000029.en.html)

[Aybee]

@Ruudt @tsarma [cacheicon] is only to show if a page has cache activated or not in the page settings.

[Toflar]

A button to quickly do that would be great.

Maintenance -> checkbox for page cache -> submit -> done. Can't be much quicker I think. Where else would you like to put it?

@Toflar: I think the customer should not need to understand caching. Most barely understand adding content, and unfortunately almost none appreciate waiting for content to show.

Disagree. Again: if they don't understand it, then the system administrator should not enable caching. If, however, the system administrator feels like caching is (due to the number of requests or so) needed, he or she should explain it to the customer so that they understand. It's as easy as that.

[tsarma]

@Aybee:[cacheicon] is only to show if a page has cache activated or not in the page settings.

Not just show if a page has cache activated. Mine implementation above shows icon only if the page is cached.

@Ruudt : Thanks for info, I just went my way.

Actually I think, with little bit of work we can also make it possible to purge page's cache if some editor edit and save content with use of save_callback.

[Metis77]

Disagree. Again: if they don't understand it, then the system administrator should not enable caching.

Thats like: "if the customer does not understand web, he should not have a website"

Maybe I am the only one with that kind of customers, but most of my customers either do not understand it, do not care about it or just forget it. But whenever asking an explaining it to them they prefer to keep caching on.

That is why i still stick to my feature request: Add a link/button "clear PageCache (x)" next to the user settings at the top of the contao backend. Maybe even with "x" indicating the number of currently disk cached contao pages.

[Ruudt]

Maintenance -> checkbox for page cache -> submit -> done. Can't be much quicker I think. Where else would you like to put it?

That's actually not as quick because there are a lot of caching options to choose from. Doesn't get much more complicated for the layperson. I mostly have the type of customer @derhaeuptling describes.

Disagree. Again: if they don't understand it, then the system administrator should not enable caching.

The typical client needs to know the effect, not the mechanism; push button -> refresh browser -> see contents now! If new important content is a daily occurrence the administrator should consider disabling/altering of some/all caching; different scenario and you could be right there.

[Toflar]

So to sum up for @leofeyer: People would like to have a "Clear cache" button in the top bar that clears the page cache on click. :smile: For the record: I'm still :-1: on this for a few reasons I have mentioned in my comments.

[Ruudt]

How about I'll create an extension for it instead? Button can't be in the header in that case because I'd not like to edit the original template. What would be the best alternative for a single click button?

@leofeyer: Is it possible to make the top links editable through the dca?

[Metis77]

@Ruudt I'd prefer the "button" to be in the same look an feel as the other top links (like user settings, logout, ...)

Also i think this should be not a plugin. This feature should present itself by default particularly to not so experienced users, who do not know of helpful plugins like this. (same as the ticket about the sticky footer buttons like save)

[leofeyer]

I am with @Toflar on this one. An extra button does not solve any problem.

Also, constantly purging the cache causes more harm than simply decreasing the cache timeout. Why do you set a cache timeout of 4 hours for a dynamic page? What are the positive effects you are hoping to accomplish?

[Aybee]

I think it's the wish to simulate a static page for speed up page rendering. Some customers like to set their cache to 1 year and maybe change some content (news, event ...) only once a month. Then they like to see new content immediately and not waiting one year ;) and they don't know anything about clearing cache.

[Metis77]

I think it's the wish to simulate a static page for speed up page rendering. Some customers like to set their cache to 1 year and maybe change some content (news, event ...) only once a month. Then they like to see new content immediately and not waiting one year ;) and they don't know anything about clearing cache.

that is absolutely a good point.

another is: especially rarely visited pages with a cache time of 5 min would actually never be cached, as there are no two visitors visiting within 5 min. so it could be a good idea, to set caching time to weeks or longer.

[aschempp]

Don't forget about the client cache. So if you set the chache to 1 year the previous visitors will not see the updated version even though you clean the server cache. I suggest you do not use 1-year caches... make the caches reasonable, like several hours. The load on the server will still be dramatically less (if you have a lot of visitors), and everyone will see new news within an hour.

[Ruudt]

Does the frontend preview bypass cache? If so it can be used to see changes right away for the customer while waiting for the 1 hour cache to expire. On Jul 16, 2014 10:51 PM, "Andreas Schempp" [email protected] wrote:

Don't forget about the client cache. So if you set the chache to 1 year the previous visitors will not see the updated version even though you clean the server cache. I suggest you do not use 1-year caches... make the caches reasonable, like several hours. The load on the server will still be dramatically less (if you have a lot of visitors), and everyone will see new news within an hour.

— Reply to this email directly or view it on GitHub https://github.com/contao/core/issues/7155#issuecomment-49225065.