De automatiska uppdateringarna på mindre versioner av WordPress har bevisat sig i flera år. Men fungerar detta också med plugin-uppdateringar? Och i så fall under vilka förutsättningar? WordPress-utvecklaren Florian Simeth har undersökt denna fråga.

Alla som har använt WordPress under en tid vet att de automatiska uppdateringarna av kärnprogramvaran fungerar ganska bra och vanligtvis utan problem. Om det inte vore för plugins. Vanligtvis står hårstråna på baksidan av nacken upp vid tanken på automatiska plugin-uppdateringar för de flesta ansvariga för en webbplats. Alla som någonsin har gnuggat tänderna innan de klickar på uppdateringsknappen vet vad jag pratar om.

Det finns ingen grundläggande säkerhet om huruvida uppdateringarna kommer att gå igenom korrekt. Även om själva uppdateringen inte misslyckas alls, men felen lurar någonstans - inte uppenbart - under jord. De flesta kollegor jag intervjuade skulle inte utföra automatiska plugin-uppdateringar, åtminstone inte för alla WordPress-plugins. Men varför är det så?

Automatiska plugin-uppdateringar: Riskerna

Hundratals volontärer är involverade i nya versioner av WordPress. Inte alla plugin-projekt har denna kraft. De allra flesta gratis plugins i WordPress-plugin-katalogen är bara utvecklade av en människa (eller kanske ett litet team). Det är inte att säga att dessa plugins är dåliga i sig. Från det förflutna vet vi dock att det vanligtvis är plugins som öppnar säkerhetsluckor och att din egen WordPress-instans blir en attackyta för hackare.

Det kan därför antas att kodkvaliteten lider eller inte testas tillräckligt. Varför det är så vill jag inte förklara i nuläget. Men det förklarar varför jag snabbt klickar på uppdateringsknappen med välkända plugins som YoastSEO och inte med andra.

"I grund och botten kan du känna igen problem eftersom något har gått fel tidigare", skrev WordPress-utvecklaren Marc Nilius i en intervju via e-post. Enligt egen uppgift har han för närvarande cirka 200 WordPress-instanser och känner sina "vänner" alltför väl.

Yoast har verkligen ett stort team bakom sitt eget kostnadsfria YoastSEO-plugin, som är aktivt på över fem miljoner WordPress-webbplatser. När det gäller företagets flaggskepp gör man allt man kan för att se till att inget går fel. Det är en fråga om ansträngning. En insats som en utvecklare ensam kanske inte kan eller vill hantera. Vad kan man då göra?

Sätt att minimera risken för plugins

1. Ingen gammal Plugins Använda

"Demokratiserande publicering" är en spetsig vägledande princip för WordPress. Det faktum att vem som helst snabbt kan skapa en WordPress-webbplats är en lysande sak, men leder automatiskt till att dessa människor vill utöka webbplatsen någon gång. Och med plugins. Eftersom de vanligtvis inte kan programmera sig själva, letar de efter ett botemedel på den eviga World Wide Web. Och det finns gott om dem. 

För närvarande finns det nästan 55 000 tillägg enbart i WordPress plugin-katalogen. Det som fungerar är det som används. Utan att ta hänsyn till om insticksprogrammet utvecklas vidare eller om det är kompatibelt med den aktuella WordPress-versionen. Detta är inte alltid sant och leder i slutändan ofta till en sund misstro mot uppdateringar. Ofta slutar sådana plugins att fungera någon gång. Även om det kan ta några år.

Naturligtvis finns det också positiva exempel. Bakom WooSidebars finns till exempel ett stort företag. Icke desto mindre har WooCommerce Plugin inga uppdateringar på länge. Det har inte testats med de senaste WordPress-versionerna, men det fungerar fortfarande bra i många fall. Hur mycket längre? Tidigare kommentarer i stödområdet pekade redan på ett slut. Men användaren märkte ingenting. Under installationen indikeras detta klagomål endast av en liten, iögonfallande anteckning. En farlig sak.

När man börjar sin bloggkarriär har man ofta inte pengar för individuell utveckling. För dessa människor finns det ibland inget annat alternativ. Du bör dock komma ihåg att du på grund av de säkerhetsrisker som nämns ovan inte bör använda föråldrade WordPress-plugins.

