Cookies blev først opfundet i 1994 af en computerprogrammør ved navn Lou Montulli. Uden dem ville internettet ikke være som det er i dag. Uanset om du logger ind på bagsiden af dit WordPress-websted eller lukker et irriterende popup-vindue, bruger du- og interagerer med cookies hver dag (selvom du ikke er klar over det).

På nuværende tidspunkt har du sikkert gættet, at når vi henviser til cookies, mener vi de cookies, der bruges til at gemme vigtige besøgsoplysninger på en hjemmeside, ikke den lækre chokolade-type. 🍪

I dag skal vi dykke ind i det nogle gange forvirrende emne i cookies og PHP-sessioner. Specielt alt hvad du behøver at vide om, hvordan WordPress bruger dem sammen med nogle almindelige problemer, som du bør være opmærksom på (især som en udvikler), når det kommer til hosting af dit websted, brugerdefineret kode eller brug af et tredjeparts plugin. Efter vores mening er dette emne ikke diskuteret nok.

Typer af cookies

Der er to forskellige typer af cookies, der ofte er indstillet: session cookies og vedholdende cookies.

Session Cookies

Session cookies, også kendt som forbigående cookies, er midlertidige. De har ikke en udløbsdato vedhæftet og gemmer kun oplysninger om, hvad brugeren gør under en enkelt session. En session er simpelthen en tilfældigt genereret / unik værdi, der tildeles når nogen besøger et websted. Session cookies gemmes midlertidigt i hukommelsen og fjernes automatisk, når browseren lukker eller sessionen slutter.

Vedholdende Cookies

Vedholdende cookies, som du måske har gættet, er dem, der indeholder en udløbsdato. Disse varer meget længere og opbevares på disk indtil de udløber eller manuelt ryddes af brugeren. Disse kaldes også nogle gange som “sporing af cookies”, da disse er de typer af cookies, som Google Analytics, AdRoll, Stripe osv. Bruger.

Vores Kinsta-affilierede program er et andet eksempel. En 60-dages cookie er placeret i brugerens browser, når de klikker på et tilknyttet link. Dette sikrer, at henviseren får den rette kredit, selvom personen har lukket og genåbnet deres browser flere gange.

Hvordan WordPress Core bruger cookies

Når vi henviser til WordPress-kernen, mener vi blot de filer, der udgør open source-projektet, før du installerer plugins eller temaer fra tredjepart. Det er WordPress i sin naturlige tilstand, som vi kan lide at kalde det.

Nu hvor du kender det grundlæggende om, hvad en cookie er og de forskellige typer, lad os tage et kig på, hvorfor og hvordan WordPress-kernen bruger dem til at gøre alt det magiske der sker bag kulisserne. Sjovt faktum: Cookie var oprindeligt afledt af udtrykket “magisk cookie“.

WordPress-kernen bruger cookies til to forskellige formål:

1. Log ind Cookies

Login cookies indeholder godkendelsesoplysninger og bruges når en bruger logger ind på WordPress admin dashboard. Ifølge WordPress Codex er et par forskellige session cookies indstillet:

Når du forsøger at få adgang til bagsiden af ​​dit WordPress-websted, foretages et check for at se, om de to cookies ovenfor eksisterer og ikke er udløbet. Dette giver dig mulighed for at omgå wp-login.php-skærmen. 😉

WordPress indstiller også wp-settings- {time} - [UID] cookies. ID’et er dit bruger-id fra WordPress-brugerdatabasen. Dette gemmer personlige dashboard og admin interface indstillinger.

2. Kommentar cookies

Som standard er der angivet cookies, når nogen kommenterer et blogindlæg (med et udløb på 347 dage). Hvis de kommer tilbage senere, behøver de så ikke at udfylde alle oplysningerne igen. De følgende tre cookies gemmes:

Men med de seneste ændringer af privatlivspolitikken på grund af GDPR, er nye værktøjer blevet introduceret af WordPress-kernen for at sikre, at du giver brugerne mulighed for at logge ind på disse cookies. Denne indstilling, hvis den ikke allerede er indstillet, kan aktiveres under “Indstillinger → Diskussion” i dit WordPress admin dashboard. Vælg indstillingen “Vis kommentarer til cookies-optjekker”. Det populære Akismet-plugin giver dig også mulighed for at vise en fortrolighedserklæring.

hvordan kommentarer cookies opt-in

hvordan kommentarer cookies opt-in

Hvordan tredjeparts WordPress-plugins- og temaer Bruger cookies

Ligesom WordPress bruger cookies til bestemte funktioner, tredjeparts plugins og temaer som du installerer, indstilles også cookies. De fleste bruger en kombination af browser cookies og database rækker gemt i wp_options boardet eller deres eget brugerdefinerede board. Dette skyldes, at WordPress er statsløs.

En statsløs app er et program, der ikke sparer klientdata, der genereres i en session, til brug i den næste session med den pågældende klient. Hver session udføres som om det var første gang, og svarene er ikke afhængige af data fra en tidligere session. – TechTarget

Med nye lovgivninger om beskyttelse af personlige oplysninger er det vigtigere end nogensinde at rent faktisk at forstå, hvilke cookies der indstilles, og hvis de giver en mulighed for, at dine besøgende kan opt-in. Tip: Ikke alle cookies kræver opt-in. Læs vores dybdegående indlæg på GDPR for at få bedre forståelse af nye krav.

Her er blot et par af de mange eksempler på, hvilke cookies der bruges til:

I det væsentlige vil enhver handling eller opt-in på et WordPress-websted, typisk være at indstille en cookie i browseren bag kulisserne. Målet med dette er selvfølgelig at forsøge at hjælpe med at forbedre browseroplevelsen eller give yderligere funktionalitet gennem verifikation.

Click to Tweet

WooCommerce cookies

E-handels-plugins som WooCommerce har typisk deres egne ekstra cookies, som de sætter, så købere nemt kan føje ting til deres indkøbsvogn, gemme dem senere, når de checker ud og logger ind og ud af deres konto.

For at holde styr på indkøbsvogn-data indstiller WooCommerce følgende tre cookies (ingen personlige oplysninger gemmes i cookies):

De to første cookies indeholder oplysninger om indkøbsvognen og hjælper simpelthen WooCommerce med, hvornår vogndataene ændres. Den tredje cookie wp_woocommerce_session_ indeholder en unik kode for hver kunde, hvilket svarer til en post i den brugerdefinerede wp_woocommerce_sessions-tabel i databasen.

wp_woocommerce_sessions tabel

wp_woocommerce_sessions tabel

Dataene for wp_commerce_session_ blev tidligere gemt i wp_options-tabellen, men blev flyttet til sit eget brugerdefinerede board i WooCommerce 2.5, da de introducerede en ny sessionshandler. Dette var for at forbedre ydeevnen, skalerbarheden og styringen af ​​sessioner. Ellers slutter du hurtigt med et opblussen wp_options board, du skal rydde op.

Easy Digitial Downloads Cookies

Easy Digital Downloads bruger som standard WP_Session, som er en kombination af browser cookies og database rækker gemt i wp_options tabellen. Nedenfor ses den cookie den sætter:

Cookies og WordPress caching

Når det kommer til WordPress cache, er det her, hvor tingene bliver vanskelige. Caching er i det væsentlige processen med at lagre ressourcer fra en anmodning og genbruge disse ressourcer til efterfølgende anmodninger. Det reducerer i grunden mængden af ​​arbejde, der kræves for at generere en sidevisning. Selvom dette er fantastisk til ydeevne, forårsager det et problem, når det kommer til cookies.

Hvorfor? Fordi cookies er der for at udføre en vis handling, som f.eks. at holde indkøbskurven befolket, mens du besøger et WooCommerce-websted. Men hvis en side serveres fra cache, tjener hverken PHP eller databasen noget, serveren serverer blot en statisk kopi af siden.

Så hvad kan du gøre?

1. Brug JavaScript

Den første mulighed ville være at bruge JavaScript og opdatere indhold på en side dynamisk. Dybest set har du HTML-pladsholdere og bruger JavaScript til at trække i info over et API eller Ajax-opkald.

Et eksempel ville være at indlæse en liste over indlæg i WordPress sidebjælken ved at bruge JavaScript til at hente en liste over indlæg over wp-api og derefter lave dem i sidepanelet. I dette scenario kan du opdatere listen over indlæg uden at rydde siden fra cachen, da dataene genereres dynamisk.

Dette er ikke ideelt, men det er altid bedre at cache, hvis det er muligt med hensyn til ydeevne. Men hvis du skal have at en smule indhold forbliver dynamisk, mens selve siden kan forblive statisk (serveret fra cache), er det en måde at gøre det – brug JavaScript til at trække indholdet for den del af siden, dynamisk ud via et API / ajax opkald. Men medmindre du kan ansætte en WordPress-udvikler til at opbygge en brugerdefineret JavaScript-løsning eller udvidelse af et plugin, er denne indstilling normalt ikke praktisk.

