Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
|
admin:caching [2026/05/06 14:21] oesi angelegt |
admin:caching [2026/05/22 12:49] (aktuell) oesi |
||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| - | ====== Caching Prevention ====== | + | ====== Server Caching deaktivieren ====== |
| + | FH-Complete unterstützt versionierte JavaScript-URLs, um Browser-Caching nach Deployments zu umgehen. Dadurch lädt der Browser nach einem Deployment automatisch neue JS-Dateien statt veraltete Dateien aus dem Cache zu verwenden. Dazu gibt es die in der Datei /var/www/application/config/javascript.php die Option: | ||
| + | <code> | ||
| + | $config['use_fhcomplete_build_version_in_path'] = true; | ||
| + | </code> | ||
| + | Beispiel: | ||
| + | /public/js/components/foo.js wird automatisch zu /public/2026030501/js/components/foo.js | ||
| + | die Build-Version (2026030501) stammt aus: /var/www/application/config/config.php - $config['fhcomplete_build_version'] | ||
| - | FH-Complete bietet die Möglichkeit das Caching Verwalten des Webbrowsers zu beeinflussen. | + | Apache Rewrite |
| - | Da es vermehrt zu Problemen mit dem Cachingverhalten des Webbrowsers kommt wurde ein Mechanismus implementiert der es ermöglicht nach Deployments Sicherzustellen dass User die neuen JS Dateien vom Server laden und nicht mit alten / gecachten Dateien arbeiten die teilweise über Tage hinweg im Cache bleiben. | + | Damit die versionierten URLs funktionieren, muss Apache die Build-Version intern wieder auf den echten Dateipfad auflösen. Eine entsprechende Rewrite Regel muss der Apache VHosts Konfiguration hinzugefügt werden. Alternativ kann dies auch über die .htaccess Datei in /var/www/public/ erfolgen (.htaccess_sample) |
| - | Dazu gibt es unter application/config/config.php den Eintrag | + | <code> |
| - | <code>fhcomplete_build_version</code> | + | <Directory /var/www/public> |
| + | Options -Indexes +FollowSymLinks | ||
| + | AllowOverride None | ||
| + | Require all granted | ||
| - | Diese wird als Parameter an JS Includes gehängt. Nach einem Deployment kann die Build Version angepasst werden auf einen neuen Wert. Dadurch wird sichergestellt dass die Dateien neu vom Webbrowser geladen werden und nicht mit veralteten (gecachten) Dateien gearbeitet wird. | + | RewriteEngine On |
| + | RewriteCond %{REQUEST_FILENAME} !-f | ||
| + | RewriteCond %{REQUEST_FILENAME} !-d | ||
| + | RewriteRule ^[0-9]{10}/(.*)$ $1 [L] | ||
| + | RewriteCond %{REQUEST_URI} ^(.*?)/public/index.ci.php/ | ||
| + | RewriteRule ^index.ci.php/(.*)$ %1/index.ci.php/$1 [R=303,L] | ||
| + | </Directory> | ||
| + | </code> | ||
| + | Beispiel intern: | ||
| + | /public/2026030501/js/foo.js wird zu /public/js/foo.js | ||
| + | Die URL im Browser bleibt dabei unverändert. | ||
| - | Zusätzlich kann dieses Verhalten auch für Dynamisch nachgeladene Javascripts aktiviert werden. | + | Wichtig bei JavaScript Imports |
| - | Dazu gibt es die in der Datei application/config/javascript.php die option <code>use_fhcomplete_build_version_in_path</code> Wenn diese auf true gesetzt wird, dann wird die fhcomplete-build-version automatisch bei Imports in den Pfad geschrieben was das Caching durch diverse Browser verhindert. | + | Imports dürfen nicht aus dem public-Pfad heraus und anschließend wieder nach public hinein navigieren. |
| - | Der Pfad /public/js/DialogLib.js wird dann zu /public/2026030501/js/DialogLib.js | + | Problematisch: |
| - | Durch das Rewriting des Apache wird der Pfad zum korrekten File aufgelöst. | + | import Foo from '../../../../../../public/js/foo.js'; |
| + | Dies kann bei aktivem URL-Rewrite zu fehlerhaften URLs wie: | ||
| + | /public/public/js/foo.js | ||
| + | führen. Stattdessen sollten absolute oder saubere relative Imports verwendet werden: | ||
| - | Damit die Konfiguration funktioniert muss das Apache Rewrite für den Public Ordner aktiviert werden. Das erfolgt entweder über die .htaccess Datei im Public Ordner ->.htaccess_sample oder direkt in der /etc/apache/sites-enabled direktive der Seite. | + | import Foo from '/public/js/foo.js'; |
| - | Für die .htaccess Variante muss im Apache VHost die Option "AllowOverride FileInfo" gesetzt sein. Für produktiv Syste sollte kein htaccess sondern hat die Anweisung direkt im VHost stehen. | + | Dadurch bleiben die Imports unabhängig von der Build-Version stabil. |
| - | + | ||
| - | Achtung: Imports dürfen nur JS Files aus dem Public Ordner importieren und keine die Ausserhalb liegen da es sonst zu Problemem kommt. Vorsicht bei Pfaden die aus public heraus und wieder hinein zeigen. Das sollte nicht passieren da dies zu Problemen führt. Beispiel "../../../public/js/lehre/foo.js" | + | |