Asky rig: WordPress content element probe

Vad REST-API:et når och inte når

WordPress har levererat ett REST-API för innehåll i kärnan sedan version 4.7, som släpptes den 6 december 2016. Varje inlägg, sida eller registrerad anpassad innehållstyp kan läsas och skrivas över HTTP under /wp-json/wp/v2/, utan att något tillägg är inblandat. Det är den enskilda omständighet som gör att ett externt verktyg kan redigera en webbplats som det inte självt hanterar.

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. Före den versionen krävde redigering av en egenhostad webbplats via API:et ett autentiseringstillägg, eller att man skrev ett själv.

Ytterligare två versioner spelar roll för allt som läser en webbplats utifrån. WordPress 5.0 ersatte den klassiska redigeraren med blockredigeraren den 6 december 2018, vilket är skälet till att innehållet numera kommer inslaget i HTML-kommentarer som markerar var varje block börjar och slutar. WordPress 5.5 lade till en XML-webbplatskarta på /wp-sitemap.xml den 11 augusti 2020, så de flesta webbplatser annonserar nu sina egna adresser utan tillägg.

Den skarpaste begränsningen är en som dokumentationen anger tydligt och som folk ändå möter med förvåning. Ett metafält vars nyckel börjar med ett understreck behandlas som skyddat, och 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.

Den praktiska följden är att läsa post_content inte är detsamma som att läsa sidan.

• 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.