Створення веб-сайту за допомогою Nuxt.js та WordPress REST API

Оновлення:
Тепер ви можете використовувати мою котельну плиту з громадського репо:
https://github.com/bovas85/nuxt-headless
(будь ласка, позначте зірочку, якщо ви цінуєте це, не соромтеся робити внесок).

Часто ми опиняємось у становищі, коли наші клієнти хочуть Систему управління вмістом (CMS і далі), яка дозволить їм редагувати свої сторінки, не знаючи HTML-код для цього.

Тоді зазвичай це вибір між замовленим CMS та WordPress (останнім часом ми бачимо, що з'являється все більше "безголівкових" CMS, а також дуже допустима альтернатива розмітки або статичні параметри CMS).

У нашому випадку ми вибрали WordPress з кількох причин:
- Це солідна CMS з багаторічним досвідом роботи на місцях
- Проблем із безпекою зараз майже немає, враховуючи автоматичні оновлення безпеки, починаючи з версії 4.7 (я можу помилитися у версії, не цитуйте мене про це).
- API WordPress REST надає нам доступ до декількох полів (і спеціальних), без необхідності обслуговувати весь передній край за допомогою WordPress.

Наш розробник Backend також був більш знайомий з PHP, Laravel та WordPress, ніж інші технології, тому, на щастя, ми вирішили врешті-решт WordPress.

Що стосується Frontend, я відповідав за вибір стека, і так як я дуже люблю Vue.js (Vue 2), я, безумовно, штовхнув це вперед, використовуючи Nuxt.js для серверного візуалізації (SSR відтепер).

Частина 1, що таке Nuxt.js?

Програми Nuxt.js:
1) автоматично згенерована маршрутизація з середньою програмою, валідаторами тощо
2) повна підтримка SSR з коробки з підтримкою vuex
3) система сторінок з асинхронними гачками даних, переходами, індикатором завантаження тощо
4) макети системи поза коробкою
5) обробка метаданих поза коробкою з підтримкою SSR
6) всі модні модулі nuxt, що надають такі речі, як PWA, автентифікація, підтримка в режимі офлайн тощо
7) умовність щодо конфігураційного підходу, який я віддаю перевагу
8) Громада Vue devs, яка працює з однаковим підходом.
Точка 8 особливо велика, оскільки спільнота Vue надзвичайно розділена, через те, що Vue є прогресивною основою.
Люди використовують Vue настільки багато різних способів, що велика частина спільноти Vue, яка насправді використовує Vue однаково, чудово.
Це виключає SSR ...

- @ gustojs # 2934 з каналу VueLand Discord

Як ви можете сказати, ці функції є величезною перевагою для невеликого агентства, яке не може витратити занадто багато часу на розробку архітектури підприємства для їх стека.
Нещодавно WordPress поставив REST api всередині основного пакету (4.6.0), тому я вирішив спробувати його на нашому першому веб-сайті.

Це була міграція з кордону AngularJS ...

Частина 2, Початкові налаштування

Першим необхідним моментом було те, щоб веб-сайти були настільки оптимальними для SEO, як це було з Angular 1 / 1.5, де єдиним простим рішенням було prerender.io (яке не було реалізовано).

Я раніше пробував Nuxt для побічного проекту, але речі ніколи не клацають, якщо ви над цим не працюєте.

Я був знайомий з VueJS, але початкова настройка Nuxt залишила мене трохи сумнівною у можливостях. Це виглядало занадто просто, щоб бути правдою, і без жодного конфігурації від початкового CLI.

Ви можете почати, встановивши vue cli, якщо цього ще не зробили:

npm install -g vue-cli

(стежте за vue-cli 3, який незабаром вийде, що може змінити цю наступну команду)

Потім за допомогою vue-cli ви можете запустити новий Nuxt проект, набравши текст:

vue init nuxt-community / startter-template <ім'я_проекту>

Де <назва проекту> назва вашої папки та проекту.
Ви будете складати каталог, який містить кілька інших та файл nuxt.config.js:

початковий файл nuxt.config.js для моєї розмови про зустріч

Перше, що потрібно зрозуміти про Nuxt, це те, що це безпроблемна система навколо VueJS та SSR.

Він використовує лише модулі та бібліотеки, які вже доступні у VueJS, але впорядковує їх у дійсно акуратну, впорядковану структуру папок.

структура папки для nuxt проекту

Частина 3, Заглиблюючись

