Benutzer-Werkzeuge

Webseiten-Werkzeuge


admin:caching

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

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ösenEine 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ängtNach 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 (gecachtenDateien 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ührenStattdessen 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 kommtVorsicht 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"​+
/var/www/wiki/data/attic/admin/caching.1778070112.txt.gz · Zuletzt geändert: 2026/05/06 14:21 von oesi