2. Plugins justera inte dig själv

För att spara utvecklingstid anpassas officiella och inofficiella WordPress-plugins ofta helt enkelt av sina egna utvecklare. Om versionsnumret eller namnet på plugin-programmet inte ändras erbjuder WordPress en uppdatering, även om detta inte får göras eftersom det annars skulle skriva över sina egna ändringar.

"Anpassad Plugins ofta för mycket Theme funktioner", Marc vet också. Förändras något i Theme , kör också Plugin inte längre korrekt. Så det finns många problem. Men att göra allt själv från grunden, med andra ord att bara använda sin egen utveckling, är inte heller ett verkligt alternativ här.

3. Inga dåliga Plugins Använda

Vad är ett "dåligt" plugin? Denna fråga är inte lätt att svara på. Särskilt inte för lekmannen. Naturligtvis kan man fråga sig om automatiserade tester av nya versioner utförs. Men vem gör det? Många WordPress-användare vet inte ens att något sådant är möjligt. Dessutom har sådana tester (om de utförs) ofta inget att göra med levande situationer.

Vilket också är förståeligt ur utvecklarens synvinkel. Vem testar varje plugin med alla möjliga WordPress-teman? Eller något plugin med något annat plugin? Det duger inte. Du kan inte lita på att de som utvecklar WordPress-plugins gör det.

Återigen är "dåliga" plugins ibland inte möjliga att inte använda, eftersom du helt enkelt inte alltid känner igen dem. Även om kvalitetsbetyget redan är det första hindret för många användare, bör du åtminstone aktivt testa nya plugins själv innan du integrerar dem på en live-sida. Men mer om det om en stund.

Varför automatiska plugin-uppdateringar misslyckas

Faktum är: Du kan inte bara inte använda WordPress-plugins. Ovanstående problem kommer alltid att finnas. Så en annan lösning måste hittas. Så frågan du måste ställa dig själv är: " Hur kan du - trots alla problem - fortfarande utföra automatiska uppdateringar för WordPress-plugins?". Och denna fråga leder oundvikligen till nästa: "Vad kan gå fel?"

Här är några alternativ:

1. PHP Fatal Error: Webbplatsen fungerar inte längre på grund av ett allvarligt fel.
2. Den Plugin fungerar inte (mer) med andra Plugins och/eller Theme . Detta är extremt annorlunda i olika saker:
   a) Funktioner är inte längre tillgängliga eller
   b) layouten ändras i den främre änden.
3. Obefintlig bakåtkompatibilitet gör det svårt att återställa.
4. Databasen är så stor att en säkerhetskopia skulle ta lång tid att konfigurera.

Lösningar för framgångsrika plugin-uppdateringar

Dålig Plugins Känna igen

Låt oss börja med användarna. Hur kunde de känna igen ett "dåligt" plugin? Eftersom lekmannen inte kan kontrollera om kodkvaliteten är bra måste ett system skapas som kan göra detta. Frågan är: Skulle något sådant fungera? Och svaret är helt klart: Ja!

Det fina med det: Ett litet WordPress-team arbetar redan med ett sådant system. Det heter Tide. Tides vision är att utföra automatiserade kvalitetstester för alla WordPress-plugins och teman och att göra dessa testresultat synliga för både författarna och användarna av dessa plugins och teman.

Det är inte klart ännu, men i framtiden kommer Tide att hjälpa lekmän att bättre känna igen vilken typ av WordPress-plugins de installerar. Fram till dess måste du hålla dig till plugin-metadata, som är baserad på wordpress.org I plugin-katalogen för varje enskilt plugin:

1. Datumet för den senaste uppdateringen. Frekvent uppdatering kan indikera en aktiv utvecklingsprocess. I de flesta fall tar utvecklarna också hand om att fixa buggar.
2. Antal installationer. Ett mycket högt tal indikerar inte bara populariteten utan kan också vara en indikation på att författarna tjänar pengar med plugin (t.ex. via en proversion). Detta skapar ett visst tryck från tillverkaren. Han har verkligen ett intresse av att se till att det gratis pluginet också fungerar felfritt.
3. Testad tills. Detta är också bara ett versionsnummer som kan justeras av tillverkaren när som helst utan att behöva bevisas av en tredje part. Ett aktuellt versionsnummer är dock en indikation på att plugin-programmet uppdateras regelbundet.
4. PHP-version. Även om det är trevligt att utvecklare fortsätter att stödja låga versionsnummer av PHP, skulle en högre version vara säkrare.

