Generator für den statischen Cache #

Diese Seite ist für Administratoren von Websites mit überwiegend öffentlichen, selten geänderten Seiten, die möchten, dass diese so schnell ausgeliefert werden, wie der Webserver eine Datei senden kann. Der statische Cache macht aus Seiten einfache Dateien, die der Webserver senden kann, ohne Exponential überhaupt zu starten. In 6.0 durchläuft der Generator Ihre Website so, wie es ein Besucher täte, zeigt während der Arbeit den Fortschritt, und die mitgelieferten Standards erzeugen jetzt einen funktionierenden Cache, statt still nichts zu erzeugen.

Warnung .htaccess bremst jede Anfrage. Sind .htaccess-Dateien erlaubt (AllowOverride alles außer None), geschweige denn genutzt, sucht Apache sie bei jeder Anfrage in jedem Verzeichnis des Pfads und liest und wertet sie aus, und die Ladezeiten der Seiten steigen drastisch (gemessen). Die einzige wirkliche Abhilfe ist, die Funktion für den virtuellen Host abzuschalten: AllowOverride None im virtuellen HTTPS-Host, und die Regeln in der Konfiguration des virtuellen Hosts selbst als mod_rewrite-Regeln. Das ist in Geschwindigkeitstests im Produktivbetrieb weit schneller und die Zeit für die Optimierung einer Produktivkonfiguration unbedingt wert. Stellen Sie sofort um: Übernehmen Sie die Regeln des Beispiels für einen virtuellen HTTPS-Host in Ihren virtuellen Host (mit dem statischen Cache auch staticcache_offload.conf), setzen Sie AllowOverride None, führen Sie apachectl configtest aus, laden Sie Apache neu und testen Sie die Website. Dieselben Regeln für andere Server: nginx, LiteSpeed, Caddy, IIS, Velocity (eingebaut); wohin Regeln für virtuelle Hosts in einem Control Panel gehören: Plesk, cPanel, DirectAdmin, ISPConfig. Unter LiteSpeed oder OpenLiteSpeed kann zusätzlich der Seiten-Cache des Servers anonyme Besucher und Crawler ohne PHP bedienen: Seiten-Caching mit LiteSpeed und OpenLiteSpeed.

Was Sie bekommen #

• Setup > Cache > Statischer Inhalts-Cache: Wählen Sie eine Website, setzen Sie ein Seitenlimit und eine Link-Tiefe, drücken Sie Neu erstellen und sehen Sie zu, wie jede Seite gespeichert wird. Eine Schaltfläche zum Anhalten beendet den Lauf vorzeitig.
• bin/php/makestaticcache.php: derselbe Durchlauf auf der Kommandozeile.
• Webserver-Regeln, die eine Anfrage aus der gespeicherten Datei beantworten, sodass eine zwischengespeicherte Seite einen Dateizugriff kostet.

In der Administrationsoberfläche erzeugen #

1. Öffnen Sie Setup > Cache.
2. Wählen Sie im Abschnitt Statischer Inhalts-Cache die zu erzeugende Website. Angeboten werden nur Siteaccesses, die jedem ausgeliefert werden können: Einer, der eine Anmeldung verlangt, wird ausgelassen, weil seine Seiten pro Benutzer sind.
3. Setzen Sie die Grenzen (unten) und drücken Sie Neu erstellen.
4. Lesen Sie die Live-Liste der gespeicherten Seiten. Drücken Sie Anhalten, um den Lauf zu beenden.

Ein Lauf leert zuerst die gespeicherten Seiten der Website (der Parameter purge des Streams, standardmäßig an), sodass gelöschte Seiten nicht liegen bleiben. Die Ansicht läuft unter der vorhandenen Richtlinie managecache von setup/cache; niemand, der keine Caches leeren kann, kann einen erzeugen.

Warum er die Website durchläuft #

Ein älterer Ansatz erweiterte CachedURLArray gegen die Tabelle der URL-Aliase der ganzen Datenbank. Auf einer Installation mit mehreren Websites bietet das jedem Siteaccess jeden Alias an, sodass eine Website nach den Seiten einer anderen gefragt wird und ihre eigenen verfehlt. Der Durchlauf beginnt an der eigenen Wurzel der Website und folgt nur Links, die die Website selbst schreibt, sodass er genau die Adressen besucht, die ein Besucher anfragen kann, in der Form, in der der Besucher sie anfragt. Jede geholte Seite wird gespeichert, sodass keine Seite zweimal angefragt wird.

Auf der Kommandozeile erzeugen #

