WordPress Cookies und PHP Sessions – Alles was du wissen musst

Cookies wurden erstmals 1994 von einem Computerprogrammierer namens Lou Montulli erfunden. Ohne sie wäre das Web heute ein ganz anderer Ort. Ob du dich in das Backend deiner WordPress Seite einloggst oder ein lästiges Popup-Fenster schließt, du benutzt und interagierst jeden Tag mit Cookies (auch wenn du es nicht merkst).

Inzwischen hast du wahrscheinlich schon erraten, dass wir mit Cookies die Cookies meinen, die dazu dienen, wichtige Besucherinformationen auf einer Webseite zu speichern, und nicht die leckeren Schoko-Chips. 🍪

Heute tauchen wir in das manchmal verwirrende Thema der Cookies und PHP-Sessions ein. Insbesondere alles, was du darüber wissen musst, wie WordPress sie benutzt, zusammen mit einigen allgemeinen Problemen, die du (besonders als Entwickler) beachten solltest, wenn es darum geht, deine Webseite zu hosten, eigenen Code zu schreiben oder ein Plugin eines Drittanbieters zu benutzen. Unserer Meinung nach wird dieses Thema nicht genug diskutiert.

• Arten von Cookies
• Wie WordPress Core Cookies verwendet
• Wie WordPress-Plugins und Themes von Drittanbietern Cookies verwenden
• Cookies und WordPress-Caching
• Wie man Cookies sieht und löscht
• GDPR und Cookies
• PHP-Sitzungen

Arten von Cookies

Es gibt zwei verschiedene Arten von Cookies, die üblicherweise gesetzt werden: Session-Cookies und dauerhafte Cookies.

Session-Cookies

Session-Cookies, auch bekannt als vorübergehende Cookies, sind temporär. Sie haben kein Verfallsdatum und speichern nur Informationen darüber, was der Nutzer während einer einzelnen Sitzung tut. Eine Session ist einfach ein zufällig generierter/eindeutiger Wert, der zugewiesen wird, wenn jemand eine Webseite besucht. Session-Cookies werden vorübergehend im Speicher abgelegt und automatisch entfernt, wenn der Browser geschlossen wird oder die Sitzung endet.

Leseempfehlung: Wie du das PHP-Speicherlimit in WordPress verbesserst.

Dauerhafte Cookies

Dauerhafte Cookies, wie du vielleicht schon vermutet hast, sind solche, die ein Verfallsdatum enthalten. Diese dauern viel länger und werden auf der Festplatte gespeichert, bis sie ablaufen oder vom Benutzer manuell gelöscht werden. Diese werden manchmal auch als „Tracking-Cookies“ bezeichnet, da dies die Arten von Cookies sind, die Google Analytics, AdRoll, Stripe usw. alle verwenden.

Unser Kinsta-Affiliate-Programm ist ein weiteres Beispiel. Ein 60-Tage-Cookie wird in den Browser des Nutzers gesetzt, wenn er auf einen Partnerlink klickt. Dadurch wird sichergestellt, dass der Werber eine angemessene Gutschrift erhält, auch wenn die Person ihren Browser mehrmals geschlossen und wieder geöffnet hat.

Wie WordPress Core Cookies verwendet

Wenn wir uns auf den Kern von WordPress beziehen, meinen wir einfach die Dateien, aus denen das Open Source Projekt besteht, bevor wir irgendwelche Plugins oder Themes von Drittanbietern installieren. Es ist WordPress in seinem natürlichen Zustand, wie wir es gerne nennen.

Nun, da du die Grundlagen dessen kennst, was ein Cookie ist und die verschiedenen Typen, lass uns einen Blick darauf werfen, warum und wie der WordPress Core sie benutzt, um all die Magie hinter den Kulissen geschehen zu lassen. Lustige Tatsache: Cookie wurde ursprünglich von dem Begriff „magic cookie“ abgeleitet.

Der WordPress Core verwendet Cookies für zwei verschiedene Zwecke:

1. Login Cookies

Login-Cookies enthalten Authentifizierungsdetails und werden verwendet, wenn ein Benutzer sich in das WordPress Admin-Dashboard einloggt. Gemäß dem WordPress-Codex werden einige verschiedene Session-Cookies gesetzt:

• Beim Einloggen verwendet WordPress das wordpress_[hash]-Cookie, um die Authentifizierungsdaten zu speichern (beschränkt auf den Bereich /wp-admin/).
• Nach dem Einloggen setzt WordPress das wordpress_logged_in_[hash]-Cookie. Dieser zeigt an, wann du eingeloggt bist und wer du bist..