2. Brug Admin-Ajax-opkald

Admin-ajax.php kan ikke gemmes, derfor kan du bruge admin-ajax-opkald. Et godt eksempel på dette er plugin for No Cache AJAX Widgets. Det laver administrator-ajax-opkald og behøver derfor ikke at bekymre sig om at være i modstrid med server-niveau eller tredjeparts caching-løsninger.

Men ligesom med JavaScript er det typisk ikke muligt at tage denne vej for den gennemsnitlige bruger. Det kan også føre til andre præstationsproblemer som f.eks. Høj brug af admin-ajax og mange ubearbejdede forespørgsler.

3. Ekskluder sider fra cache (når cookies er til stede)

Medmindre du vil tage JavaScript eller admin-ajax-ruten, er det den bedste vej at tage, med undtagelse af sider fra caching, når en bestemt cookie er til stede. Dette er typisk det, vi anbefaler. Især dem der kører meget dynamiske websteder som WooCommerce og Easy Digital Downloads.

På Kinsta udelukkes visse WooCommerce og Easy Digital Downloads sider som indkøbsvogn, min konto og checkout automatisk fra caching. Der er en server-niveau-regel på plads, så brugerne automatisk omkaster cachen, når cookie-cookie_items_in_cart-cookie eller edd_items_in_cart-cookie er registreret for at sikre en jævn og in-sync-checkout-proces.

Vi lytter også efter de tilhørende logget cookies og indstiller cachen til at omgå, når vi opdager, at nogen har logget på WordPress. Det forhindrer, at back-end-dashboardet fra et uheld bliver cachelagret.

Som standard udelukker vi ikke wp_woocommerce_session_ cookie fra cache. De fleste WooCommerce-websteder, med vores erfaring, har ingen problemer. Dette forbedrer også ydelsen ved at øge dit cache-HIT-forhold, mens du bruger færre PHP-medarbejdere.

På grund af at der er mange forskellige WordPress tema- og pluginkonfigurationer, kan vi udelukke wp_woocommerce_session_ cookie fra cache, hvis det er nødvendigt. Bare nå ud til vores supportteam. Resultatet er, at når en bruger først tilføjer et produkt til deres indkøbskurv, vises ikke alle efterfølgende anmodninger fra cache, hvilket øger brugen af PHP-medarbejdere..

Kæmper med nedetid og WordPress-problemer? Kinsta er hostingløsningen designet til at spare din tid! Tjek vores funktioner

Hvis du har brug for en brugerdefineret side, der er udelukket fra cache, er du velkommen til at åbne en billet med vores supportteam. Igen skal du være forsigtig, når det kommer til udelukkelser. For mange ubeskyttede sider kan virkelig forringe ydeevnen. Tjek vores do’s og don’ts for hosting WordPress medlemskab websteder.

Sådan ses og ryddes cookies

Det er nemt at se og rydde cookies på et websted. For at se, hvilke cookies der er angivet på et bestemt websted, skal du søge på det pågældende websted og klikke på det lille hængelåsikon øverst. Klik derefter på “Cookies”.

Cookies i brug

Cookies i brug

Derefter skal du bore ned til den pågældende hjemmesides mappe. I eksemplet nedenfor kan du se, at vi har et par WooCommerce-cookies, samt wordpress_logged_in_ [hash] cookie. Du kan også se udløbet tid, og om det er en vedvarende cookie eller session cookie (når browseren slutter).

WordPress cookies

WordPress cookies

For at fjerne en cookie skal du blot klikke på en individuel cookie og klikke på knappen “Fjern”. Du kan også gøre dette på mappeniveau eller i Chrome DevTools.

Alternativt kan du søge efter eller rydde alle cookies i din browser.

GDPR og cookies

GDPR er en ny lov om beskyttelse af personlige oplysninger, der trådte i kraft den 25. maj 2018. Det var designet til at give borgerne kontrol over deres personoplysninger. Vi anbefaler stærkt at læse vores dybtgående indlæg: downdown på GDPR overholdelse, hvis du ikke allerede har det. Dette er et emne, der ikke kan opsummeres i et afsnit!

Her er et eksempel på en ændring, vi lavede hos Kinsta, for at hjælpe med at overholde den nye lov. Når du først besøger vores websted, har du måske allerede set det, du bliver mødt med en “Accept Cookies” -prompt nederst på skærmen. Dette skyldes, at vi nu lovligt er forpligtet til at give brugerne en mulighed for at logge ind og fravælge cookies. Væk er de dage, hvor du bare kører, uanset hvad du vil, uden at informere brugere om dataindsamling.

