Att publicera till WordPress över REST-API:et

Written by

in

Hur publicerar man ett inlägg via REST-API:et?

Ett nytt inlägg skapas genom att skicka en POST-förfrågan till /wp-json/wp/v2/posts. Förfrågans kropp skickas som JSON och innehåller minst tre fält: title (inläggets rubrik), content (brödtexten, som kan innehålla block-HTML) och status (“publish” för att publicera direkt, “draft” för att spara som utkast).

Autentiseringen sker med Basic Auth. Kombinera användarnamnet och applikationslösenordet med ett kolon, Base64-koda strängen och skicka den i headern Authorization: Basic {kodad sträng}. Content-Type sätts till application/json.

Om förfrågan lyckas svarar WordPress med statuskod 201 Created och returnerar det skapade inläggets fullständiga JSON-objekt, inklusive det tilldelade id:t, länken till inlägget och den sparade statusen. Ett svar med 401 betyder att autentiseringen misslyckades, medan 403 innebär att användaren saknar rätt behörighet.

Hur sätter man kategorier, taggar och utvald bild i samma förfrågan?

Lägg till fältet categories som en lista med kategori-ID:n och tags som en lista med tagg-ID:n i samma JSON-kropp. För att sätta en utvald bild, ange featured_media med mediaobjektets ID. Slug, excerpt och author kan också skickas i samma POST-förfrågan.

Hur en svarsmotor läser en sida

Hur uppdaterar eller raderar man ett befintligt inlägg?

Skicka en PUT- eller PATCH-förfrågan till /wp-json/wp/v2/posts/{id} med de fält du vill ändra. PUT ersätter hela resursen, medan PATCH uppdaterar bara de angivna fälten. För att radera ett inlägg skickar du en DELETE-förfrågan till samma adress. Som standard läggs inlägget i papperskorgen; lägg till parametern force=true för att ta bort det permanent.

Vad når REST-API:et och vad når det inte?

REST-API:et når alla inlägg, sidor och registrerade anpassade innehållstyper, men det når inte skyddade metafält eller layout som ägs av en sidbyggare. WordPress har levererat detta API i kärnan sedan version 4.7, som släpptes den 6 december 2016. Varje resurs kan läsas och skrivas över HTTP under /wp-json/wp/v2/, utan att något tillägg är inblandat.

Ett applikationslösenord är en inloggningsuppgift per applikation, skild från kontots vanliga lösenord, och kan återkallas för sig utan att personen låses ute. WordPress 5.6 införde dem den 8 december 2020, och de fungerar bara över HTTPS. Lösenordet skapas under Användare, din profil, sektionen “Applikationslösenord” i wp-admin. Värdet visas bara en gång, så det måste kopieras direkt.

Tre förutsättningar måste vara uppfyllda för att REST-API:et ska ta emot en publiceringsförfrågan:

  • Snygga permalänkar, annars svarar /wp-json/ med 404 och bara ?rest_route= fungerar.

  • HTTPS, som applikationslösenord kräver.

  • En användare med edit_posts, eftersom API:et mappar behörigheter per innehållstyp.

Varför syns inte sidbyggarens layout via API:et?

Ett metafält vars nyckel börjar med ett understreck behandlas som skyddat. WordPress exponerar det inte via REST-API:et om inte ett tillägg registrerar det med show_in_rest. En sidbyggare som lagrar sin layout under en nyckel som _elementor_edit_mode är därför osynlig för en API-klient, trots att webbplatsen renderas från den.

Om innehållet saknas eller är tomt äger en sidbyggare layouten. I så fall finns tre alternativ:

  • Registrera det skyddade metafältet med show_in_rest i ett eget tillägg så att API:et exponerar det.

  • Publicera genom sidbyggarens egen lagring i stället för via post_content.

  • Acceptera att post_content inte kommer att runda hela vägen, och behandla det renderade HTML:et som den auktoritativa källan.

Elementor, Divi och WPBakery är vanliga byggare som lagrar layout under skyddade nycklar.

Vill du se hur dina sidor ser ut via API:et?

Vi går igenom dina tjugo viktigaste sidor och visar vad REST-API:et faktiskt returnerar, vad som saknas och vad en svarsmotor kan plocka upp. Inget konto behövs.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *