Vollseiten-Cache

Dieses AddOn wird die gesamte Frontend-Ausgabe, die durch Template und Module erzeugt wird, in statischen HTML-Dateien cachen. Dadurch kann die Seitenerzeugung bei wiederholten Aufrufen vollständig eingespart und die Performance einer einfachen Seite enorm gesteigert werden.

Bemerkung

Es handelt sich hierbei nicht um ein “Hinzufügen, Installieren, Glücklich sein”-AddOn. Es sind Änderungen am Sally-Core erforderlich und während der Entwicklung wird das AddOn mehr stören als nutzen. Ohne genaue Kenntnis darüber, welche Teile des Frontends von welchen Änderungen im Backend betroffen sind, sollte das AddOn nicht eingesetzt werden.

Beispiel: Jede Seite enthält die vollständige Navigation mit allen Kategorien. Wird nun eine Kategorie auf offline gesetzt, muss der gesamte Cache aller Seiten entfernt werden, da sich diese Änderung auf das erzeugte HTML jeder einzelnen Seite auswirkt.

Allgemein gelten folgende Ratschläge:

  • Das AddOn sollte erst nach Projektabschluss hinzugefügt werden.
  • “When in doubt, clear all” – heißt, wenn man aufgrund der Komplexität einer Seite nicht sicher ist, welche Seiten bei welchen Änderungen entfernt werden müssen, sollte man einfach alle Cacheseiten entfernen.

Installation

Schritt 1

Legen Sie im develop-Verzeichnis eine Datei namens fullpagecache.yml an. Dort wird die projektspezifische Konfiguration abgelegt.

# gibt an, welche GET-Parameter beim Caching beachtet werden sollen
allowed_params: [q]

# Unbedingt Hilfe des AddOns lesen, bevor diese Funktion aktiviert wird!
# use_voodoo_magic: true
# ignored_session_fields: [STAMP, UID]

# gibt an, was bei einzelnen Events passieren soll
events:
   CLANG_DELETED: {action: flush}
   CLANG_ADDED: {action: flush}
   ALL_GENERATED: {action: flush}

Weitere Details zu den möglichen Aktionen folgen weiter unten.

Schritt 2

Installieren Sie nun das AddOn.

Schritt 3

Um das Caching im Frontend zu ermöglichen, muss der Frontend-Controller von SallyCMS manuell angepasst werden. In der index.php muss eine Zeile eingefügt werden:

<?php
/*
 * [snip]
 */

define('IS_SALLY', true);
define('IS_SALLY_BACKEND', false);

... wird zu ...

<?php
/*
 * [snip]
 */

// FullPageCache-Integration
require 'sally/addons/fullpagecache/scripts/layer1.php';

define('IS_SALLY', true);
define('IS_SALLY_BACKEND', false);

Im Layer-1-Cache wird der Request entgegengenommen und eine passende Cache-Datei gesucht. Wenn eine gefunden wird, wird sie ausgeliefert und die Ausführung des Scripts beendet.

Warnung

Eventuelle Statistik-AddOns werden bei einem Cache-Hit nicht mehr ausgeführt und können die Seitenaufrufe daher nicht zählen.

Konfiguration

Wenn das AddOn aktiv ist, erscheinen auf der Metaseite von Artikeln zwei neue Eingabefelder. Über die Ablaufzeit kann gesteuert werden, wie lange eine Cache-Version eines Artikels verwendet wird, bevor der Cache neu erzeugt wird. Über die Checkbox kann das Caching für diesen Artikel auch gänzlich deaktiviert werden.

The Big Clear All Config

Die folgende Konfiguration kann verwendet werden, um bei jeder Änderung an den Inhalten den gesamten Cache zu leeren.

events:
   SLY_CAT_ADDED: {action: flush}
   SLY_CAT_UPDATED: {action: flush}
   SLY_CAT_DELETED: {action: flush}
   SLY_CAT_STATUS: {action: flush}
   SLY_ART_ADDED: {action: flush}
   SLY_ART_UPDATED: {action: flush}
   SLY_ART_DELETED: {action: flush}
   SLY_ART_STATUS: {action: flush}
   SLY_CONTENT_UPDATED: {action: flush}
   ART_META_UPDATED:
      - {action: flush}
      - {action: callback, callback: [WV35_Extensions, artMetaUpdated]}

