WordPress

det CMS som det mesta av webben publiceras med

Vad det är

WordPress är ett system för innehållshantering (CMS) med öppen källkod: programvara skriven i PHP som lagrar en webbplats inlägg, sidor, media, användare och inställningar i en MySQL- eller MariaDB-databas och sätter ihop varje sida ur dem när någon efterfrågar den. Namnet förkortas ofta till WP, samma prefix som projektets egna filer och mappar bär (wp-config.php, wp-content, wp-admin). Det ges ut under GPLv2 (eller senare), så programvaran kostar ingenting att ladda ned, köra eller ändra.

En webbplats i WordPress består av tre lager. Kärnan (core) är den gemensamma kod som alla laddar ned och uppdaterar. Ett tema styr presentationen och tillägg (plugins) lägger till beteende, och just där drar projektets egen handbok för teman gränsen. Båda når in i kärnan genom hooks, namngivna punkter i koden där annan kod får köras, och hooks finns i två sorter: actions och filter. En action körs vid ett visst ögonblick, t.ex. när ett inlägg sparas, och returnerar ingenting. Ett filter tar emot ett värde, ändrar det och lämnar tillbaka det. Det här filtret kortar de automatiska utdragen ur inlägg från standardvärdet 55 ord till 30:

add_filter( 'excerpt_length', function ( $length ) {
    return 30;
} );

Teman har bytt form med åren. Klassiska teman använder det mallsystem i PHP som kom med WordPress 1.5 år 2005, och de används fortfarande i stor utsträckning. Blockteman är dagens angreppssätt: deras mallar är HTML-filer byggda av block, redigerbara i Site Editor, med färger, typsnitt och avstånd samlade i en fil som heter theme.json. Hybridteman är klassiska teman som har tagit till sig en del av blockfunktionerna.

Innehållet lämnar också webbplatsen som JSON genom REST-API:et, som blockredigeraren själv är byggd på. Ett anrop till webbplatsens adress /wp-json/ returnerar en karta över varje rutt som den erbjuder, publikt innehåll går att läsa utan inloggning, och allt privat kräver autentisering. Vilket program som helst kan hämta de tre senaste inläggen så här:

curl -s 'https://example.com/wp-json/wp/v2/posts?per_page=3'

För att köra det rekommenderar projektet PHP 8.3 eller senare, MySQL 8.0 eller MariaDB 10.11 eller senare, och HTTPS, helst på Apache eller nginx. Joomla och Drupal är system för innehållshantering av samma slag, och de två andra vägarna att väga det mot är en egen applikation på ett ramverk som Django och en statisk webbplatsgenerator.

Varför det spelar roll

Det verkliga beslutet bakom WordPress är vem som ändrar webbplatsen efter lanseringen, och vem som håller den säker medan det sker. WordPress ger personal utan teknisk bakgrund en komplett redigerare: de kan publicera en sida, byta en bild, lägga till en användare eller göra om en meny utan att öppna ett ärende. På en webbplats som ändras varje vecka är den billigaste ändringen den som inte kräver någon utvecklare.

Licensen är gratis, men webbplatsen är det inte. GPL täcker programvaran, och wordpress.org intar hållningen att tillägg och teman är härledda verk som ärver samma licens. Kostnaderna flyttar någon annanstans: ett webbhotell som kör PHP och en databas, timmarna för att välja, sätta upp och testa ett tema, och det löpande arbetet med att hålla kärnan, tilläggen, temana och PHP-versionen aktuella. Den sista kostnaden löper så länge webbplatsen finns, och en offert bör säga vem som bär den.

Underhållet följer av att WordPress är en levande applikation. Varje besök kör PHP mot en databas, varje tillägg är kod från tredje part som körs med samma åtkomst som kärnan, och inloggningssidan ligger öppet på internet om inte någon sätter ett andra lås framför den. De flesta webbplatser installerar mindre uppdateringar och säkerhetsuppdateringar i bakgrunden, vilket WordPress har tillåtit sedan version 3.7, medan en ny huvudversion väntar på att någon trycker på knappen för att uppdatera, och PHP på servern följer en egen tidplan.

Ett specialbygge passar data och arbetsflöden som inte alls liknar sidor och inlägg, och det kräver oftast en utvecklare för varje ändring. Ett statiskt bygge har ingen kod som körs när en sida efterfrågas och alltså ingenting att uppdatera där, och dess redaktörer arbetar oftast genom filer och ett byggsteg. WordPress passar den breda mitten: en ganska vanlig webbplats som ägarna själva ska sköta, där redigeringsvyerna är värda det underhåll som de för med sig. Inlåsningen förblir måttlig, eftersom koden är GPL, innehållet ligger i en vanlig SQL-databas och REST-API:et levererar inlägg, sidor och taxonomier som JSON.

Så ser det ut i praktiken