Wenn du versuchst, auf das Backend deiner Webseite von WordPress zuzugreifen, wird geprüft, ob die beiden obigen Cookies existieren und noch nicht abgelaufen sind. Dies erlaubt es dir, den wp-login.php Bildschirm auf magische Weise zu umgehen. 😉

WordPress setzt auch wp-settings-{time}-[UID] Cookies. Die ID ist deine Benutzer-ID aus der WordPress-Benutzerdatenbank-Tabelle. Diese speichert persönliche Dashboard- und Admin-Interface-Einstellungen.

2. Cookies kommentieren

Standardmäßig werden Cookies gesetzt, wenn jemand einen Blog-Eintrag kommentiert (mit einer Gültigkeitsdauer von 347 Tagen). Wenn sie später wiederkommen, müssen sie also nicht alle Informationen noch einmal ausfüllen. Die folgenden drei Cookies werden gespeichert:

• comment_author_[hash]
• comment_author_email_[hash]
• comment_author_url_[hash]

Da sich die Datenschutzbestimmungen aufgrund von GDPR in letzter Zeit geändert haben, wurden vom WordPress-Core neue Tools eingeführt, um sicherzustellen, dass die Nutzer sich für das Setzen dieser Cookies entscheiden können. Diese Einstellung kann, falls nicht bereits gesetzt, unter „Einstellungen → Diskussion“ in deinem WordPress-Admin-Dashboard aktiviert werden. Aktiviere die Option „Cookies für Kommentare anzeigen opt-in“. Das beliebte Akismet-Plugin erlaubt es dir auch, einen Datenschutzhinweis anzuzeigen.

Wie WordPress-Plugins und Themes von Drittanbietern Cookies verwenden

Genauso wie WordPress für bestimmte Funktionen Cookies verwendet, setzen auch Plugins und Themes von Drittanbietern, die du installierst, Cookies. Die meisten von ihnen verwenden eine Kombination aus Browser-Cookies und Datenbankzeilen, die in der Tabelle wp_options oder ihrer eigenen benutzerdefinierten Tabelle gespeichert sind. Das liegt daran, dass WordPress stateless ist.

Eine stateless App ist ein Anwendungsprogramm, das die in einer Session erzeugten Client-Daten nicht für die nächste Session mit diesem Client speichert. Jede Session wird so ausgeführt, als wäre es das erste Mal und die Antworten sind nicht von den Daten einer vorherigen Session abhängig. – TechTarget

Mit den neuen Datenschutzgesetzen ist es wichtiger denn je, wirklich zu verstehen, welche Cookies gesetzt werden und ob sie eine Möglichkeit für deine Besucher bieten, sich anzumelden. Tipp: Nicht alle Cookies erfordern ein Opt-in. Lies unseren ausführlichen Beitrag über GDPR, um ein besseres Verständnis der neuen Anforderungen zu bekommen.

Hier sind nur ein paar der vielen Beispiele dafür, wofür Cookies verwendet werden:

• Wenn du ein Popup-Fenster auf deiner WordPress Seite hast und ein Besucher es schließt, wird normalerweise ein Cookie gesetzt, so dass es nicht mehr zurückkommt.
• Artikel, die auf deiner Webseite in den Warenkorb gelegt wurden. Ein Cookie wird gespeichert, damit der Einkaufswagen deine Produkte behält, während du dich weiter auf der Webseite umschaust.
• IP Geolocation-Features speichern möglicherweise die IP-Adresse und die Breiten-/Längen-Koordinaten des Besuchers, der auf der Webseite surft. Dies wird typischerweise verwendet, um bestimmte Inhalte in einer bestimmten Region anzuzeigen oder vielleicht sogar den Benutzer auf eine andere Unterseite umzuleiten.
• Verfolgen der Aktivität über Klicks mit einem Linkverkürzer wie dem PrettyLinks-Plugin.
• Das Newsletter-Plugin könnte ein Cookie für Benutzer setzen, wenn diese sich bereits angemeldet haben, dies gibt die Möglichkeit, die Newsletter-Box komplett auszublenden.

Bei jeder Aktion oder Opt-in auf einer WordPress Seite wird normalerweise hinter den Kulissen ein Cookie im Browser gesetzt. Das Ziel ist es natürlich, das Browser-Erlebnis zu verbessern oder durch Verifizierung zusätzliche Funktionen anzubieten.

WooCommerce-Cookies

E-Commerce-Plugins wie z.B. WooCommerce haben normalerweise ihre eigenen zusätzlichen Cookies, die sie setzen, so dass Käufer ganz einfach Dinge in ihren Warenkorb legen, für später speichern können, wenn sie zur Kasse gehen, und sich in ihr Konto ein- und ausloggen können.

