Automatiska WordPress-uppdateringar mitt i Halloween-trafiken: så ser du exakt vad som ändrades

Sista veckan i oktober kör många butiker Halloween-kampanjer. Trafiken ökar och marginalen för fel krymper. Samtidigt fortsätter WordPress att uppdatera sig själv i bakgrunden, utan att någon klickar på en knapp. För det mesta går det bra. När det inte gör det märks felet ofta först hos en kund i kassan, timmar efter själva uppdateringen. Kopplingen mellan de två är då svår att se.

Artikeln handlar om just den kopplingen. Vad uppdateras automatiskt, när händer det, vilka fel visar sig först under hög last, och hur bevisar du vilken ändring som hänger ihop med felet?

Vad uppdateras faktiskt automatiskt?

Det första steget är att veta vad som är påslaget. Det skiljer sig mellan sajter, och ibland även mellan webbhotell.

• Mindre core-versioner (till exempel 6.x.1 till 6.x.2) installeras automatiskt som standard. Det styrs av konstanten WP_AUTO_UPDATE_CORE.
• Översättningar uppdateras automatiskt som standard.
• Plugins och teman uppdateras bara automatiskt om det har slagits på för varje enskilt tillägg eller tema. Det kan också styras via filtren auto_update_plugin och auto_update_theme, eller av webbhotellet.
• Allt stängs av om AUTOMATIC_UPDATER_DISABLED är satt till true.

Med WP-CLI kan du kontrollera läget på några sekunder:

• wp plugin auto-updates status --all visar vilka plugins som uppdateras automatiskt.
• wp theme auto-updates status --all visar samma sak för teman.
• wp config get WP_AUTO_UPDATE_CORE ger ett fel om konstanten inte är definierad, och då gäller standardläget.
• grep -rn "auto_update_" wp-content/mu-plugins/ visar om någon har lagt in filter som skriver över inställningarna i adminpanelen.

Varför det spelar roll: en kund som säger "vi uppdaterar aldrig automatiskt" kan mycket väl ha ett webbhotell som gör det åt dem. Utgå inte från vad någon tror. Kontrollera.

När körs uppdateringarna?

Bakgrundsuppdateringar körs via WP-Cron. Händelserna wp_version_check, wp_update_plugins, wp_update_themes och wp_maybe_auto_update är normalt schemalagda två gånger per dygn. WP-Cron startas av sidvisningar, så den exakta tidpunkten beror på när trafiken kommer in. Du kan se nästa körning med:

wp cron event list --fields=hook,next_run_relative,recurrence

Under en kampanj betyder det i praktiken att uppdateringen kan köras mitt på dagen, mitt i rusningen. Om sajten använder systemcron i stället för WP-Cron styrs tidpunkten av serverns schema, så kontrollera crontab också.

Medan en uppdatering pågår finns optionen auto_updater.lock. Kör du wp option get auto_updater.lock och får ett värde, så pågår en körning just nu eller har nyligen avbrutits.

Felmönster som visar sig först när trafiken ökar

Underhållsläget och 503

Under en core-uppdatering skriver WordPress en .maintenance-fil i webbroten. Besökare får då HTTP 503 med Retry-After: 600. WordPress ignorerar en fil som är äldre än tio minuter, så ett avbrutet underhållsläge varar sällan längre än så. Men tio minuter med 503 under en kampanjtopp är tio minuter utan försäljning. Och en avbruten uppdatering kan lämna kvar ett halvt uppdaterat tillägg.

Fatala fel och vad den inbyggda återställningen missar

Sedan WordPress 6.6 gör core en loopback-förfrågan efter en automatisk plugin-uppdatering. Om den hittar ett fatalt PHP-fel återställs den tidigare versionen. Det är ett bra skydd, men det har tydliga gränser. Det fångar inte:

• JavaScript-fel som bara slår till i kassan eller i varukorgen.
• Fel som bara uppstår för inloggade kunder, i specifika betalflöden eller på enskilda produkttyper.
• Varningar och deprecation-meddelanden som fyller felloggen och gör sajten långsammare.
• Ändrade mallar eller beteenden som inte ger något fel alls, bara fel resultat.

Problem som skalar med lasten

