Управлението на съдържанието може да бъде мъчно. Все пак споменаването на WordPress често предизвиква стенания от страна на някои разработчици. Със сигурност през 2018 г. има по-добър начин.
Е, нека да направим CMS без глава и да публикуваме статичен JSON, който може да се консумира от приложение без сървър — или рендиран от страната на сървъра с кеширане за максимална скорост! Бонус за прилагането на този подход: можем да намалим проблемите със сигурността, както и да използваме данните от нашата CMS на множество места. И никога не трябва да се справяме с натоварването на сървъра, защото всичко идва от AWS S3.
Да, WordPress има API, който можете да използвате. Но целта тук е да избегнете директен интерфейс с WordPress във вашите приложения, поддържайки всичко статично.
За тази публикация създадох репо, което идва пакетирано с всичко, което ще разгледаме тук, но тази публикация ще обясни какво се случва и как можете да пуснете своя собствена версия на програмата за качване и анализатора.
Репо на проекта: https://github.com/DrewDahlman/headless-wordpress
Добавка: https://github.com/DrewDahlman/wp-headless
въведение
Добре — сега нека поговорим малко за целите на този проект.
Сигурност: Тъй като няма да използваме WordPress в традиционния смисъл, можем да скрием всичко в някакво удостоверяване или дори просто да запазим проекта заедно с дъмповете на базата данни в github и когато са необходими промени, можете да завъртите проекта локално и публикувайте.
Скорост: Тъй като публикуваме статични файлове в s3, единственият път, когато имаме натоварване в нашата база данни, е когато публикуваме съдържание и правим промени, като правим това, нашето приложение ще прави само една заявка или бихме могли разделяме го и го зареждаме според нуждите, което винаги ще направи приложението по-бързо.
Друг начин, по който можем да ускорим нещата, е да направим изобразяване от страна на сървъра и да кешираме нашия файл с данни, което отново увеличава скоростта ни на доставка.
Страхотно, нека направим WordPress без глава.
Обърнете внимание, че примерният проект идва с файл с база данни, който автоматично ще настрои всички изброени по-долу неща за вас, но не се колебайте да си играете с него. Вие обаче ще трябва да предоставите свои собствени идентификационни данни за AWS, за да работят качванията.
Настройвам
Първото нещо, което искаме да направим, е да завъртим нашия екземпляр на WordPress. За това използвам примерното репо, но можете да направите това сами. След като стартираме, ще искаме да инсталираме нашите добавки. За този пример използвам:
Advanced Custom Fields Pro
Персонализирани типове публикации
Amazon Web Services
Amazon s3 и Cloudfront
WP Headless
Само с тези плъгини сме готови да започнем работа.
Първото нещо, което искаме да направим, е да настроим aws и нашата s3 кофа. Отидете на страницата с настройки на AWS и въведете своите идентификационни данни.
След като това е готово за пускане, нека настроим нашата кофа.
След като това е зададено, нека да настроим някои типове публикации и някои персонализирани полета. За този пример, нека направим персонализиран тип публикация на телевизионни предавания.
Страхотно, сега нека направим персонализирано поле: Име, Корица, Информация и повторител на знаци с име и снимка.
Добре – след като сме настроили нашите полета и типове публикации, следващото нещо, което трябва да направите, е да въведете малко съдържание.
Така че със създадена публикация, нека всъщност публикуваме и да видим как работи това. В плъгина „Publish Site“ има страница със съдържание, където можем да конфигурираме файловете, които ще публикуваме, и как са структурирани.
Настройване на съдържанието за това къде да се качват файловете в кофата, която настроихме по-рано, и след това даване на име на нашия файл с данни, както и избиране на публикациите, страниците, медиите, които искаме.
След това е толкова лесно, колкото да запазите и щракнете върху „Публикуване на етапа“ или „Публикуване на продукцията“.
Бум! Успех! Трябва да видите нещо подобно.
Така че нека проверим данните.
Това е прост пример, но вие бихте могли да имате още повече данни за вашите проекти. Забележете няколко хубави неща, които се случват тук. Получаваме необработените данни на WordPress за охлюва и подобни, но също така получаваме всички наши ACF полета, както и обекти на изображения и ако искаме свързани публикации или галерии — каквото искате да създадете!
Как работи това?
Кодът
Страхотно, сега всичко това работи. Но как работи? И как можете да създадете нещо подобно със собствени модификации за публикуване? Понякога може да не искате нито една от необработените данни на WordPress, може би само охлюв и ID.
Нека да проверим плъгина wp-headless. Направих това като плъгин, защото е по-лесно да се управляват кукичките на жизнения цикъл, но също така се придържам към идеята, че можем да поддържаме всичко живо само по себе си. Може би все пак искате да използвате традиционната тема, но да имате и това като опция.
Проверявайки кода, всичко е доста ясно. Плъгинът е хубав, защото проверява за зависимости и настройва първоначалната страница за публикуване с най-важното, за да го улесни. Можете напълно да пуснете своя собствена версия на това, ако искате други опции или по-прецизни опции.
Хубаво нещо тук също е настройката на среди, така че можем да имаме staging-FILENAME.json и production-FILENAME.json.
Там, където нещата стават интересни, е около ред 134, където имаме рекурсивна функция, която анализира публикация.
Това се извиква от нашата функция за публикуване, която преминава през полето за съдържание в нашата страница с настройки за публикуване на сайт.
Като преглеждаме всяка от нашите потенциални кофи със съдържание – както и публикациите вътре в тях – ние извикваме анализираща публикация, която преминава през всяко поле от WordPress и след това проверява за ACF полета, които може да имаме.
Това има способността да отиде едно ниво по-дълбоко по отношение на полетата на взаимоотношенията. (Това се дължи най-вече на факта, че свързана публикация може да препраща към тази публикация, която ще продължи вечно да се влага и свързва.)
Някои други неща тук: ние генерираме произволно име за нашия файл и го запазваме локално, преди да го качим. Ако успее, изтриваме произволната директория и файл и сайтът се публикува.
Инструментът за качване също е директен, той използва плъгините на AWS, които сме настроили преди, за определяне на целевата кофа. Обърнете внимание, че можете абсолютно да добавите многоезици към тези публикации, като добавите параметър за проверка на WPML, ако използвате това и добавите нещо staging-es-FILENAME.json или нещо подобно.
Програмата за качване получава името на файла, временния файл и крайната дестинация. Това проверява с нашите добавки и качва в S3.
Сега, когато всичко това е настроено и работи, можете да използвате този s3 файл навсякъде! Начините, по които използвах тази настройка, бяха инсталирането на WordPress на сървър под поддомейн с удостоверяване преди влизане, като например https://admin.example.com. Това отново запазва WordPress скрит от света като цяло и добавя ниво на сигурност към вашето приложение.
Можете дори да имате друго приложение, живеещо на сървъра ви, което консумира от S3 и рендира от страна на сървъра. Предимствата на всичко това са по-добра сигурност, повече опции за потребление на съдържанието и по-малко натоварване на сървъра.
Друг вариант, който можете да предприемете, е да направите дъмп на базата данни, след като сте направили редакции и да го запишете в репо на GitHub и да позволите на членовете на екипа да изтеглят надолу, да завъртят сайта, да правят промени и да публикуват. Отново, поддържане на нещата сигурни, без да се притеснявате за уязвимости.
Отново проверете приставката в Github и примерния проект, за да видите как работи това!