Wann wird nicht gecached?

  • bei POST-Aufrufen
  • wenn im Frontend WV35_FullPageCache::dontCache() aufgerufen wird
  • wenn das Caching im Backend für den Artikel deaktiviert wurde
  • wenn die Ausführung von OUTPUT_FILTER_CACHE verhindert wird (z.B. bei Ajax-Calls oder Weiterleitungen)
  • bei aktiven Sessions (siehe weiter unten)
  • bei Aufrufen mit X-Requested-With: Ajax (siehe weiter unten)

Aktionen

Das Herz des AddOns ist das Eventsystem, das flexibel auf die möglichen Veränderungen auf den Seiten reagieren kann. Dazu wird in der fullpagecache.yml eine Liste von Events mit dazugehörigen Aktionen angegeben. Für die grundlegenden Events (neuer Artikel, Artikel umbenannt, ...) sind bereits die notwendigen Aktionen vordefiniert.

Es kann entweder eine Aktion oder eine Liste von Aktionen angegeben werden:

events:
   MY_EVENT: {action: flush}     # einzelne aktion
   MY_OTHER_EVENT:               # mehrere
      - {action: flush}
      - {action: file}

Es gibt drei mögliche Werte für action:

  • flush: leert den Seitencache für eine Menge von Artikeln
  • callback: ruft ein beliebiges PHP Callable auf
  • file: bindet ein benutzerdefiniertes Script ein

Zu jeder der drei möglichen Aktionen gibt es weitere Parameter:

flush

Die einzelnen Werte müssen als ‘filters’ notiert werden, siehe Beispiel. All Filter sind optional und werden, wenn angegeben, mit UND verknüpft. Wenn eine Aktion die Menge nicht korrekt ausdrücken kann, können auch mehrere flush-Aktionen für ein Event definiert werden.

  • article: ID oder ‘self’ für den aktuellen Artikel (oder Event-Parameter, siehe unten)
  • clang: ID oder -1 für die aktuelle Sprache (oder Event-Parameter, siehe unten)
  • tree: wie bei article
  • status: wenn ein Wert aus [true, 1, yes, on, online], dann nur online Artikel
  • template: Template-Name
  • tree: Bei diesem Filter wird der angegebene Artikel sowie alle in seinem Teilbaum liegenden Artikel (falls es sich dabei um eine Kategorie handelt).
events:
   MY_EVENT:
      action: flush
      filters: {article: self, clang: -1, template: standard, status: online}
   MY_OTHER_EVENT:
      action: flush
      filters: {tree: self}

callback

Es kann ein beliebiges PHP Callable auf die übliche Art angegeben werden.

events:
   MY_EVENT:
      action: callback
      callback: [ClassName, methodName]
   MY_OTHER_EVENT:
      action: callback
      callback: myGlobalFunction

file

Der Pfad (relativ zum Projektroot) zu einem PHP-Script kann angegeben werden.

events:
   MY_EVENT: {action: callback, file: 'develop/foo.php'}

Event-Parameter

Statt bei der flush-Aktion die Parameter fest zu definieren, kann auch auf die Werte aus dem eigentlichen Event zugegriffen werden. Dazu muss der Wert, der in der YAML-Datei definiert ist, nur mit event_param_ beginnen.

Die Standard-Konfiguration gibt ein Beispiel:

events:
   CAT_UPDATED: {action: flush, filters: {tree: event_param_id, clang: event_param_clang}}
   CAT_STATUS: {action: flush, filters: {tree: event_param_id, clang: event_param_clang}}
   ART_UPDATED: {action: flush, filters: {article: event_param_id, clang: event_param_clang}}
   ART_STATUS: {action: flush, filters: {article: event_param_id, clang: event_param_clang}}

Ajax-Handling

FPC kann Ajax-Aufrufe automatisch erkennen und für sie das Caching deaktivieren. Da diese Erkennung rein auf frei durch den Client zu setzenden Daten basiert, ist sie optional und muss erst in der Konfigurationsdatei aktiviert werden:

auto_detect_ajax: true

Session-Handling

Sessions verkomplizieren das Handling des Caches. Aus diesem Grund wurde ihnen eine extra Seite gewidmet.

Inhalt

Nächstes Thema

Session-Handling

Diese Seite