En uppdatering kan ändra en databasfråga så att den tar 300 ms i stället för 30 ms. Vid låg trafik märks det knappt. Vid kampanjtrafik tar PHP-arbetarna slut och du får 502- eller 504-fel. Många cacheplugins tömmer dessutom cachen efter en uppdatering. En kall cache samtidigt som en trafiktopp är en vanlig väg till timeouts.

Aviseringen som ingen läser

WordPress skickar e-post efter automatiska uppdateringar till sajtens adminadress. Kontrollera vart den går med wp option get admin_email. På många kundsajter går den till en inkorg som ingen bevakar.

Så loggar Ravnsight Detective vad som ändrades

Problemet med bakgrundsuppdateringar är sällan själva felet. Problemet är att ingen vet vad som ändrades eller när. Ravnsight Detective är ett gratis WordPress-tillägg som registrerar ändringar, alltså plugin-, tema- och core-uppdateringar, på samma tidslinje som PHP-fel, JavaScript-fel, prestanda, cron och WooCommerce-händelser.

Ett förenklat exempel på hur en sådan tidslinje kan läsas:

• 13:12 Ändring: ett presentkortsplugin uppdaterades automatiskt.
• 13:14 De första PHP-varningarna från samma plugin dyker upp.
• 13:40 JavaScript-fel på kassasidan.
• 13:45 Antalet slutförda WooCommerce-ordrar sjunker.

Detective lägger händelserna i ordning och pekar ut en trolig orsak. Den visar både bevisen som stöder slutsatsen och de som talar emot, med en säkerhetsnivå: LOW, MEDIUM, HIGH eller CONFIRMED. I exemplet ovan är uppdateringen starkt korrelerad med felen. Bekräftad blir den först efter ett isoleringstest. Testet stänger av det misstänkta tillägget enbart i administratörens egen session, så besökarna påverkas inte. Bara om felet då försvinner och kommer tillbaka när tillägget slås på igen sätts nivån till CONFIRMED.

Detective observerar och diagnostiserar. Det återställer inga versioner och ändrar ingenting på egen hand. Tillägget gör inga externa anrop om du inte själv har valt det.

Utifrån: se felet innan kunderna gör det

Tidslinjen inifrån förklarar varför. Övervakning utifrån talar om när. Under en kampanj är det framför allt tre kontroller som är värda att ha:

• Nyckelordskontroll på en sida som måste fungera, till exempel att texten på köpknappen finns. Då fångar du också fall där sidan svarar 200 men visar fel innehåll.
• Syntetiskt flöde (Pro) som lägger en vara i varukorgen och går till kassan i en riktig webbläsare.
• Startsidesbild med insamling av JavaScript-fel, som visar fel som en enkel HTTP-kontroll aldrig ser.

Kontrollerna körs varje minut från Tyskland, och ett misslyckat resultat bekräftas från Finland eller Sverige innan någon larmas. Ett kort underhållsläge som redan är över vid bekräftelsen ger därför inget larm. Det är avsiktligt. Ändringen finns ändå kvar på tidslinjen i Detective.

Före kampanjen: en kort checklista

1. Kör wp plugin list --fields=name,version,auto_update > fore-kampanj.txt och spara filen. Då har du en referens att jämföra mot.
2. Bestäm aktivt vilka plugins som får uppdateras automatiskt under kampanjveckan. Säkerhetsuppdateringar är ett skäl att låta core-uppdateringarna vara på. Ett kampanjkritiskt betalplugin är ett skäl att uppdatera det manuellt och under uppsikt.
3. Flytta adminadressen till en inkorg som någon faktiskt läser, eller vidarebefordra aviseringarna.
4. Lägg till nyckelordskontroll och, om möjligt, ett syntetiskt kassaflöde minst en vecka före kampanjen, så att du vet hur normalläget ser ut.
5. Installera Detective innan kampanjen startar. En tidslinje börjar registrera från den dag den installeras, inte bakåt i tiden.

Om du hellre vill uppdatera kontrollerat än låta det ske i bakgrunden erbjuder Pro övervakade uppdateringar med en återställningspunkt och säkerhetskopiering på sajten. Även där är det du som bestämmer när uppdateringen körs.