Основна проблема спочатку полягала в тому, як інтегрувати sass та використовувати змінні sass у мій проект.
Мені довелося зробити цей чаклун, щоб мати змінні в кожному компоненті одного файлу (SFC) або на сторінці

Потім це стало набагато простіше завдяки Nuxt модулю, який можна просто додати до nuxt.config у масиві зі списком змінних sass для завантаження в усьому світі.

Наступним кроком було з'ясування способів управління державою.

Чомусь я хоч глобальний міксин був хорошою ідеєю

Реальність полягає в тому, що коли у вас є пара компонентів, можливо, навігаційна панель або деякі модалі, настав час завантажувати Vuex.

Зробити це в Nuxt так само просто, як:

index.js всередині / зберігати папку з деякими прикладними мутаціями та nuxtServerInit

Nuxt також дає змогу заздалегідь завантажити кожне значуще стан за допомогою дії NuxtServerInit у магазині.
Це дозволяє попередньо завантажити все необхідне без необхідності використання змонтованого для завантаження (і втрати на SSR таким чином).

Існують і інші методи, які можна використовувати поза магазином, а саме: asyncData (що завантажує дані в компонент) і витяг (який здійснює мутації або розсилає дії).

Вони можуть бути використані, якщо вам потрібно щось лише локально в межах компонента чи сторінки.

asyncData повертає нову властивість даних на локальній сторінці .vueми можемо взяти нові дані з API в магазин із завантаженням

Тут потрібно усвідомити одне, що ми маємо справу з двома інстанціями.
Один на сервері, віртуальний і не видимий, і один на стороні клієнта.

Це означає, що при розробці Nuxt і будь-якого серверного додатка є деякі добутки, але Nuxt робить ці gotchas дуже обмеженими і простими для подолання.

Nuxt вбудований у компонент , який може обгортати будь-що інше, включаючи інші компоненти, якщо у вас є один кореневий елемент всередині нього.

no-ssr запускає доданий код тільки на стороні клієнта (без SSR)

Цей плагін дозволяє жити тільки на стороні клієнта, і особливо корисний при роботі з сторонніми плагінами, які можуть містити посилання на елементи вікна або DOM і не потрібні на стороні сервера.

Якщо ви цього не зробите або я щось зараз покажу, ви можете зіткнутися з іншою структурою дерева, про яку Nuxt сповістить вас:

Інша проблема - це те, як бібліотеки та компоненти завантажуються в Nuxt.
Ми завантажуємо їх, створюючи додатки в папці плагінів і додаючи за допомогою Vue.use, Vue.component або Vue.directive з ним.

Другий крок тут - додати цей плагін у nuxt.config, і тут ми можемо вказати, чи є плагін, готовий до ssr (просто ввівши шлях до плагіна), чи ні, вказавши ssr: false там.

Частина 4: розгляд викликів CMS та API WordPress

Як тільки основний проект буде налаштований, і ви почнете працювати з кожною сторінкою, найшвидший і найкращий підхід, на мою думку, - це додати плагін під назвою:
Розширені спеціальні поля (ACF)
до бекенда WordPress.

Це додає функціональні функції поля на сторінки та публікації в WordPress.
Щоб поширити це на API REST, вам також знадобиться плагін під назвою
ACF до REST API

Деякі корисні добавки:
Поля фільтрів API WP REST
Поля фільтра Дозволяє фільтрувати поля, повернені api.

Чисті таксономії WP REST API
Цей плагін включає всі доступні атрибути таксономії в API WordPress REST (v2) без додаткових запитів API.

Кеш API API RP
Увімкніть кешування для WordPress REST API та збільшити швидкість вашої програми. (Я не рекомендую використовувати цей плагін)
Скрізь тут:
Якщо ви робите запити на пошту (наприклад, плагін contact-form-7), переконайтеся, що ви не використовуєте цей плагін, або якщо ви це зробите, відфільтруйте рядок "контакт-форми" у function.php, як показано нижче:

add_filter ('rest_cache_skip', функція ($ skip, $ request_uri) {
  if (! $ skip && false! == stripos ($ request_uri, 'contact-form-7')) {
    повернути правду;
  }
  повернути $ пропустити;
}, 10, 2);

Меню API WP REST
Розширює API WP на маршрути меню WordPress.

Наступним кроком було налаштування кінцевих точок API.
Я особисто використовував файл config.js, який я можу імпортувати так:

імпортувати Config з '~ / properties / config';

Це дозволить мені мати чітке та налаштоване кінцеве місце для всіх моїх сторінок.

