Hallo Ortwin,
habe mir allgemein zum Setzen von HTTP-Header ein paar Gedanken gemacht.
Die einfachste Lösung wäre, eine neue Konfiguration zu definieren, die dann eingreift.
Kann mir vorstellen, eine neue Konfoguration in contenido/includes/config.misc.php zu definieren:
Code: Alles auswählen
// per default keine callbackfunktion für den puffer
$cfg['frontend']['ob_callback'] = '';
Dies kann man dann im Mandatenverzeichnis in der config.local.php für den Mandanten konfigurieren:
Code: Alles auswählen
// gzip komprimierung für den puffer
$cfg['frontend']['ob_callback'] = 'ob_gzhandler';
// oder eigene funktion für den puffer
$cfg['frontend']['ob_callback'] = 'my_ob_callback';
Das müsste dann in der front_content.php entsprechend angepasst werden.
Wenn wir schon bei dem Thema HTTP-Header sind:
Es gab letztens ein Thema (
http://forum.contenido.org/viewtopic.php?f=62&t=30099), wegen dem in der Session-Klasse gesetzten ETag.
Vielleicht sollte man das Setzen der Header grudsätzlich überdenken. Eine granulare Steuerung der zu setzenden HTTP-Header wäre meiner Meinung nach angebracht.
Dafür bräuchte man zum einen eine Möglichkeit, irgendwo solche HTTP-Header zu definieren, und ein Response-Objekt, das sich um die Ausgabe der Header kümmert.
Cool wäre es, wenn man solche Sachen an bestimmten Stellen konfigurieren könnte. Ich denke da z. B. an Kategorien oder Seiten.
Man konfiguriert die HTTP-Header Ausgabe in einer Kategorie, dies erbt sich auf alle Unterkategorien und an alle darin enthaltenen Seiten. Man kann da sogar viel weiter gehen, und dem User weitaus mehr Steuerungsmöglichkeiten anbieten, Steuerung des Caches für Kategorien/Artikel, das Hinzufügen von zusätzlichen Metatags, die Möglichkeit, bestimmte zusätzliche Tags im head-Bereich auszugeben, wie z. B. das Einbinden von JavaScript-/CSS-Files. Wenn man für jedes einzelne Feature eigene Formularfelder anbieten, wird die Oberfläche mit vielen Controls zugemüllt und der User hat viel zum Klicken.
Wenn man dafür eine Textarea bereitstellt, so wie die Eingabe der Modulcodes, könnten solche Einstellungen in Kategorien oder Artikel definiert werden. Dann sind wir aber an dem Punkt, wo man sich überlegen sollte, wie man das zur Verfügung stellt. Erlaubt man dem User, für solche Konfigurationen normalen PHP-Code anzugeben, ist die Gefahr groß, dass da viel schief geht.
Will man das Risiko von Fehlern, die durchaus verherende Folgen haben können, minimieren, wäre alternativ eine eigene Scriptingsprache denkbar. Dies ist aber auch nicht so ideal, weil man sich da wieder irgendeine Syntax aneignen muss. Vielleicht ist hier
YAML Ain’t Markup Language eine mögliche Alternative. Die Syntax ist nicht kompliziert, das kann sich jeder schnell aneignen. Eingegebener Markup lässt sich mit Parsern in PHP-Code umwandeln, ist der Inhalt Fehlerhaft, kommt auch kein Fehlerhafter PHP-Code raus. Damit hätte man die Möglichkeit, den Usern ein Konfigurationswerkzeug zur Verfügung zu stellen.
Der User gibt folgenden Markup ein:
Code: Alles auswählen
http-header:
- value: 'Cache-Control: no-cache, must-revalidate'
- value: 'Expires: Sat, 26 Jul 1997 05:00:00 GMT'
- value: 'Content-Type: text/html'
Der YAML Parser generiert daraus folgenden PHP-Code
Code: Alles auswählen
$arr['http-header'][0]['value'] = 'Cache-Control: no-cache, must-revalidate';
$arr['http-header'][1]['value'] = 'Expires: Sat, 26 Jul 1997 05:00:00 GMT';
$arr['http-header'][2]['value'] = 'Content-Type: text/html';
Danach ist es eine leichte Aufgabe, aus der Konfiguration die HTTP-Header zu setzen oder jede andere Art der Konfigurationen entsprechend zu verarbeiten.
Gruß
Murat