php bin/php/makestaticcache.php --help --allow-root-user
php bin/php/makestaticcache.php --site=user --allow-root-user
php bin/php/makestaticcache.php --site=user --site=intranet --max-pages=500 --max-depth=6 --allow-root-user

--allow-root-user ist nur nötig, wenn Sie als root arbeiten. --site nennt einen Siteaccess und kann wiederholt werden; lassen Sie es weg, um jeden öffentlichen Siteaccess zu erzeugen. --max-pages (Standard 2500) und --max-depth (Standard 12) haben dieselben Grenzen wie das Formular der Administrationsoberfläche. --keep fügt zum Gespeicherten hinzu, statt es zu ersetzen; -f/--force wird aus Kompatibilitätsgründen angenommen (ein Lauf ersetzt immer, was er erzeugt, sofern nicht --keep angegeben ist). Die Ausgabe von --help oben wurde auf dieser Installation ausgeführt und führt genau diese Optionen auf.

Die Dateien ausliefern, ohne das CMS zu starten #

Dateien zu erzeugen ist die halbe Arbeit. Die andere Hälfte ist, dem Webserver zu sagen, dass er sie verwenden soll.

• Apache mit .htaccess: Kopieren Sie .htaccess_root_static statt .htaccess_root nach .htaccess. Es ist .htaccess_root plus die Regeln zum Entlasten, sodass das Zurückwechseln das Kopieren der anderen Datei darüber ist. Von der Konsole aus: ./console exp:setup:htaccess --static zeigt den Unterschied zu Ihrer jetzigen .htaccess, --static --force --apply wechselt (die alte Datei wird vorher nach var/backup/setup/<Zeit>/ gesichert), und ./console exp:setup:htaccess --force --apply wechselt zurück (.htaccess und config.php von der Konsole aus einrichten). Prüfen Sie die eine Zeile RewriteRule ^ - [E=EZ_VAR_SITE:site]: Der Wert ist site.ini [FileSettings] VarDir ohne das führende var/; eine Standardinstallation (var/site) braucht keine Änderung.
• Apache oder ein anderer virtueller Host: Ein vhost liest keine .htaccess; verwenden Sie dieselben Regeln aus doc/eng-us/examples/staticcache_offload.conf.

Eine Anfrage wird nur dann aus einer Datei beantwortet, wenn sie ein einfaches GET oder HEAD ist, keine Abfrage hat und keine Sitzung trägt. Formulare, Suchen und jeder Angemeldete erhalten immer die Live-Seite.

Einstellungen (settings/staticcache.ini, Block [CacheSettings]) #

Drei weitere Schlüssel der mitgelieferten Datei sind älter und unverändert:

Überschreiben Sie in settings/override/staticcache.ini.append.php oder pro Siteaccess.

Erneuern beim Veröffentlichen: jede einmal, parallel (01.10.2026) #

Mit eingeschaltetem statischem Cache erneuert ein Veröffentlichen die Seiten, die es berührt. Ein Veröffentlichen eines Produkts ohne Änderung verbrachte früher 4975 ms einer Anfrage von 6 s damit, 24 Seiten zu erneuern: Jede wurde zweimal über HTTP geholt (eine Prüfung mit HEAD, die die Website genauso vollständig ausgibt, dann das GET), eine nach der anderen, und zehn davon waren bei jedem Veröffentlichen 404. eZStaticCache::fetchPages() holt jetzt jede Seite einmal, mehrere gleichzeitig, und nur eine Antwort 2xx zählt. Dasselbe Veröffentlichen erneuert 14 Seiten in etwa 0,5 s und speichert dieselben 32 Dateien. Ohne curl wird das alte Prüfen und Holen verwendet.

executeActions() und der Cronjob-Teil staticcache_cleanup holen über dieselbe Methode. Ein Siteaccess mit einem PathPrefix speichert nur seine Startseite, die Seiten unter dem Präfix und Seiten, die PathPrefixExclude nennt: Eine Seite einer Website wird nicht mehr unter dem Präfix einer anderen Website angefragt.

Aktualisieren #

Die Standards haben sich geändert; siehe bc: Standards des statischen Caches.

Verwandte Seiten #

• Seiten vorladen, Befehl Vorlader für den Website-Cache
• Cache aus der Konsole (Gruppe statischer Cache von exp:cache), HTTP-Caching
• Velocity und der Opcode-Cache, Leeren von Caches, das Verzeichnisse beiseiteschiebt
• Checkliste zur Aktualisierung vom 1. und 2. Oktober 2026
• .htaccess und config.php von der Konsole aus einrichten: exp:setup:htaccess --static
• Changelog 6.0.15
• Chronik: September 2026, erste Hälfte: Caches, die Sie sehen können, Oktober 2026