Um den Überblick über die Daten im Warenkorb zu behalten, setzt WooCommerce die folgenden drei Cookies (in den Cookies werden keine persönlichen Informationen gespeichert):

• woocommerce_cart_hash
• woocommerce_items_in_cart
• wp_woocommerce_session_

Die ersten beiden Cookies enthalten Informationen über den Warenkorb und helfen WooCommerce einfach zu wissen, wenn sich die Daten des Warenkorbs ändern. Das dritte Cookie wp_woocommerce_session_ enthält einen eindeutigen Code für jeden Kunden, der einem Eintrag in der benutzerdefinierten Tabelle wp_woocommerce_sessions in der Datenbank entspricht.

Die wp_commerce_session_-Daten waren vorher in der wp_options-Tabelle gespeichert, aber sie wurden in WooCommerce 2.5 in eine eigene benutzerdefinierte Tabelle verschoben, als sie einen neuen Session-Handler einführten. Damit sollte die Performance, Skalierbarkeit und Verwaltung der Sessions verbessert werden. Sonst landet man schnell bei einer aufgeblähten wp_options-Tabelle, die man aufräumen muss.

Easy Digital Download Cookies

Easy Digital Downloads verwendet standardmäßig WP_Session, was eine Kombination aus Browser-Cookies und Datenbankzeilen ist, die in der wp_options-Tabelle gespeichert sind. Unten ist der Cookie, den es setzt:

• edd_items_in_cart

Cookies und WordPress-Caching

Wenn es um den WordPress-Cache geht, wird es hier knifflig. Caching ist im Wesentlichen ein Prozess, bei dem Ressourcen aus einer Anfrage gespeichert und für nachfolgende Anfragen wiederverwendet werden. Im Grunde genommen reduziert es den Arbeitsaufwand, der zur Erzeugung einer Seitenansicht erforderlich ist. Dies ist zwar für die Leistung von Vorteil, verursacht aber ein Problem, wenn es um Cookies geht.

Warum? Weil Cookies dazu da sind, eine bestimmte Aktion auszuführen, z.B. den Einkaufswagen gefüllt zu halten, während du dich auf einer WooCommerce-Webseite umschaust. Wenn eine Seite jedoch aus dem Cache bedient wird, tun weder PHP noch die Datenbank etwas, sondern der Server gibt einfach eine statische Kopie der Seite aus.

Was kann man also tun?

1. JavaScript verwenden

Die erste Möglichkeit wäre, JavaScript zu verwenden und den Inhalt einer Seite dynamisch zu aktualisieren. Im Grunde hast du HTML-Platzhalter und verwendest JavaScript, um Informationen über eine API oder einen Ajax-Aufruf einzuziehen.

Ein Beispiel wäre, eine Liste von Beiträgen in der WordPress Sidebar zu laden, indem man JavaScript benutzt, um eine Liste von Beiträgen über die wp-api zu holen und sie dann in der Sidebar zu rendern. In diesem Szenario könntest du die Liste der Beiträge aktualisieren, ohne die Seite aus dem Cache zu löschen, da die Daten dynamisch generiert werden.

Das ist aber nicht ideal, es ist immer besser, wenn möglich, aus Performancegründen im Cache zu speichern. Aber wenn du möchtest, dass ein Teil des Inhalts dynamisch bleibt, während die Seite selbst statisch bleiben kann (aus dem Cache bedient), ist das eine Möglichkeit, es zu tun – benutze JavaScript, um den Inhalt für diesen Teil der Seite dynamisch über einen API/ajax-Aufruf herunterzuladen. Wenn du jedoch keinen WordPress-Entwickler beauftragen kannst, um eine maßgeschneiderte JavaScript-Lösung oder eine Erweiterung eines Plugins zu erstellen, ist diese Option normalerweise nicht praktikabel.

2. Admin-Ajax Calls benutzen

admin-ajax.php kann nicht gecached werden, daher könntest du Admin-ajax-Aufrufe verwenden. Ein gutes Beispiel dafür ist das No Cache AJAX Widgets Plugin. Es macht Admin-ajax-Aufrufe und muss sich daher keine Gedanken über Konflikte mit Caching-Lösungen auf Serverebene oder von Dritten machen.

Allerdings ist dieser Weg, genau wie bei JavaScript, für den durchschnittlichen Benutzer normalerweise nicht machbar. Es kann auch zu anderen Performance-Problemen führen, wie z.B. hohe Admin-ajax-Nutzung und viele ungecachte Anfragen.

3. Seiten aus dem Cache ausschließen (wenn der Cookie vorhanden ist)