I företagets arbete är WordPress ett svar bland flera, valt med avsikt. Redogörelsen för hundra webbapplikationer täcker 2003–2014 och anger regeln bakom valet. När en kund behövde något skräddarsytt byggdes det med HTML/HTML5, CSS/SCSS och Django. När en kund behövde en mer standardmässig webbplats som den också kunde sköta själv kom WordPress eller Joomla fram snabbare och var det förnuftigare valet.

Det som redogörelsen värdesätter är omdömet, inte verktyget. En del av arbetet som den beskriver var att skilja de två fallen åt: att få en kund att avstå från ett specialbygge som den inte behövde, och att övertyga den om ett när behovet var verkligt.

Formulerat som frågor som en köpare kan besvara innan någon offert begärs ser omdömet ut så här:

  • Kommer medarbetare att redigera webbplatsen varje vecka utan hjälp av en utvecklare, eller ändras den bara några gånger om året?
  • Passar innehållet i sidor, inlägg, kategorier och media, eller behöver det en egen datamodell och egna regler?
  • Vem håller kärnan, tilläggen och PHP aktuella så länge webbplatsen är i drift?
  • Kommer webbplatsen att luta sig mot en handfull välskötta tillägg, eller mot dussintals som sys ihop för att efterlikna en applikation?

Ändringar varje vecka, innehåll som passar, en namngiven förvaltare och en kort lista med tillägg pekar mot WordPress eller ett liknande CMS. Ovanliga data, eller ingen som håller webbplatsen aktuell, pekar mot ett specialbygge eller ett statiskt bygge.

Var det går fel

En rutinuppdatering får webbplatsen att gå sönder

Någon uppdaterar ett tillägg, och en sida börjar visa ett fel eller adminpanelen vägrar att laddas. Webbplatsen hade samlat på sig tillägg i flera år, en del av dem övergivna av sina upphovspersoner, vart och ett PHP från tredje part med full åtkomst, och två av dem krockade. Håll listan kort och ta bort varje tillägg som webbplatsen har slutat använda, som handboken för härdning uppmanar till. Ta en säkerhetskopia före varje uppdatering, prova större uppdateringar på en kopia först och välj tillägg vars upphovspersoner fortfarande släpper nya versioner.

Egna ändringar försvinner efter en uppdatering eller en ny design

En justering som fungerade i månader försvinner den dag som temat uppdateras, eller en funktion som verksamheten är beroende av saknas när webbplatsen får ett nytt utseende. I det första fallet redigerade någon filerna i ett tema som någon annan hade skrivit, och uppdateringen ersatte dem. Handboken för teman varnar för att en funktion som läggs direkt i ett temas functions.php försvinner vid nästa uppdatering. I det andra fallet låg beteende som webbplatsen inte klarar sig utan i temat, så det försvann med temat. Lägg ändringar i någon annans tema i ett barntema, och lägg funktioner i ett litet eget tillägg som hakar in i kärnan, så att temat bär presentationen och ingenting annat.

Ett adminlösenord blir till kod på servern

Den som stjäl lösenordet till ett administratörskonto kan gå från att redigera inlägg till att köra sin egen PHP-kod, eftersom adminpanelen levereras med en redigerare för filerna i teman och tillägg. En rad i wp-config.php stänger av den redigeraren, vilket har samma effekt som att ta bort behörigheterna edit_themes, edit_plugins och edit_files från varje användare:

define( 'DISALLOW_FILE_EDIT', true );

Raden stänger en väg bland flera, och handboken säger rent ut att den inte stoppar en angripare som kan ladda upp skadliga filer. Kombinera den med starka lösenord, tvåstegsverifiering för varje administratör och så få administratörskonton som arbetet tillåter.

Webbplatsen halkar efter den aktuella versionen

Adminpanelen visar en banderoll om en ny version i månader medan webbplatsen kör en huvudversion, eller en PHP-version, som ligger långt efter den aktuella. Som standard installerar bakgrundsuppdateringarna mindre uppdateringar och säkerhetsuppdateringar, medan varje ny huvudversion väntar på ett klick. En webbplats kan alltså fortsätta att laga sig själv medan dess huvudversion och dess PHP halkar efter, tills ett tillägg som den är beroende av kräver något nyare. Lägg in uppdateringar av huvudversionen i kalendern, kontrollera samtidigt PHP-versionen mot projektets sida med systemkrav och testa båda på en kopia före den skarpa webbplatsen.

Läs mer

  • WordPress Documentation — projektets handbok för att driva en webbplats, från publicering och media till installation och underhåll.
  • Requirements — de versioner av PHP, MySQL och MariaDB som projektet rekommenderar i dag.
  • Updating WordPress — uppdateringar i bakgrunden, med ett klick och för hand, och säkerhetskopian att ta först.
  • Hardening WordPress — filrättigheter, behörigheter i databasen, reglaget för filredigeraren och ordning bland tilläggen.
  • Plugin Handbook: Hooks — hur actions och filter låter kod ändra WordPress utan att röra kärnan.
  • REST API Handbook — rutter, slutpunkter och autentisering för det API som blockredigeraren är byggd på.

Ordlista