# WordPress ## Hvad det er WordPress er et open source-system til indholdsstyring: PHP-software, der gemmer et sites indlæg, sider, medier, brugere og indstillinger i en MySQL- eller MariaDB-database og sætter hver side sammen af dem, når nogen beder om den. Navnet forkortes ofte til WP, det samme præfiks, som systemets egne filer og mapper bærer (wp-config.php, wp-content, wp-admin). Det udgives under GPLv2 (eller senere), så softwaren koster intet at hente, køre eller ændre. Et WordPress-site består af tre lag. Kernen er den fælles kode, som alle henter og opdaterer. Et tema styrer præsentationen, og plugins tilføjer adfærd; det er dér, projektets egen temahåndbog trækker grænsen. Begge griber ind i kernen gennem [hooks](https://developer.wordpress.org/plugins/hooks/), navngivne steder i WordPress-koden, hvor anden kode får lov at køre, og de findes i to slags, actions og filters. En action kører på et bestemt tidspunkt, for eksempel når et indlæg gemmes, og returnerer ingenting. Et filter modtager en værdi, ændrer den og giver den tilbage. Dette filter forkorter de automatiske uddrag af indlæg fra standardens 55 ord til 30: ```php add_filter( 'excerpt_length', function ( $length ) { return 30; } ); ``` Temaerne har skiftet form undervejs. Klassiske temaer bruger det PHP-skabelonsystem, der kom med WordPress 1.5 i 2005, og de er stadig meget udbredte. Bloktemaer er den nuværende metode: deres skabeloner er HTML-filer bygget af blokke, som kan redigeres i Site Editor, mens farver, skrifttyper og afstande ligger i en theme.json-fil. Hybridtemaer er klassiske temaer, der har taget nogle af blokfunktionerne til sig. Indholdet forlader også sitet som JSON gennem REST API'et, som selve blokeditoren er bygget på. En forespørgsel til sitets adresse /wp-json/ giver et kort over alle de ruter, det tilbyder. Offentligt indhold kan læses uden at logge ind, mens alt privat kræver godkendelse. Ethvert program kan hente de tre nyeste indlæg sådan her: ```sh curl -s 'https://example.com/wp-json/wp/v2/posts?per_page=3' ``` Til driften anbefaler projektet PHP 8.3 eller nyere, MySQL 8.0 eller MariaDB 10.11 eller nyere samt HTTPS, helst på Apache eller Nginx. Joomla og Drupal er CMS'er af samme slags, og de to andre veje, WordPress skal vejes op imod, er en skræddersyet applikation på et framework som Django og en statisk sitegenerator. ## Hvorfor det betyder noget Den egentlige beslutning bag WordPress handler om, hvem der ændrer sitet efter lanceringen, og hvem der holder det sikkert imens. WordPress giver medarbejdere uden teknisk baggrund en komplet editor: de kan udgive en side, skifte et billede, oprette en bruger eller lave menuen om på egen hånd. På et site, der ændrer sig hver uge, er den billigste rettelse den, der klarer sig uden udvikler. Licensen er gratis, men sitet er det ikke. GPL dækker softwaren, og wordpress.org mener, at plugins og temaer er afledte værker, der arver den samme licens. Udgifterne flytter til hosting, der kan køre PHP og en database, til timerne med at vælge, sætte op og teste et tema og til det løbende arbejde med at holde kerne, plugins, temaer og PHP-version opdateret. Den sidste post løber, så længe sitet lever, og et tilbud bør sige, hvem der bærer den. Vedligeholdelsen følger af, at WordPress er en levende applikation. Hvert besøg kører PHP mod en database, hvert plugin er tredjepartskode med samme adgang som kernen, og loginsiden står åbent på internettet, medmindre nogen sætter en ekstra lås foran. De fleste sites installerer mindre opdateringer og sikkerhedsopdateringer i baggrunden, som WordPress har tilladt siden version 3.7, mens en større udgivelse venter på, at nogen trykker på knappen, og serverens PHP følger sin egen kalender. En skræddersyet løsning passer til data og arbejdsgange, der slet ikke ligner sider og indlæg, og den kræver som regel en udvikler til hver ændring. Et statisk build har intet at lappe, mens siderne vises, og redaktørerne arbejder som regel i filer og et build-trin. WordPress dækker den brede midte: et ret almindeligt site, som ejerne selv driver, og hvor redigeringsskærmene er deres vedligeholdelse værd. Bindingen er beskeden, fordi koden er GPL, indholdet ligger i en almindelig SQL-database, og REST API'et udleverer indlæg, sider og taksonomier som JSON. ## Sådan ser det ud i praksis I virksomhedens arbejde er WordPress ét svar blandt flere, valgt med vilje. [Beskrivelsen af hundrede webapplikationer](/da/portfolio/developed-100-web-applications-using-html-html5-css-51/) dækker 2003–2014 og formulerer reglen bag valget. Når en kunde havde brug for noget skræddersyet, blev det bygget med HTML/HTML5, CSS/SCSS og Django. Når en kunde havde brug for et mere standardiseret site, som de også selv kunne passe, kom WordPress eller Joomla hurtigere i mål og gav mere mening. Beskrivelsen lægger vægten på dømmekraften frem for værktøjet. En del af arbejdet var at kende forskel på de to tilfælde: at tale en kunde fra en skræddersyet løsning, de ikke havde brug for, og over i en, når behovet var reelt. Som spørgsmål, en køber kan svare på inden et tilbud, ser den dømmekraft sådan ud: - Skal folk uden en udvikler rette i sitet hver uge, eller ændrer det sig et par gange om året? - Passer indholdet til sider, indlæg, kategorier og medier, eller kræver det sin egen datamodel og sine egne regler? - Hvem holder kerne, plugins og PHP opdateret, så længe sitet er i luften? - Hviler sitet på en håndfuld velholdte plugins eller på dusinvis, der er syet sammen for at efterligne en applikation? Ugentlige rettelser, indhold, der passer, en navngiven vedligeholder og en kort pluginliste peger mod WordPress eller et lignende CMS. Usædvanlige data, eller ingen til at holde det opdateret, peger mod en skræddersyet eller en statisk løsning. ## Hvor det går galt ### En rutineopdatering vælter sitet Nogen opdaterer et plugin, og bagefter viser en side en fejl, eller kontrolpanelet vil slet ikke åbne. Sitet havde samlet plugins i årevis, nogle af dem opgivet af deres forfattere, hvert af dem PHP fra tredjepart med fuld adgang, og to af dem kom i konflikt. Hold listen kort, og slet hvert plugin, sitet er holdt op med at bruge, sådan som håndbogen om hærdning beder om. Tag en sikkerhedskopi før hver opdatering, prøv de store på en kopi først, og vælg plugins, hvis forfattere stadig udgiver nye versioner. ### Egne ændringer forsvinder ved en opdatering eller et redesign En justering, der har virket i månedsvis, forsvinder den dag, temaet opdateres, eller en funktion, forretningen er afhængig af, er væk, da sitet får nyt udseende. I det første tilfælde har nogen rettet i filerne til et tema, de ikke selv har skrevet, og opdateringen har erstattet dem; temahåndbogen advarer om, at en funktion, der lægges direkte i et temas functions.php, forsvinder ved næste opdatering. I det andet tilfælde lå forretningskritisk adfærd i temaet og forsvandt sammen med det. Læg ændringer til andres temaer i et child-tema, og læg funktioner i et lille plugin, I selv ejer, der hægter sig på kernen, så temaet kun bærer præsentationen. ### En stjålet adgangskode bliver til kode på serveren Den, der stjæler én administrators adgangskode, kan gå fra at redigere indlæg til at køre sin egen PHP, fordi kontrolpanelet leveres med en editor til tema- og pluginfiler. Én linje i wp-config.php slår den editor fra, og det har samme virkning som at fjerne rettighederne edit_themes, edit_plugins og edit_files fra alle brugere: ```php define( 'DISALLOW_FILE_EDIT', true ); ``` Linjen lukker én vej blandt flere, og håndbogen siger klart, at den ikke stopper en angriber, der kan uploade ondsindede filer. Kombinér den med stærke adgangskoder, totrinsgodkendelse for hver administrator og så få administratorkonti, som arbejdet tillader. ### Sitet sakker bagud Kontrolpanelet viser et banner om en ny version i månedsvis, mens sitet kører en større udgivelse, eller en PHP-version, et godt stykke bag den aktuelle. Som standard installerer baggrundsopdateringerne mindre udgivelser og sikkerhedsudgivelser, mens hver større udgivelse venter på et klik, så et site kan lappe sig selv, mens hovedversionen og PHP halter bagefter, indtil et plugin, det er afhængigt af, kræver noget nyere. Sæt de store opdateringer i kalenderen, tjek samtidig PHP-versionen mod projektets side med krav, og test begge dele på en kopi før det kørende site. ## Læs mere - [WordPress Documentation](https://wordpress.org/documentation/) — projektets manual til at drive et site, fra udgivelse og medier til installation og vedligeholdelse. - [Requirements](https://wordpress.org/about/requirements/) — de versioner af PHP, MySQL og MariaDB, som projektet anbefaler i dag. - [Updating WordPress](https://wordpress.org/documentation/article/updating-wordpress/) — opdateringer i baggrunden, med ét klik og i hånden, og den sikkerhedskopi, der skal tages først. - [Hardening WordPress](https://developer.wordpress.org/advanced-administration/security/hardening/) — filrettigheder, databaserettigheder, kontakten til fileditoren og orden i plugins. - [Plugin Handbook: Hooks](https://developer.wordpress.org/plugins/hooks/) — hvordan actions og filters lader kode ændre WordPress uden at røre kernen. - [REST API Handbook](https://developer.wordpress.org/rest-api/) — ruter, endpoints og godkendelse for det API, som blokeditoren er bygget på.