Wenn du nicht den Weg über JavaScript oder Admin-ajax gehen kannst, ist es am besten, Seiten vom Caching auszuschließen, wenn ein bestimmtes Cookie vorhanden ist. Dies empfehlen wir in der Regel, besonders wenn du hochdynamische Webseiten wie WooCommerce und Easy Digital Downloads betreibst.

Bei Kinsta sind bestimmte WooCommerce- und Easy Digital Downloads-Seiten wie Warenkorb, Mein Konto und Kasse automatisch vom Caching ausgeschlossen. Es gibt eine Regel auf Serverebene, die dafür sorgt, dass Benutzer den Cache automatisch umgehen, wenn das Cookie woocommerce_items_in_cart oder das Cookie edd_items_in_cart erkannt wird, um einen reibungslosen und synchronisierten Checkout-Prozess zu gewährleisten.

Wir warten auch auf die zugehörigen eingeloggten Cookies und stellen den Cache so ein, dass er umgangen wird, wenn wir feststellen, dass sich jemand in WordPress eingeloggt hat. Dadurch wird verhindert, dass das Backend-Dashboard versehentlich zwischengespeichert wird.

Standardmäßig schließen wir das wp_woocommerce_session_-Cookie nicht vom Caching aus. Die meisten WooCommerce-Webseiten haben unserer Erfahrung nach keine Probleme. Dies verbessert auch die Leistung, indem es dein Cache-HIT-Verhältnis erhöht, während weniger PHP-Worker eingesetzt werden.

Da es jedoch viele verschiedene WordPress Theme- und Plugin-Konfigurationen gibt, können wir das wp_woocommerce_session_-Cookie bei Bedarf aus dem Cache ausschließen. Wende dich einfach an unser Support Team. Das Ergebnis ist, dass sobald ein Benutzer ein Produkt in seinen Warenkorb legt, alle nachfolgenden Anfragen nicht mehr aus dem Cache bedient werden, was die Nutzung von PHP-Workern erhöht.

Wenn Sie eine benutzerdefinierte Seite aus dem Cache ausschließen möchten, können Sie gerne ein Ticket bei unserem Support-Team eröffnen. Auch hier müssen Sie vorsichtig sein, wenn es um Ausschlüsse geht. Zu viele nicht gecachte Seiten könnten die Leistung wirklich verschlechtern. Sehen Sie sich unsere Do’s and Don’ts für das Hosting von WordPress-Mitgliedsseiten an.

Wie man Cookies sieht und löscht

Es ist einfach, Cookies auf einer Webseite zu sehen und zu löschen. Um zu sehen, welche Cookies auf einer bestimmten Webseite gesetzt sind, browse zu dieser Webseite und klicke auf das kleine Vorhängeschloss-Symbol oben. Dann klicke auf „Cookies“.

Klicke dann auf den Ordner dieser Webseite. In dem Beispiel unten siehst du, dass wir ein paar WooCommerce-Cookies gesetzt haben, sowie den wordpress_logged_in_[hash] Cookie. Du kannst auch die Ablaufzeit sehen und ob es ein dauerhafter Cookie oder ein Session-Cookie ist (wenn die Browsing-Session endet).

Um ein Cookie zu entfernen, klicke einfach auf ein einzelnes Cookie und klicke auf die Schaltfläche „Entfernen“. Du kannst dies auch auf der Ordnerebene oder in den Chrome DevTools tun.

Das Löschen von Cookies kann dir auch helfen, den 304 Fehler zu beheben.

Alternativ kannst du auch alle Cookies in deinem Browser suchen oder löschen.

GDPR und Cookies

GDPR ist ein neues Datenschutzgesetz, das am 25. Mai 2018 in Kraft getreten ist. Es wurde entworfen, um den Bürgern die Kontrolle über ihre persönlichen Daten zurückzugeben. Wir empfehlen dir dringend, unseren ausführlichen Post zu lesen: Der Überblick über die Einhaltung des GDPR, falls du das noch nicht getan hast. Dies ist ein Thema, das sich nicht in einem Absatz zusammenfassen lässt!

Hier ist ein Beispiel für eine Änderung, die wir bei Kinsta vorgenommen haben, um die Einhaltung des neuen Gesetzes zu unterstützen. Wenn du unsere Webseite zum ersten Mal besuchst, hast du es vielleicht schon gesehen, du wirst am unteren Rand des Bildschirms mit der Aufforderung „Cookies akzeptieren“ begrüßt. Der Grund dafür ist, dass wir jetzt gesetzlich verpflichtet sind, den Nutzern eine Möglichkeit zur Verfügung zu stellen, sich gegen das Setzen von Cookies zu entscheiden. Vorbei sind die Zeiten, in denen man einfach machen konnte, was man wollte, ohne die Nutzer über die Datensammlung zu informieren.