Accepter cookies

Accepter cookies

Hvis du klikker på “Accept Cookies”, indstilles alle cookies til brugeren. Hvis du klikker på “Cookie Settings”, giver vi nu mulighed for at logge ind og fravælge alt, hvad du ønsker.

Cookie indstillinger

Cookie indstillinger

Ret smart ik? Vores cookie-løsning blev bygget internt af vores udviklere, men her er nogle nyttige GDPR WordPress-plugins, der kan hjælpe dig med at opnå noget lignende. Igen er cookies bare en lille del af at blive fuldstændig GDPR-kompatibel.

PHP Sessioner

PHP sessioner er et alternativ til standard cookie tilgang. Det er stadig en cookie, men den hedder PHPSESSID og gemmes typisk i /tmp/ mappen på selve webserveren. Den måde, hvorpå serveren ved at forbinde en given session med en given anmodning, er, at den også gemmes i en HTTP-cookie.

PHPSESSID HTTP cookie

PHPSESSID HTTP cookie

Dette kan også ses under HTTP-overskriften for et websted.

HTTP header sæt cookie PHPSESSID

HTTP header sæt cookie PHPSESSID

En PHP-session er meget som en normal session, der slutter, når brugeren lukker deres browser.

Problemet med PHP-sessioner kommer alt sammen til problemer med ydeevne og caching. De oplysninger, der er gemt i browsercookien, skal springes frem og tilbage med hver anmodning, så serveren ved, hvem brugeren er. Dette betyder for websteder, der bruger PHPSESSID, at værten bliver nødt til at indstille PHPSESSID for at omgå cachen. Resultatet er imidlertid, at PHPSESSID skulle være indstillet til at omgå 100% af tiden, fordi i modsætning til wordpress_logged_in er PHPSESSID indstillet på hver enkelt PHP-anmodning.

Så forestil dig, at wordpress_logged_in skulle indstilles 100% af tiden for at tillade login funktionalitet til at fungere. Det betyder, at selv udmeldte brugere skulle have cookien, og det skulle være unikt for dem. Forestil dig det, der var nødvendigt for at WordPress loginsystemet skulle fungere. I dette scenario skulle hvert enkelt sidevisning være omgået af cachen, således at wordpress_logged_in cookie blev indstillet korrekt både for brugere der er logget- ind og ud.

Det er problemet med at bruge PHPSESSID. Fordi det genereres på hver enkelt PHP-anmodning, hvis et websted er afhængigt af PHPSESSID-cookies, skal værten sætte PHPSESSID for at omgå cache 100% af tiden. Ellers ophører PHPSESSID’en med at blive cachelagret, og det ødelægger uanset hvilken funktionalitet der er afhængig af.

Vi anbefaler ikke at bruge PHP-sessioner, og de vil normalt ikke fungere i vores Kinsta-miljø. PHP-sessioner har også andre sikkerhedsmæssige konsekvenser, der bør overvejes.

Hvis du ser kode ved hjælp af session_start på dit websted, betyder det, at det bruger PHP-sessioner.

Mange plugin- og temaudviklere er skiftet til at bruge en kombination af browser cookies og database rækker (enten i wp_options bordet eller deres eget brugerdefinerede bord). Hvis du har brug for session data, er dette den bedre tilgang.

Du er velkommen til at kontakte vores supportteam, hvis du har yderligere spørgsmål vedrørende PHP-sessioner.

Resumé

Forhåbentlig, nu ved du lidt mere om, hvordan WordPress-cookies og PHP-sessioner virker, end du gjorde før. Cookies er i øjeblikket det, der får verden til at gå rundt og er vigtig for stort set alt, hvad der sker på et WordPress-websted. Fra at holde os logget ind for at sikre en jævn indkøbskurv-oplevelse og endda sikre, at et popup-vindue forbliver lukket.

Har du andre spørgsmål om cookies? 🍪 Lad os vide nedenfor i kommentarerne.


Hvis du godt kunne lide denne artikel, så vil du elske Kinstas WordPress hostingplatform. Boost dit website og få 24/7 support fra vores WordPress-ekspertteam. Vores Google Cloud-drevne infrastruktur fokuserer på automatisk skalering, ydeevne og sikkerhed. Lad os vise dig Kinsta-forskellen! Tjek vores planer