Automatiserad webbläsartestning

Nu blir det lite svårare. Speciellt för dem som inte har någon programmeringskunskap. Om du är beroende av viktiga funktioner bör du testa dem regelbundet – gärna automatiskt, förstås.

Puppeteer är ett NodeJS-bibliotek som tillhandahåller ett API på hög nivå för att styra Chrome-webbläsaren via DevTools-protokollet. Puppeteer körs huvudlös som standard, men kan konfigureras för att öppna webbläsaren och se vad som händer.

Funktionella

Det finns många användningsområden för sådana tester. Om du har en webbutik med WooCommerce kan du kontrollera om produkterna fortfarande kan läggas till i kundvagnen. Eller om det fortfarande går att skicka in formulär.

Naturligtvis kan inte alla fall täckas. Ett litet automatiskt test är dock effektivare i de flesta fall än enkel visuell inspektion. När allt kommer över kan du inte alltid testa alla funktioner på en sida efter varje liten uppdatering. Särskilt när det är mycket omfattande.

Visuella regressionstester

Även en "visuell inspektion" skulle redan kunna automatiseras med dagens medel. Detta fungerar relativt enkelt, till exempel med BackstopJS. Konfigurationen görs snabbt via en JSON-fil. Ett backstop-test i konsolen räcker för att starta jämförelsen. Slutligen öppnar verktyget ett webbläsarfönster och visar skillnaderna.

Eftersom BackstopJS också anger en detaljerad rapport med ett särskiljande värde i procent kan du få .B informerad via e-post om det fanns en betydande förändring i layouten.

Rollback

Låt oss säga att alla uppdateringar utfördes och de automatiska testerna misslyckades. Vad ska man göra? Naturligtvis kan säkerhetskopior också ställas in automatiskt. Men detta fungerar bara i tre fall: 

1. Om värden har ett gränssnitt som automatiskt initierar en återställning.
2. Eller om du har SSH-åtkomst.
3. Och om säkerhetskopian är tillräckligt liten. Annars tar reprisen i värsta fall flera timmar.

Många utvecklare vet bara alltför väl att det mesta av detta ofta inte är möjligt. Antingen är SSH-åtkomst inte tillgänglig alls eller så finns det tidsgränser på grund av saknade resurser på servern.

Andra lösningar?

Naturligtvis är min åsikt bara en av många. Det finns andra, oftast dyrare lösningar. I stället för att ladda upp en säkerhetskopia efteråt kan du till exempel göra en kopia av sidan i förväg (Iscensättningskoncept samt med Raidboxes, förutom WordPress-säkerhetskopiorna) och därmed utföra alla typer av uppdateringar och tester. Om allt går bra under testet kan uppdateringarna äntligen också installeras på livesidan. Då, naturligtvis, (vanligtvis) helt automatiskt och utan upphöjt nackhår.

En annan idé är att låta WordPress skapa statiska sidor. Då skulle sidan vara något mer oberoende av själva kärnan. Plugins för detta ändamål har funnits i åtta år: WPStatic, till exempel. Men detta fungerar inte för alla användningsområden, och definitivt inte för mycket dynamiska webbplatser som webbutiker.

Min slutsats

Hur du gör det, du gör det fel, eller hur? Nej! I slutändan beror det på din egen webbplats, dina önskemål och naturligtvis din plånbok. Om du inte kör kritiska webbplatser och det är okej för en webbplats att kasta fel, klarar du dig bra med automatiska uppdateringar.

Också med Raidboxes har dig med Fully Managed Tillägg möjlighet att aktivera automatiska plugin- och temauppdateringar. I inställningarna för din BOX Du kan också utesluta enskilda plugins och teman som du redan har haft problem med från de automatiska uppdateringarna.

Förmodligen automatiska plugin-uppdateringar för de flesta, små sidor är ändå relativt enkla. De som har större sidor har vanligtvis mer ekonomiska resurser tillgängliga för att vidta lämpliga åtgärder. Alla däremellan måste hitta sin egen lösning.