Když redakce publikuje několik článků denně na desítkách WordPress webů, ruční kopírování do administrace je pomalé a náchylné k omylům. REST API umožňuje založit koncept, nahrát obrázek, nastavit autora a po kontrole změnit stav článku. Samotné úspěšné odeslání požadavku ale nestačí. Bez evidence operací může přerušené spojení vytvořit duplicitu, špatného autora nebo článek, který zůstal konceptem. Tento návod popisuje provozní postup, nikoli hotový univerzální skript pro každý web.
Co může redakce přes REST API skutečně dělat
WordPress vystavuje pro obsah vlastní API na doméně každého webu. Základní endpoint /wp-json/wp/v2/posts pracuje s příspěvky, další endpointy s médii, kategoriemi, uživateli nebo revizemi. Při vytvoření či úpravě článku lze poslat titulek, obsah, perex, stav, autora, rubriku a ID náhledového obrázku. Jaká pole konkrétní instalace přijímá, ovlivňují také pluginy a oprávnění účtu. Proto nejprve čtěte schéma a vyzkoušejte koncept na jednom webu, teprve pak zapojujte celou síť.
REST API je nástroj pro zápis, nikoli redakční plán. Před ním musí vzniknout zadání, výběr tématu, zdroje, článek a kontrola návazností. Pro provozní dohled navazuje článek monitoring WordPress webu. Když publikace proběhla, ale plánovaný termín se minul, hledejte příčinu také v návodu na WP-Cron.
| Krok | Zápis | Následná kontrola |
|---|---|---|
| Obrázek | Nahrát soubor do knihovny médií | ID, MIME typ, rozměry, alt a správná doména |
| Koncept | Vytvořit příspěvek se stavem draft | Vrácené ID, autor, slug, rubrika, obsah a média |
| Publikace | Změnit konkrétní ID na publish | Stav a datum v REST odpovědi |
| Veřejný výsledek | Žádný další zápis | HTTP, URL, titulek, obrázek a mobilní zobrazení |
Přístup: oddělte technický účet od veřejného autora
WordPress podporuje aplikační hesla pro autentizaci požadavků přes HTTPS. Heslo je při vytvoření zobrazeno jednou, patří ke konkrétnímu účtu a lze ho samostatně odvolat. Zprávy přes API se řídí právy tohoto účtu. Pro redakční automatizaci si určete, kdo smí vytvářet koncepty, nahrávat média a publikovat; nepůjčujte nástroji hlavní heslo do administrace. Přihlašovací údaje nepatří do článků, logů ani exportovaných reportů.
Technický účet nemusí být veřejným autorem. Při vytvoření článku zadejte schválené ID autora výslovně a po zápisu ověřte, že je zachované. Stejně určete rubriku, titulek, slug a náhledové médium. Nenechávejte na výchozích hodnotách nic, co má čtenář vidět. Pokud vám API odmítne nastavit autora, neobcházejte oprávnění; opravte přístup nebo proces.
- Pro každou integraci používejte samostatně pojmenovaný přístup, aby šel při problému odvolat jen on.
- Každý web mějte v evidenci s kanonickou doménou, účtem a schváleným autorem.
- V požadavcích neposílejte pole, která nechcete měnit; zvlášť datum, slug a stav staršího příspěvku.
- Před uložením citlivých provozních logů odstraňte autentizační hlavičky a tajné hodnoty.
Proč je bezpečnější začít konceptem
Při jednom požadavku rovnou na publish se chyba okamžitě ukáže veřejně. Koncept dává prostor zkontrolovat diakritiku, HTML tabulky, podpis autora, obrázek, interní odkazy a SEO údaje. Druhý zápis změní pouze schválený článek na publikovaný. Mezi kroky můžete zaznamenat vrácené ID a otisk obsahu. Když se koncept mezitím změnil v administraci, automatizace se má zastavit a porovnat rozdíl, ne cizí úpravu přepsat.
WordPress REST endpoint pro příspěvky rozlišuje stav draft, future a publish. Budoucí datum a čas se vztahují k časovému pásmu webu; u redakčního kalendáře ověřte také odpovídající GMT údaj. Chcete-li skutečně naplánovat vydání, musí fungovat spouštění naplánovaných úloh. Při okamžitém vydání zase kontrolujte běžnou veřejnou URL, ne pouze přihlášený náhled.
| Stav | Co znamená | Jaký důkaz uložit |
|---|---|---|
| Požadavek připraven | Je znám přesný cíl a obsah | Web, interní ID operace a schválená pole |
| Koncept vznikl | CMS vrátil ID příspěvku | Odpověď a následné čtení téhož ID |
| Publikace potvrzena | CMS uvádí publish | Opětovné načtení a datum |
| Veřejně ověřeno | Čtenář stránku skutečně vidí | URL, HTTP a kontrola stránky |
Co dělat, když se spojení přeruší po POST
To je nejdůležitější provozní pravidlo. Klient může ztratit spojení až poté, co WordPress zápis provedl. Bez odpovědi tedy nevíte, zda příspěvek vznikl. POST naslepo neopakujte. Nejprve v CMS dohledávejte stav podle vlastního záznamu operace, času a dalších znaků; je-li známé ID, čtěte přímo toto ID. Samotná shoda slugu nebo titulku nemusí prokázat, že nalezený článek vznikl právě vaším pokusem. V nejasném případě předejte rozhodnutí člověku.
Stejné pravidlo platí pro nahrání média a následné přiřazení náhledu. Pokud byl obrázek vytvořen, není důvod nahrát ho znovu. Rozlišujte neznámý výsledek samotného nahrání, zjištěný existující soubor a potvrzenou úpravu metadat. Zápis ve dvou etapách se může zdát pomalejší, ale u sítě magazínů významně usnadňuje opravu po chybě.
- Před POST uložit záměr: přesný web, typ objektu, interní ID úlohy a povolená pole.
- Po odpovědi uložit vrácené ID a stav. Neskrývat chybovou odpověď za obecné „neúspěšné“.
- Při nejasném výsledku nejprve provést čtení CMS. Pokus o opakování je nový vědomý krok až po reconciliaci.
- Před změnou stavu znovu načíst koncept a porovnat jeho obsah s verzí schválenou redakcí.
- Po zveřejnění ověřit veřejnou stránku i několik relevantních odkazů.
Kontrola kvality pro síť magazínů
Jedna společná publikační šablona pomáhá, ale každý web může mít jiné rubriky, autora, pravidla obrázků či data vydání. Do manifestu dávky proto uložte mapování pro konkrétní doménu. Nezaměňujte jeden technický proces za povolení hromadně opravovat starší obsah. Před každým zápisem ověřte čerstvý inventář a unikátnost tématu. V dlouhých návodech zkontrolujte tabulky na mobilu a skutečně otevřete interní cíle. Změny pluginů v publikačním procesu nejprve vyzkoušejte na testovací kopii webu.
Publikační kontrola má dvě úrovně: REST potvrdí data v CMS, veřejná stránka potvrdí, co dostane nepřihlášený čtenář. CDN nebo cache může krátce ukazovat starou verzi. Pokud se tyto pohledy liší, nezapisujte tentýž text znovu; nejprve zjistěte, zda čekáte na obnovu cache. U dlouhých sérií zaznamenávejte dokončené a nedokončené operace zvlášť, aby se po přerušení nepřehrála celá dávka.
Modelový průchod jedním článkem
Představme si redakci, která chce vydat návod na jednom ze svých magazínů. V evidenci je schválené téma, kanonická doména, veřejný autor a ID rubriky. Editor připraví text a fotografii. Automatizace nejprve zkontroluje, že na daném webu podobný příspěvek už neexistuje. Potom nahraje fotografii, přečte z CMS její ID a ověří formát, alt text a rozměry. Teprve následně vytváří koncept příspěvku. Kdyby se při uploadu přerušilo spojení, zjišťuje stav média; neposílá obrazová data znovu naslepo.
Koncept se vrátí například s ID 123. Editor ho znovu načte přímo podle tohoto ID a porovná obsah, obrázek, autora i rubriku s verzí ke schválení. Pokud kolega mezitím opraví titulek v administraci, automatizace nemá jeho práci bez upozornění přepsat. Po schválení změní stav ID 123 na publikovaný, přečte ho z REST a otevře veřejnou URL. Výsledkem je doložitelný sled operací, ne pouze zpráva „odesláno“. Číslo 123 je čistě modelový příklad.
Jak si rozdělit chyby
Chyba oprávnění znamená, že účet nesmí provést požadovanou akci; řešte práva, ne opakování požadavku. Validační chyba znamená nesprávné nebo chybějící pole; opravte payload. Serverová chyba může mít jasný výsledek nebo nejistý výsledek podle okamžiku selhání. Přerušené spojení po zápisovém požadavku je zvlášť nebezpečné, protože WordPress mohl operaci dokončit. U každé kategorie evidujte kód odpovědi, čas a interní ID úlohy, ale neukládejte tajné přístupové údaje.
Ve větší síti nastavte automatizaci tak, aby chyba jednoho webu nezrušila důkaz o pěti jiných úspěšně zveřejněných článcích. Stav dávky má ukázat, co je připravené, vytvořené, publikované a veřejně ověřené. Při pokračování po přerušení začněte čtením posledního doloženého stavu, nikoli opakováním celého seznamu úkonů. Jestliže chyby vznikají při souběhu více dávek, porovnejte je s diagnostikou zátěže hostingu.
| Kontrola | REST | Veřejná stránka |
|---|---|---|
| Autor a datum | ID autora a datum | Jméno a zobrazené datum |
| Obsah | Raw HTML a excerpt | Čitelný text, seznamy a tabulky |
| Obrázek | featured_media, alt, MIME | Načtená náhledovka i mobilní varianta |
| Odkazy | URL v obsahu | Otevřené cílové články bez chyby |
Časté otázky
Potřebuji pro REST API samostatný plugin?
Pro základní práci s příspěvky a médii ne; WordPress má vlastní REST API. Plugin může přidat pole či změnit oprávnění, proto jejich podobu na konkrétním webu ověřte.
Mohu poslat článek rovnou jako publikovaný?
Ano, endpoint to umožňuje. U redakční automatizace je koncept s následnou kontrolou bezpečnější způsob, jak zabránit zveřejnění chyby.
Je slug dostatečný identifikátor pro obnovení přerušeného zápisu?
Ne vždy. Může existovat starší obsah nebo souběžný zápis. Uchovávejte vlastní záměr operace, vrácené ID a následný důkaz z CMS.
Jak přidat obrázek do článku?
Nejprve nahrajte médium a ověřte jeho ID, typ, alt a případné varianty. Potom toto ID nastavte jako náhledové médium příspěvku a po publikaci zkontrolujte veřejnou stránku.
Proč se REST a veřejný web někdy liší?
Veřejnou odpověď může obsluhovat cache. Nejdřív zkontrolujte čas a obsah v CMS, potom čerstvou veřejnou odpověď a až následně běžnou URL.
