# WordPress ## Hva det er WordPress, ofte forkortet til WP, er et system for innholdsstyring (CMS) med åpen kildekode: PHP-programvare som holder innleggene, sidene, mediene, brukerne og innstillingene til et nettsted i en MySQL- eller MariaDB-database, og som setter sammen hver side av dem når noen ber om den. WP er det samme prefikset som programmets egne filer og mapper bærer (`wp-config.php`, `wp-content`, `wp-admin`). Programvaren er utgitt under GPLv2 (eller senere), så den koster ingenting å laste ned, kjøre eller endre. Et WordPress-nettsted består av tre lag. Kjernen (_core_) er den felles koden alle laster ned og oppdaterer. Et tema styrer presentasjonen, og utvidelser (_plugins_) legger til oppførsel; det er der prosjektets egen håndbok for temaer trekker grensen. Begge griper inn i kjernen gjennom kroker (_hooks_), navngitte punkter i WordPress-koden der annen kode får lov til å kjøre, og krokene finnes i to slag: handlinger (_actions_) og filtre (_filters_). En handling kjører i et bestemt øyeblikk, f.eks. når et innlegg lagres, og returnerer ingenting. Et filter tar imot en verdi, endrer den og gir den tilbake. Dette filteret korter ned de automatiske utdragene av innlegg fra standardlengden på 55 ord til 30: ```php add_filter( 'excerpt_length', function ( $length ) { return 30; } ); ``` Temaene har skiftet form gjennom årene. Klassiske temaer bruker malsystemet i PHP som kom med WordPress 1.5 i 2005, og de er fortsatt mye i bruk. Blokktemaer er dagens tilnærming: malene deres er HTML-filer bygd av blokker, som kan redigeres i nettstedsredigereren (_Site Editor_), mens farger, skrifter og avstander ligger i en `theme.json`-fil. Hybridtemaer er klassiske temaer som har tatt i bruk noen av blokkfunksjonene. Innholdet kan også forlate nettstedet som JSON gjennom REST-API-et, som blokkredigereren selv er bygd på. En forespørsel til adressen `/wp-json/` på nettstedet returnerer et kart over hver rute det tilbyr. Offentlig innhold kan leses uten innlogging, og alt som er privat, krever autentisering. Ethvert program kan hente de tre siste innleggene slik: ```sh curl -s 'https://example.com/wp-json/wp/v2/posts?per_page=3' ``` For å kjøre det anbefaler prosjektet PHP 8.3 eller nyere, MySQL 8.0 eller MariaDB 10.11 eller nyere, og HTTPS, helst på Apache eller Nginx. Joomla og Drupal er systemer for innholdsstyring av samme slag, og de to andre veiene å veie det mot, er en skreddersydd applikasjon på et rammeverk som Django og en statisk nettstedsgenerator. ## Hvorfor det er viktig Den egentlige beslutningen bak WordPress er hvem som endrer nettstedet etter lansering, og hvem som holder det trygt mens de gjør det. WordPress gir ansatte uten teknisk bakgrunn en komplett redigerer: de kan publisere en side, bytte et bilde, legge til en bruker eller bygge om en meny uten å opprette en sak. På et nettsted som endres hver uke, er den billigste endringen den som ikke trenger en utvikler. Lisensen er gratis, men nettstedet er det ikke. GPL dekker programvaren, og wordpress.org legger til grunn at utvidelser og temaer er avledede verk som arver den samme lisensen. Utgiftene flytter seg andre steder: et webhotell som kjører PHP og en database, timene det tar å velge, sette opp og teste et tema, og det løpende arbeidet med å holde kjernen, utvidelsene, temaene og PHP-versjonen oppdatert. Den siste kostnaden løper så lenge nettstedet lever, og et tilbud bør navngi hvem som bærer den. Vedlikeholdet følger av at WordPress er en levende applikasjon. Hvert besøk kjører PHP mot en database, hver utvidelse er tredjepartskode som kjører med samme tilgang som kjernen, og innloggingsskjermen står åpent ut mot internett med mindre noen setter en ekstra lås foran den. De fleste nettsteder installerer mindre versjoner og sikkerhetsutgivelser i bakgrunnen, slik WordPress har tillatt siden versjon 3.7, mens en hovedversjon venter til noen trykker på oppdateringsknappen, og PHP på serveren følger en tidsplan av sitt eget. Et skreddersydd bygg passer data og arbeidsflyter som ikke ligner sider og innlegg i det hele tatt, og det trenger som regel en utvikler for hver endring. Et statisk bygg etterlater ingenting å patche når forespørslene kommer, og redaktørene jobber som regel gjennom filer og et byggesteg. WordPress passer den brede midten: et ganske standard nettsted som eierne skal drive selv, der redigeringsskjermene er verdt vedlikeholdet de fører med seg. Innlåsingen holder seg beskjeden, fordi koden er GPL, innholdet ligger i en vanlig SQL-database, og REST-API-et serverer innlegg, sider og taksonomier som JSON. ## Slik ser det ut i praksis I selskapets arbeid er WordPress ett svar blant flere, valgt med vilje. [Oppsummeringen av hundre webapplikasjoner](/nb/portfolio/developed-100-web-applications-using-html-html5-css-51/) dekker 2003–2014 og sier rett ut regelen bak valget. Der en kunde trengte noe skreddersydd, ble det HTML/HTML5, CSS/SCSS og Django. Der en kunde trengte et mer standard nettsted som den også kunne administrere selv, kom WordPress eller Joomla raskere i mål og var det mer fornuftige svaret. Det siden verdsetter, er skjønnet, ikke verktøyet. En del av arbeidet den beskriver, var å skille de to tilfellene fra hverandre: å få en kunde til å droppe en skreddersydd løsning den ikke trengte, og til å velge en når behovet var reelt. Stilt som spørsmål en kjøper kan svare på før det bes om noe tilbud, ser skjønnet slik ut: - Skal folk uten en utvikler redigere nettstedet hver uke, eller endres det noen få ganger i året? - Passer innholdet i sider, innlegg, kategorier og medier, eller trenger det en egen datamodell og egne regler? - Hvem skal holde kjernen, utvidelsene og PHP oppdatert så lenge nettstedet er i drift? - Skal nettstedet lene seg på en håndfull godt vedlikeholdte utvidelser, eller på dusinvis av dem sydd sammen for å etterligne en applikasjon? Ukentlige endringer, innhold som passer, en navngitt vedlikeholder og en kort liste over utvidelser peker mot WordPress eller et CMS av samme slag. Uvanlige data, eller ingen til å holde det oppdatert, peker mot et skreddersydd bygg eller et statisk. ## Hvor det går galt ### En rutinemessig oppdatering ødelegger nettstedet Noen oppdaterer en utvidelse, og en side begynner å vise en feilmelding, eller administrasjonspanelet nekter å laste. Nettstedet hadde samlet utvidelser i årevis, noen av dem forlatt av forfatterne, hver av dem tredjeparts PHP som kjørte med full tilgang, og to av dem kolliderte. Hold listen kort, og slett hver utvidelse nettstedet har sluttet å bruke, slik herdingshåndboken ber om. Ta en sikkerhetskopi før hver oppdatering, prøv de store på en kopi først, og velg utvidelser der forfatterne fortsatt gir ut nye versjoner. ### Egne endringer forsvinner ved en oppdatering eller et redesign En justering som virket i månedsvis, forsvinner den dagen temaet oppdateres, eller en funksjon virksomheten er avhengig av, blir borte når nettstedet får et nytt utseende. I det første tilfellet redigerte noen filene i et tema de ikke hadde skrevet selv, og oppdateringen erstattet dem; temahåndboken advarer om at en funksjon som legges rett inn i `functions.php` i et tema, forsvinner ved neste oppdatering av temaet. I det andre tilfellet lå oppførsel som nettstedet var avhengig av, i temaet, så den forsvant sammen med temaet. Legg endringer i andres temaer i et undertema (_child theme_), og legg funksjoner i en liten egen utvidelse som kobler seg på kjernen, så temaet bærer presentasjonen og ingenting annet. ### Et administratorpassord blir til kode på serveren Den som stjeler passordet til én administrator, kan gå fra å redigere innlegg til å kjøre sin egen PHP, fordi administrasjonspanelet leveres med en redigerer for filene i temaer og utvidelser. Én linje i `wp-config.php` slår den redigereren av, noe som har samme virkning som å fjerne rettighetene `edit_themes`, `edit_plugins` og `edit_files` fra hver bruker: ```php define( 'DISALLOW_FILE_EDIT', true ); ``` Linjen stenger én vei blant flere, og håndboken sier rett ut at den ikke stopper en angriper som kan laste opp ondsinnede filer. Kombiner den med sterke passord, totrinnsautentisering for hver administrator og så få administratorkontoer som arbeidet tillater. ### Nettstedet sakker akterut Administrasjonspanelet viser et banner om en ny versjon i månedsvis, mens nettstedet kjører en hovedversjon, eller en PHP-versjon, godt bak den gjeldende. Som standard tar bakgrunnsoppdateringene seg av mindre versjoner og sikkerhetsutgivelser, mens hver hovedversjon venter på et klikk, så et nettsted kan fortsette å lappe seg selv mens hovedversjonen og PHP-en sakker akterut, helt til en utvidelse det er avhengig av, krever noe nyere. Sett de store oppdateringene i kalenderen, sjekk PHP-versjonen mot prosjektets side med krav samtidig, og test begge på en kopi før det levende nettstedet. ## Les mer - [WordPress Documentation](https://wordpress.org/documentation/) — prosjektets håndbok for å drive et nettsted, fra publisering og medier til installasjon og vedlikehold. - [Requirements](https://wordpress.org/about/requirements/) — versjonene av PHP, MySQL og MariaDB som prosjektet anbefaler i dag. - [Updating WordPress](https://wordpress.org/documentation/article/updating-wordpress/) — oppdateringer i bakgrunnen, med ett klikk og for hånd, og sikkerhetskopien som skal tas først. - [Hardening WordPress](https://developer.wordpress.org/advanced-administration/security/hardening/) — filrettigheter, databaserettigheter, bryteren for filredigereren og hygiene for utvidelser. - [Plugin Handbook: Hooks](https://developer.wordpress.org/plugins/hooks/) — hvordan handlinger og filtre lar kode endre WordPress uten å røre kjernen. - [REST API Handbook](https://developer.wordpress.org/rest-api/) — ruter, endepunkter og autentisering for API-et som blokkredigereren er bygd på.