meltemi wrote:Wenn eine versteckte Seite (CMSimple-Sprachgebrauch) auf einer anderen Seite, zB in deren Seitenleiste, angezeigt wird, und wenn zugleich ein Teil davon per CSS dem Besucher vorenthalten wird, aber für Google sichtbar ist, verstößt das gegen Googles Richtlinien. Punkt.
Stimmt.
meltemi wrote:Auch für Webmaster ohne Täuschungsabsicht ist das Risiko groß, wegen sowas aus dem Google-Index zu fliegen. Darauf wollte ich hinweisen.
Zukünftig werde ich hier auf solche gut gemeinten Hinweise verzichten. Persönlich ist es mir nämlich völlig wurscht, wenn Google irgendwelche fremden Websites aus dem Index entfernt, egal ob BMW oder Bär.
Oh, ich glaube da liegt ein Missverständnis vor. Ich wollte nicht Deine Aussage korrigieren, dass es falsch sei Seiteninhalte per CSS unsichtbar zu machen (denn das stimmt ja), sondern wollte allgemein auf die Verwendung von versteckten Seiten eingehen. Mir schien (und scheint), dass Albert
grundsätzliche Bedenken bzgl. versteckten Seiten hatte, da die ja nicht im Menü verlinkt werden. Und die wollte ich ausräumen.
Grundsätzlich sind mir gut gemeinte Hinweise immer willkommen, und ich denke, auch anderen geht das so.
meltemi wrote:Kannst Du bitte mal eine (gekürzte) template.htm posten mit dem erforderlichen Beispiel-Code zur Cache-Steuerung verrückter Weise ganz am Ende? Mir geht's vor allem darum: Wo genau und wie ganz am Ende?
Was nun wirklich konkret gemacht werden muss, ist mir noch immer nicht klar. Ich versuche im Lauf des Tages schlauer zu werden. Aber grundsätzlich meinte ich mit "ganz am Ende" folgendes:
Code: Select all
</body>
</html>
<?php
// setzte die benötigten Header-Felder
?>
Warum ganz am Ende? Einfach deshalb, weil es sein könnte, dass ein Pluginaufruf im Template gezielt das Skript abbricht (siehe z.B. Sitemapper), und etwas anderes als das ausgefüllte Template ausliefert, oder gar unabsichtlich das Skript mit einem Fehler beendet wird (=> weiße Seite). In diesen Fällen sollten die Header im Zweifel besser nicht gesetzt werden.
meltemi wrote:Sowohl die CMSimple_XH-Startseite als auch die CMSimple_4-Startseite haben dieses gähnend alte Verfallsdatum, [...]
Stimmt -- da stimmt was nicht. Danke für den Hinweis; das schau ich mir gleich näher an.
PS: Die Cache-Control, Expires und Pragma Headerfelder werden gesendet, sobald eine Session gestartet wird (bei CMSimple_XH 1.6+ also immer). Was nun der Inhalt dieser Headerfelder ist, hängt zunächst einmal von der ini Direktive session.cache_limiter ab; die Voreinstellung ist "nocache", und das setzt folgende Header:
Code: Select all
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Hier wird also ganz gezielt das Caching unterbunden, was durchaus Sinn ergibt, da die Inhalte der Session ja durchaus auch das erzeugte HTML beinflussen können.
Man kann die Voreinstellung "nocache" nun leicht ändern (am einfachsten wohl mit der Funktion
session_cache_limiter). Wenn ich auf "public" umstelle, dann funktioniert das Caching von selbst (die Dauer ergibt sich aus dem Wert von session.cache_expire; Standardwert "180" Minuten). Aber das gibt natürlich schon die ersten Probleme im Adminbereich: Änderung an der Seite wird gespeichert, und auch angezeigt; nach Wechsel in den View-Mode sieht man die Änderung aber nicht; Zurück in den Edit-Mode, wo dann die Änderung ebenfalls nicht mehr sichtbar ist, da nun ein GET-Request erfolgt, der auf den Cache zurück greift, während das Ergebnis des Speicherns (ein POST-Request) eben nicht aus dem Cache kommt.
Im Adminmodus erscheint das Caching also nicht sinnvoll. Das Caching nun für Frontend und Backend unterschiedlich zu handhaben, ist aber zumindest nicht ohne. Das Problem: um festzustellen, ob der User als Admin angemeldet ist, muss zunächst die Session gestartet werden, da dort diese Info verfügbar ist. Nach dem Start der Session kann aber session_cache_limiter() nicht mehr aufgerufen werden (bzw. der Aufruf bewirkt nichts mehr) -- da beißt sich also die Katze in den Schwanz.
Es bliebe noch die Möglichkeit am Ende des Templates die entsprechenden Headerfelder manuell zu setzen, falls der User nicht als Admin angemeldet ist, also etwa:
Code: Select all
</html>
<?php
if (!XH_ADM) {
$expire = 3 * 60 * 60;
$expires = gmdate('D, d M Y H:i:s', time() + $expire) . ' GMT';
$mod = gmdate('D, d M Y H:i:s', filemtime($pth['file']['content']) + $expire) . ' GMT';
header('Cache-Control: public, max-age=' . $expire);
header('Expires: ' . $expires);
header('Last-Modified: ' . $mod);
header('Pragma:');
}
Allerdings würde ich nicht ausschließen, das ein solches Caching eben doch hier und da Probleme verursachen könnte; zumindest müsste man gründlichst testen, bevor man das auf einer echten Website einsetzt.