Вищезазначене частково взято у розкішного туроператора Антилофія.
Веб-сайт ще не працює, але я його оновлю, як тільки він буде. Слідкуйте за налаштуваннями;)

Коли у вас є вищевказаний конфігурація, ви можете налаштувати додаток для отримання даних або на nuxtServerInit, або за допомогою fetch / asyncData.

Після цього ви можете заповнити кожен розділ веб-сайту за допомогою розширених спеціальних полів, а також решта доступних полів WordPress API (все, що насправді).

Сервер оновлюватиме вміст кожного разу, коли він завантажує сеанс для користувача.

Ви можете створити динамічні сторінки, використовуючи структуру папок:
Де - ім'я потрібного параметра (наприклад: призначення)

Це дає вам доступ до параметра за допомогою:

це. $ route.params. 

Наприклад, /pages/:mexico/index.vue повернеться

це. $ route.params.destination === 'mexico'

Пам'ятайте, що у asyncData чи файлі ви не маєте доступу до "цього", як це працює перед монтажем сторінки, але ви можете отримати доступ до "контексту".

async fetch ({додаток, магазин, парами}) {
  // це дає вам доступ до маршрутів параметів із скороченими парамами
  // але також до магазину та інших значень програми
  // перевірити всі поля на https://nuxtjs.org/api/context/
}

Якщо у вас багато дзвінків API, я можу запропонувати два варіанти:
- Використовуйте плагін WP REST API Cache, як WP REST API Cache
- Кеш nuxtServerInit дзвінків (бажано)

Для останнього це досить складно і вимагає використання механізмів lre-cache та пакета axios-extensions.
Нижче наведено суть усіх файлів.

Посилання: https://gist.github.com/bovas85/8b5610ac94dd036628f53f702b300a64

магазин vuexдодайте це розширення до axios та додайте плагін axios.js до nuxt.config.js

Це особливо корисно, якщо ви генеруєте статичний сайт (nuxt-генерація), оскільки nuxtServerInit буде працювати один раз на створеній сторінці (уявіть, якщо у вас є 20 динамічних сторінок, то він запустить 20 * кількість дзвінків api).

Частина 5: Як щодо розгортання програми?

Ми спробували два маршрути з цим.
1) Ми використовували статичний сайт, створений на нутрі, що обслуговується зі звичайним сервером (спосіб старої школи). Швидкий, але недолік - якщо у вас багато динамічних сторінок, відображення динамічних маршрутів є дещо складним і повільним (перевірте тут, як це зробити);
2) Ми використовували службу, розміщену на nodeJS, як зараз (є декілька, або навіть просто використовувати ваш хостинг, якщо він підтримує NodeJS, у нас цього не було).

Я написав статтю про певну ґетчу під час переміщення домену на Асистент з GoDaddy, її ви можете прочитати тут:

"Розгортання програми SSR в Zeit Now від GoDaddy" @MoustacheDsign https://medium.com/@moustachedesign/deploying-your-ssr-app-to-zeit-now-from-godaddy-41b51302375f

Після встановлення кліпу ви просто введіть зараз, і він розгорне ваш SSR-сайт за лічені секунди (буквально, залежно від вашого підключення та наскільки великий сайт;))

Результат - дуже невеликий, оптимізований та асинхронний пакет. Існує автоматичне розділення шматок сторінок поза коробкою, тому вам більше не потрібно турбуватися про ці хитрі шматки.

непогано

Частина 6: Що далі для Vue та Nuxt?

Vue і Nuxt більше не є новачком, є велика екосистема плагінів, модулів і бібліотек, які доступні і стануть все більшими і більшими.

Деякі з тих, що я використовував, включають плагіни для слайдерів, каруселей, ледачого завантаження зображення, і більшість часу можна включати, навіть якщо вони не є Nuxt або навіть Vuejs.

Nuxt.js - це OpenCollective та фінансується самостійно.
Якщо ви любите це як я, подумайте про пожертви на https://opencollective.com/nuxtjs

Виправляйте проблеми для Nuxt сюди (він інтегрується з проблемами Github, досить акуратним!):
https://nuxtjs.cmty.io

Це обгортання

У вас є які-небудь питання?
Якщо так, сміливо коментуйте внизу, або твітте мені @moustacheDsign

Деякі сайти, які я створив за таким підходом:

Якщо у вас виникли запитання, дайте відповідь тут або твітте мене @moustacheDsign

Спасибі від кота