Wenn du auf „Cookies akzeptieren“ klickst, werden dann alle Cookies für den Nutzer gesetzt. Wenn du auf „Cookie-Einstellungen“ klickst, bieten wir dir nun eine Möglichkeit an, dich für die gewünschten Cookies ein- und auszuschalten.

Ziemlich raffiniert, oder? Unsere Cookie-Lösung wurde von unseren Entwicklern selbst entwickelt, aber hier sind ein paar hilfreiche GDPR WordPress-Plugins, die dir helfen können, etwas Ähnliches zu erreichen. Auch hier sind Cookies nur ein kleiner Teil davon, vollständig GDPR-konform zu werden.

PHP-Sitzungen

PHP-Sessions ist eine Alternative zum Standard-Cookie-Ansatz. Es ist immer noch ein Cookie, aber es heißt PHPSESSID und wird normalerweise im Verzeichnis /tmp/ auf dem Webserver selbst gespeichert. Die Art und Weise, wie der Server weiß, dass er eine bestimmte Session mit einer bestimmten Anfrage verknüpft, ist, dass es auch in einem HTTP-Cookie gespeichert wird.

Dies kann man auch unter dem HTTP-Header einer Webseite sehen.

Eine PHP-Sitzung ist ähnlich wie eine normale Sitzung, die endet, wenn der Benutzer seinen Browser schließt.

Das Problem mit PHP-Sessions liegt in der Performance und im Caching. Die Informationen, die im Browser-Cookie gespeichert sind, müssen bei jeder Anfrage hin- und herspringen, damit der Server weiß, wer der Benutzer ist. Das bedeutet, dass bei Webseiten, die PHPSESSID verwenden, der Host die PHPSESSID so einstellen müsste, dass der Cache umgangen wird. Das Ergebnis ist jedoch, dass PHPSESSID zu 100% umgangen werden müsste, da im Gegensatz zu wordpress_logged_in die PHPSESSID bei jeder einzelnen PHP-Anfrage gesetzt wird.

Stellt euch also vor, dass das wordpress_logged_in zu 100% der Zeit gesetzt werden müsste, damit die Login-Funktionalität funktioniert. Das bedeutet, dass sogar ausgeloggte Benutzer den Cookie haben müssten und es müsste für sie einzigartig sein. Stell dir vor, das wäre nötig, damit das WordPress-Anmeldesystem funktionieren konnte. In diesem Szenario müsste jede einzelne Seitenansicht den Cache umgehen, damit das wordpress_logged_in-Cookie sowohl für eingeloggte als auch für ausgeloggte Benutzer korrekt gesetzt ist.

Das ist das Problem bei der Verwendung von PHPSESSID. Da es bei jeder einzelnen PHP-Anfrage generiert wird, müsste der Host, wenn eine Webseite auf PHPSESSID-Cookies angewiesen ist, PHPSESSID so einstellen, dass der Cache zu 100% umgangen wird. Andernfalls werden die PHPSESSID’s gecached und es versaut alle Funktionen, die darauf angewiesen sind.

Wir raten davon ab, PHP-Sessions zu benutzen und sie werden in unserer Kinsta-Umgebung normalerweise nicht funktionieren. PHP-Sessions haben auch andere Sicherheitsaspekte, die berücksichtigt werden sollten.

Wenn du Code mit session_start auf deiner Webseite siehst, bedeutet das, dass es PHP-Sessions benutzt.

Viele Plugin- und Theme-Entwickler sind dazu übergegangen, eine Kombination aus Browser-Cookies und Datenbankzeilen zu verwenden (entweder in der wp_options-Tabelle oder ihrer eigenen benutzerdefinierten Tabelle). Wenn du Session-Daten benötigst, ist dies der bessere Ansatz.

Wenn du weitere Fragen zu PHP-Sessions hast, kannst du dich gerne an unser Support Team wenden.

Zusammenfassung

Hoffentlich weißt du jetzt ein bisschen mehr darüber, wie WordPress-Cookies und PHP-Sessions funktionieren als vorher. Cookies sind derzeit das, was die Welt am Laufen hält und sind wichtig für so ziemlich alles, was auf einer WordPress Seite passiert. Sie sorgen dafür, dass wir eingeloggt bleiben, dass der Einkaufswagen reibungslos funktioniert und sogar dafür, dass ein Popup-Fenster geschlossen bleibt.

Hast du noch weitere Fragen zu Cookies? 🍪 Lass es uns unten in den Kommentaren wissen.