WebsiteBaker Community Forum
WebsiteBaker Support (2.10.x) => General Help & Support => 
Hilfe & Support (deutsch) => Topic started by: evaki on January 04, 2018, 01:00:51 PM
-
Jo, das geht.
Aus unserem Sandkasten (sehr alt - kleine Anpassung, und geht noch immer):
Ins Template kommt
<?php
$cacheFile=$_SERVER['DOCUMENT_ROOT']."/pages".get_page_link(PAGE_ID).".html";
if (file_exists($cacheFile))
{
readfile($cacheFile);
exit;
} else { ob_end_clean();
ob_start();
}
?>
<!DOCTYPE html>
<head>
</head>
<body>
.........
</body>
</html>
<?php
$buffer = ob_get_contents();
ob_end_flush();
$fp = fopen($cacheFile, "w");
fwrite($fp, $buffer);
fclose($fp);
?>
Das wars schon. Der Cache ist nun global. Zusätze wie Ausnahmen, php-Files per htaccess unzugänglich machen etc. muß man sich selbst dazubauen. Wer Content erstellt, ändert und speichert, muß für diesen Zeitraum natürlich den Cache deaktivieren etc.
Geht nicht, hamwer nich, güldet nich 8-)
MfG. Evaki
-
Kleine Korrektur:
Es muß bei Contentänderungen nur die zugehörige statische Datei gelöscht bzw überschrieben werden.
-
Und das kann man mit
if (file_exists($cacheFile)) {
unlink($cacheFile);
}
realisieren. Mit 'nem Request wird dann die Datei neu geschrieben.
Mit 'nem "Schalter: Eingeloggt=ja/nein soll das auch ohne Admin-Modul funktionieren.
Erst wenn alle oder ausgewählte Seiten neu geschrieben werden sollen, sind weitere "Knöpfchen" angebracht. Kommt wie gesagt aus unserem experimentierenden Anwenderkreis. Eine vollständige Beschreibung habe ich bisher nicht gesehen oder bekommen. Bröckchenweise kommt da was, wenn man aufpasst.
Programmierer, die sich damit auskennen, werden sichs wahrscheinlich zusammenreimen können.
MfG. Evaki
p.s. Erforderliche dynamische Seiten werden anscheinend per Frame oder <object> eingebunden, wenn ich das richtig verstanden habe. Habs mal mit der "Suche" (mit Template "blanc" -ohne Menu) in einer statischen Datei ausprobiert, scheint zu funktionieren. Ob das auch barrierefrei ist, hab ich nicht geprüft.
-
Mittlerweile konnt ich mal reinschauen. Der Cache ist etwas abgewandelt und nun nur für eine bestimmte Zeit gültig (Vielschreiber z.B. kurz). Danach kann er über einen Request erneuert werden, Authorisierung und Löschen ist dabei nicht nötig. Anscheinend machen das einige über Cron. Wie der Request nun für alle Accessfiles (manuell wie über Cron + Code) ausgelöst wird, weiß ich aber leider immer noch nicht.
Das war wohl die letzte Info hierzu.
MfG. Evaki
-
War sicher zu erwarten, daß ich mich doch noch mal rege :-D
Nachdem ich mittlerweile ein wenig tiefer ins Thema eingetaucht bin, hab ich nun auch realisiert, daß ein CMS-spezifischer Cache -z.B in der Verwaltung/Steuerung- ein nicht leichter Akt ist, ganz abgesehen von den hier nicht berücksichtigten Ausnahmeregeln etc. Das ist was für "Gelernte".
Bin aber dennoch dran, da trotz der Ein-/Beschränkungen ein oder zwei Nutzer in JWD das nutzen möchten.
Daher Frage an den oder die Entwickler.
Läßt sich "rebuildAccessFiles" derart ändern, das der geparste html-content statt der page_id geschrieben wird? Mit der geänderten Dateierweiterung hätte man umgehend die statischen Files. Macht natürlich nicht viel Sinn bei vielen Seiten und mehrfachen Änderungen am Tag.
Ansonsten verhält sich der Cache im Moment so, daß nach Änderung einer Seite dieselbe per http aufgerufen werden muß, um sich so zu aktualisieren, trotz der hohen voreingestellten Zeit. WB läuft unter domain.tld/cms, die html-Dateien sind in root (alles noch in der Testphase).
MfG. Evaki
Edit: Im "Sandkasten" befinden sich auch Lösungsvorschläge wie z.B. Daten aus der DB modified_when mit $statuscachdatei['mtime'], also Unixtime, zu vergleichen, und daraus Aktionen abzuleiten.