Вийшов WordPress 5.8 “Tatum” з блок-віджетами, двофарбові фільтри та блоком “Цикл запитів”

20 липня побачив світ WordPress 5.8 «Татум», названий на честь джазового піаніста Арта Татума. Це другий великий реліз 2021 року. Він включає редагування шаблонів, підтримку JSON-файлів для тем, блоки, пов’язані з темами, двофарбові фільтри для медіа файлів та віджети блокування.

Остання версія має багато інших чудових функцій, таких як підтримка нових смайлів, оновлення поля URI для розробників плагінів. Випуск 5.8 припиняє підтримку IE11. Ви можете, нарешті, попрощатися з епохою Internet Explorer.

Метт Малленвег відповідав за звільнення WordPress 5.8. В останньому випуску взяли участь 530 добровольців. Команда розробників закрила 320 Trac-квитків і понад 1500 запитів на GitHub.

Двофарбні фільтри та покращення мультимедіа

Блоки зображень і обкладинок отримують нову функціональність Двофарба. Це фільтр, який дозволяє користувачам накладати два кольори на носій, створюючи унікальні ефекти. Кольори переписує світло та тіні на зображенні або відео. Користувачі можуть застосовувати настройки за замовчуванням у WordPress, включіть кольори, визначені темою, або створіть власні колірні суміші.

У WordPress 5.8 також було представлено декілька оновлень бібліотеки. Команда розробників видалила нескінченну прокрутку і впровадили кнопку “завантажити більше”, покращивши досвід для користувачів програми читання екрану. Тепер користувачі можуть копіювати URL-адресу медіафайлів зі сторінки “Додавання нового носія”.

Останній реліз пропонує підтримку формату WebP зображення вперше. Розробники тепер мають фільтр image_editor_output_format для детальних налаштувань формату виведення даних.

Блокувати віджети

Вперше з моменту з’явилася система блоків (ще в WordPress 5.0 майже три роки тому користувачі змогли застосувати блоки не тільки в редакторі постів. Тепер блоки можуть бути використані на будь-якій доступній бічній панелі. Це ще один крок до повного редагування сайту (Повне редагування сайту, або FSE коротко). Поки що користувачі можуть ознайомитися з новим процесом використання блоків.

Все залежить від існуючої теми. Деякі старі проекти можуть не працювати з цією системою. Можливо, авторам тем потрібно буде відмовитися від цієї можливості на даний момент. Щоб не зіткнутися з зламаними віджетами, користувачі можуть встановити плагін Класичні віджети.

Цикл запитів і блоки в темах

Можливість створювати списки, сітки та інші види дизайну вже давно в руках досвідчених розробників. Щоб внести деякі зміни, користувачам довелося покладатися на свої теми або на спеціалізовані плагіни. Це не той випадок сьогодні. Користувачі можуть створювати майже будь-який тип списку записів за допомогою блоку Цикл запитів.

І це тільки початок. Новий блок у WordPress 5.8 – це лише перший крок на шляху до повного редагування сайтів. Коли інші блоки розвиваються і з’являються, користувачі та автори теми створюватимуть все нові та нові макети. Повторення запиту є лише початковою точкою.

Через блок “Цикл запитів” користувачі зможуть вперше ознайомитися з шаблонами. Інструмент вставки шаблону дозволить користувачам вибирати шаблони блоків, налаштовувати їх і змінювати їх. У майбутньому така можливість стане ще більш помітною і цікавою.

Вставлення списків записів – це лише невелика частина пропонованих функцій. У WordPress 5.8 З’явиться нова тематична рубрика для блоків. В основному ці блоки призначені для використання в циклі запитів. Існують також блоки, такі як Назва сайту та Слоган сайту, які будуть корисні в редакторі шаблонів.

Редактор шаблонів

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

По суті, це зменшена версія майбутнього редактора веб-сайтів. У версії 5.8 ця функціональність ідеально підходить для створення цільових сторінок (цільових сторінок). Для звичайних користувачів це дуже потужний інструмент. І це дозволяє WordPress Наблизіться до своєї мети демократизації видавничої справи (і дизайну).

Мінус цей параметр? Його не ввімкнуто за замовчуванням. В активній темі слід прописати її підтримку. Багато хто просто не побачить його, поки розробники теми не розгорнуть останні оновлення.

Підтримка Theme.json

У WordPress 5.8 розробники тем можуть налаштовувати глобальні стилі та параметри через нову систему theme.json. Найближчі до найближчих вона стане основою для створення тем.

Новий файл є мостом між темами, WordPress і користувачі є стандартизованим методом взаємодії. Автори теми визначають параметри, які підтримує тема, а також її стандартні стилі. WordPress виводить все це через інтерфейси редагування і в інтерфейсі. Користувачі можуть переписати стилі для кожного окремого блоку або встановити власні глобальні стилі за допомогою функції “Глобальні стилі”.

Зараз цією функцією можуть скористатися розробники як традиційних, так і блок-тем. Найближчим часом багато розробників тем почнуть перенесення своїх рішень на theme.json.

джерело: wptavern.com

Wayfinder: додаток для ідентифікації та вибору блоків у WordPress

Крістофер Джон, дизайнер з Сіетла та інженер UX, опублікував свій перший проект у каталозі плагінів. Позитивно розглядається на Twitter, плагін Wayfinder є рішенням для підсвічування контуру блоків у WordPress- Ред.

Як і у випадку з подібними плагінами, метою Wayfinder є полегшення вибору користувачами вкладених блоків. Wayfinder показує контур кожного блоку в редакторі, коли ви наводите курсор миші. При цьому в лівому верхньому кутку поля (над контуром) відображається ім’я блоку.

Моя улюблена функція, яку ви не знайдете більше ніде, – це виведення класу кожного блоку в нижньому правому куті шляху. Це полегшує пошук класу для подальшої укладки.

Користувачі також можуть вмикати або вимикати елементи інтерфейсу користувача через сторінку налаштувань плагіна. Проте будь-які внесені зміни впливають на всіх користувачів сайту. В даний час немає індивідуальних налаштувань для кожного користувача.

На перший погляд плагін функціонував відмінно. Зовнішній вигляд шляху був цілком зрозумілий, і мені не потрібно було міняти настройки за замовчуванням. Wayfinder виглядав як кращий продукт для виводу контуру блоку. Він перевершує існуючі плагіни майже в усіх відношеннях.

Однак незабаром ситуація пішла вниз. Досить було почати писати типовий пост, що складається тільки з заголовків, блоків Paragraph і Image. Спочатку я помітив, що не можу навести звичайну кількість слів в одному рядку. Моя ідеально налаштована типографіка зламалася швидше, ніж я очікував. Інтервал між абзацами здавався завеликим. Мої широко вирівняні зображення виглядали трохи менше, ніж зазвичай.

До цього моменту досвід взаємодії здавався приємним. Але дивацтва нагромаджуються. Щось не так. Плагін отримав похвалу в Twitter і зібрав три 5-зіркових відгуки в перший же день. Можливо, проблема була в моїй нестандартній темі. Однак у мене були подібні проблеми при тестуванні на інші теми – Twenty Twenty-One, Nutmeg, Eksell. Всі ці теми добре продумані, заточені для редактора блоків.

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

Проблема полягає в тому, що плагін додає відступ 18px біля кожного блоку через свою список стилів.

.wp-block:not(.block-list-appender) {
    position: relative;
    outline: 1px dashed transparent;
    padding: 18px;
    overflow: visible !important;
}

Часто це непомітно. Це впливає на кожен сайт по-різному. Додаткові відступи 18px для кожного блоку, безсумнівно, можуть призвести до розбивки дизайну (якщо сама тема не використовує однаковий інтервал для відступів).

Більш помітні проблеми спостерігаються з іконками соціальних мереж (блок Social Icons):

Навіть блок, максимально простий, може мати помилкове вирівнювання:

Розробники тем можуть писати власні CSS, щоб запобігти перезапису відступів. Природно, це не найкращий підхід, але що можна зробити. Навряд чи в громаді WordPress Я хотів би бачити війну за стилізацію з боку тем і плагінів.

Видалення цього правила одноразового заповнення з файлу в стилі редактора.css плагін виправить 99% проблем. Зрештою, все буде працювати безперебійно.

Як розробник, я б краще бачити використання зсув контуру для відступу між блоком і його контуром (а 18px – це багато, я б його скоротив). Шляхи не є частиною моделі css box, і тому не впливають на відступи. Коригування може знадобитися для будь-яких окремих блоків, особливо якщо вони вкладені або мають невеликий розмір (наприклад, Соціальні іконки, Навігація). Це може призвести до інших труднощів, але цей курс принаймні менш руйнівний.

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

Інша проблема може бути пов’язана з псевдоелементами ::before і ::after для блоків. Додаток повинен буде переписати їх, щоб відобразити назву блоку і список класів. Це прикордонний випадок, який варто пам’ятати.

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

Повнороз ширина блоків редактора Gutenberg (ну, ім’я!) — це ще один нещодавній додаток, який надає подібну функціональність. Правда, він порушує дизайн теми по всій дошці.

Блок-структура редактора – Цей плагін був частиною моїх рекомендацій на деякий час. У нього є пара рРоблем з дизайном, але деякі з них досить вирішувані. Останнім часом плагін став занадто повільним для редактора. Крім того, зловживання системою повідомлень WP для просування в Twitter вбиває в бутоні всі позитивні аспекти цього рішення.

Набір редакторів має схожу функціональність “блоч-покажчики” – в ній використовується поле-тінь замість відступів і контуру. Такий підхід дозволяє зберегти розмітку теми. Тим не менш, я зіткнувся з іншими конфліктами стилю в плагіні. EditorsKit буде зайвим для користувачів, яким потрібна лише одна функція.

Залишається тільки Wayfinder. Тепер це найкращий автономний варіант.

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

джерело: wptavern.com

Pocket Casts: ще одне придбання Automattic

Automattic купує Pocket Casts, популярний додаток для прослуховування та пошуку подкастів на Android та iOS. Австралійські співзасновники Рассел Іванович і Філіп Сімпсон продовжать керувати Pocket Casts в рамках придбання.

Додаток дозволяє користувачам централізовано зберігати всі свої підписки на подкасти та синхронізувати їх на різних платформах. Додаток Pocket Casts, раніше призначений тільки для комерційних цілей, був безкоштовним з вересня 2019 року, коли розробники вирішили перейти на модель розповсюдження freemium. Монетизація Pocket Casts проводиться через план Plus, який надає користувачам доступ до настільних додатків, хмарного сховища, відтворення подкастів, а також тем і іконок всього за $ 9.99 / рік.

У травні 2018 року Pocket Casts була придбана громадськими медіа-організаціями NPR, WNYC Studios, WBEZ Chicago і This American Life. Невелика частка також належала BBC Studios до придбання Automattic.

Незважаючи на те, що NPR називають одним з кращих додатків для подкастів, фінансова звітність та аудит NPR за 2020 рік показали чистий збиток у розмірі $ 800K. Команда керівництва компанії зустрілася в грудні 2020 року і вирішила продати Pocket Casts.

Фінансові деталі угоди не розголошуються. Зрозуміло, що Automattic зможе укласти угоду тільки в тому випадку, якщо інші компанії з акціями в додатку також зазнали збитків. В результаті покупки Tumblr і Day One Automattic завоювала репутацію покупця додатків, які подобаються користувачам, в результаті чого ці додатки мають шанс на фінансову стабільність і майбутній розвиток. Automattic демонструє інтерес до технологій, пов’язаних з подкастингом , просто згадайте недавні інвестиції в Castos і партнерство з платформою Anchor Spotify.

Оголошення про покупку послуг / додатків зазвичай містять гарантії того, що для поточних клієнтів не буде змін. Однак анонс Automattic не містив таких обіцянок. І особливих подробиць щодо планів Pocket Casts не було. Можливо, найближчим часом буде інтеграція з WordPress.com (але все ще розробляється).

«У рамках Automattic Pocket Casts продовжить пропонувати вам функціонал, який вам потрібно прослухати улюблені подкасти (або знайти щось нове)», – сказав Елі Буделлі, керівник відділу додатків Automattic. “Ми розглянемо створення тісної інтеграції між WordPress.com pocket Casts, щоб полегшити розповсюдження та прослуховування подкастів. Ми раді продовжувати пропонувати нашим користувачам різні способи взаємодії з історіями “.

джерело: wptavern.com

Google завершив базове тестування FLoC на цьому тижні

На цьому тижні Google завершив дослідження FLoC (Федеративне навчання когорт). Дослідження проводилося в рамках ініціативи Поштова скринька конфіденційності, набір нових технологій, призначених для заміни сторонніх файлів cookie, відбитків пальців та інших часто використовуваних механізмів відстеження. Цей конкретний експеримент групує людей на основі їхніх звичок перегляду та позначає їх за допомогою машинного навчання.

Дослідницька програма FLoC була завершена 13 липня 2021 року. Експерти Google вирішили закрити фазу тестування проекту, проаналізувавши відгуки користувачів.

«Ми вирішили не поновлювати наше початкове тестування Origin Trial», – сказав старший розробник Google Джош Карлін у філії Blink Developers форуму Chromium. – Замість цього ми до працюємо над вдосконаленням FLoC, щоб задовольнити всі відгуки, отримані від спільноти, перш ніж перейти до подальшого тестування екосистеми».

Суперечливий експеримент зустрів опір з боку захисників конфіденційності, таких як розробники браузера Brave та учасники. EFF (Аф). Вони не бачать FLoC як переконливу альтернативу бізнес-моделі відстеження, яка в даний час використовується в рекламній індустрії. Amazon, GitHub, Firefox, Vivaldi, Drupal, Joomla, DuckDuckGo та інші великі технологічні компанії та проекти з відкритим вихідним кодом вже вирішили заблокувати FLoC за замовчуванням.

На даний момент тільки Twitter, здається, є єдиною великою платформою, яка працює з FLoC (в коді програми експерти знайшли посилання, пов’язані з цією ініціативою).

Початкові зусилля Google з просування FLoC не знайшли широкої підтримки. Можливо, це сприяло тому, що компанія призупинила свій план відмови від сторонніх файлів cookie в Chrome до 2022 року. Рекламна індустрія поступово піддається тиску з боку законів про конфіденційність даних. У найближчі роки нас чекає справжній “Апокаліпсис”. Google відклав крайній термін відмови від сторонніх файлів cookie – тепер цей процес повинен початися в середині 2023 року і закінчитися в кінці 2023 року.

«Ми повинні тримати темп руху адекватним, – сказав Вінай Гоель, директор з конфіденційності Chrome. «Буде достатньо часу для публічного обговорення правильних рішень, взаємодії з регуляторами, а також для реструктуризації видавців та рекламної індустрії в цілому. Це дуже важливо, тому що ми не можемо поставити під загрозу бізнес-моделі багатьох видавців, які підтримують вільно доступний контент».

Дискусії про блокування FLoC в WordPress за замовчуванням дещо застопорилися на форумах Trac. Прихильники блокування FLoC вважали, що підтримка або опозиція з боку WordPress буде вирішальним фактором успіху або провалу прийняття FLoC в Інтернеті.

Нещодавня стаття на VIP-.com WordPress отримала назву “До побачення, сторонні файли cookie, привіт FloC Google”. Це свідчить про те, що Automattic може схилятися на користь цієї ініціативи:

«FLoC має свої переваги. Але це не так орієнтовано на конфіденційність, як хотілося б, і може призвести до дискримінаційної практики, як показано вище. Крім того, є побоювання, що Google буде домінувати в іншому аспекті технологій. Google також планує стягувати плату з будь-якої сторонньої компанії з відстеження за використання зібраних даних”.

В даний час, схоже, що найбільші технологічні платформи не готові активно просувати ініціативу FLoC, оскільки вона була відправлена назад для значних поліпшень. В останній часовій шкалі до Privacy Sandbox Віней зазначив, що Google «отримав значний зворотний зв’язок від веб-спільноти під час базового тестування першої версії FLoC».

Здається, що FLoC знаходиться далеко від стадії реалізації, оскільки вона навіть не змогла закріпитися в галузі. Тривожно, Google може таранити спільноту в будь-якому випадку і насильно відкликати FLoC, враховуючи значні частки ринку Chrome, навіть незважаючи на холодний прийом від користувачів. І хоча запропоновані зміни в рекламних технологіях вплинуть на всю галузь, включаючи звичайних користувачів, Google не планує розкривати будь-які приватні відгуки, отримані від компаній під час базового тестування FLoC.

«Результати зібраного зворотного зв’язку будуть наступною версією FLoC», – сказав математик Google Майкл Клебер під час недавньої зустрічі Групи інтересів веб-комерції (WCIG).

Захисники конфіденційності хочуть, щоб процес був більш прозорим. Базові питання не слід ігнорувати. Ви не можете залишити все це на розсуд зацікавлених сторін в Інтернеті. Реструктуризація рекламної індустрії з використанням нових технологій ці зміни мають відбуватися відкрито, якщо ці зміни дійсно призначені для захисту конфіденційності користувачів.

джерело: wptavern.com

Зміни в бібліотеці WordPress 5.8, які чекають нас

Як ви вже знаєте, WordPress 5.8 буде мати просто божевільну кількість змін. Ми подивилися на деякі з них. Настав час вивчити зміни, пов’язані з обробкою мультимедійних файлів у майбутньому випуску.

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

WordPress 5.8 повинен вийти на 20 липня. Якщо ви ще не протестували зміни, ви можете зробити це, встановивши WordPress 5.8 Release Candidate 3.

Замість нескінченної прокрутки тепер кнопка Ajax

У майбутньому випуску зникне нескінченна прокрутка для медіа. Замість цього буде використовуватися кнопка “Завантажити більше” на Ajax. Бібліотека і накладення з медіа в редакторі будуть обмежені виведенням 40 медіа-елементів за замовчуванням.

Ця зміна з’явилася завдяки зусиллям команди доступності WordPress. Член цієї команди Андреа Ферсія відзначив дві серйозні проблеми, пов’язані з нескінченним прокручуванням. По-перше, користувачі клавіатури навряд чи зможуть охопити вміст після області прокручування. По-друге, немає інструкцій або сигналів для екранних чикаранів про те, як працює нескінченна прокрутка.

Він також відзначив деякі проблеми з зручністю використання та продуктивністю. Нескінченна прокрутка може порушити історію браузера, і для неї немає JavaScript-зворотного зв’ювання. Завантаження сотень і тисяч великих зображень значно роздуває обсяг пам’яті.

Медіатека буде оброблятися через Ajax в WordPress 5.8, тому ми можемо очікувати аналогічних оновлень для інших областей WP в майбутньому:

  • Сторінка “Додавання тем”
  • Настроювання > додавання елементів меню
  • Редактор > посилання > пошуку

Копіювання URL-адреси на сторінці додавання нових медіафайлів

Ця зміна усуває одну невелику, але досить помітну неприємність, яка страждала користувачів протягом багатьох років. Під час передавання зображення на сторінку “> медіа-даних” користувачі не змогли отримати його URL-адресу, не натиснувши кнопку “Редагувати”.

У WordPress 5.8 з’явиться кнопка “Копіювати URL-адресу в буфер обміну”, яка буде видимою після завантаження зображення. Немає необхідності залишати сторінку і намагатися отримати URL окремо.

Підтримка форматів зображень WebP

WordPress буде підтримувати новий формат зображення. Ні, це не SVG (технічно це не зображення). Є ще деякі проблеми безпеки, які необхідно подолати, щоб з’явилася вбудована підтримка SVG. WordPress тепер підтримує WebP, який обіцяє кращу продуктивність для тих, хто його використовує.

В даний час 1,8% з топ-10 мільйонів сайтів підтримують формат WebP. Оскільки WP перейшов на його підтримку, цей відсоток, швидше за все, збільшиться далі в найближчі роки.

Хук для формату виводу зображень у редакторі

Розробники, які хочуть перетворити зображення з одного типу MIME на інший, тепер можуть використовувати новий image_editor_output_format фільтр. Розробники плагінів можуть перетворювати всі нещодавно завантажені зображення або переписувати лише певні формати.

Наступний приклад перетворює JPG-зображення на новий формат WebP:

add_filter( 'image_editor_output_format', function( $formats ) {
        $formats['image/jpeg'] = 'image/webp';

        return $formats;
} );

Формат виводу буде застосовано до всіх зменшених розмірів зображення під час їх створення. Проте це працюватиме лише для зображень WebP, лише якщо веб-сервер підтримує цей формат.

джерело: wptavern.com

WooCommerce латає критичну вразливість

У WooCommerce Вирішені критична уразливість, виявлена 13 липня 2021 року дослідником з безпеки в рамках програми Automattic’s HackerOne. Вразливість впливає на версії 3.3-5.5 плагіна WooCommerce, а також на версії 2.5-5.5 функціонального плагіна WooCommerce Blocks.

«Дізнавшись про це питання, наша команда негайно провела ретельний аудит, перевірила всі пов’язані кодові бази і створила патч для кожної постраждалої версії (більше 90 релізів), яка була автоматично розгорнута в вразливих магазинах», – сказав Бо Лебенс, керівник з розвитку WooCommerce.

WordPress.org випускає примусові автоматичні оновлення для вразливих магазинів, практика, яка рідко використовується для виправлення потенційно небезпечних отворів, що охоплюють велику кількість сайтів. Навіть з доступними автоматичними оновленнями, продавцям WooCommerce все ще рекомендується перевірити, чи встановлено останню версію плагіна (5.5.1).

Оскільки розробники портували патч безпеки до версії 3.3, власники магазинів, які сидять на старих версіях WooCommerce, можуть сміливо оновлюватися до максимальної версії у своїй гілці (якщо ви з якоїсь причини не хочете встановлювати версію 5.5.1).

На момент публікації лише 7,2% установок WooCommerce використовували версію 5.5+. Більше половини магазинів (51,7%) працювати з версіями, старішими за 5.1. WordPress.org не надає детальної статистики щодо старих версій, але можна з упевненістю сказати, що без цих виправлень безпеки більшість установок WooCommerce залишаться вразливими.

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

«Наше розслідування цієї вразливості ще триває. Ми поділимося інструкціями з власниками магазинів про те, як перевірити цю вразливість на своїх веб-сайтах. Якщо магазин постраждав, то може витікати інформація, пов’язана з товаром, в тому числі і інформація про замовлення, клієнтів, адміністративну інформацію. “

Команда WooCommerce рекомендує продавцям змінити свої паролі після установки виправленої версії в якості запобіжного заходу.

Доброю новиною для власників магазинів WooCommerce є те, що саме ця критична вразливість була виправлена протягом одного дня після його відкриття. Команда плагінів прагне до прозорості в питаннях безпеки. На додаток до публікації оголошення в блозі плагіна, власники WooCommerce також надіслали електронного листа всім тим, хто підписується на розсилку новин. Власникам магазинів радять стежити за блог WooCommerce – незабаром він повинен містити інструкції про те, як перевірити, чи був магазин скомпрометований чи ні.

джерело: wptavern.com

Як увімкнути GraphQL в WordPress: WPGraphQL та GraphQL API для огляду WordPress

Безгольовий WordPress останнім часом стає все більш модним. Всього за кілька тижнів ми побачили багато нових розробок і рішень, пов’язаних з таким підходом. Однією з причин такої діяльності є випуск WPGraphQL 1.0, сервера GraphQL для WordPress.

WPGraphQL пропонує API GraphQL: спосіб витягти дані з WordPress та опублікувати їх на сайті. Цей метод дозволяє відокремити процеси управління контентом (що робиться через WordPress) від процесів побудови сайту (для цього ми можемо використовувати бібліотеки будь-якого фреймворку, який нас цікавить, включаючи React, Vue.js, Gatsby, Next.js).

До недавнього часу WPGraphQL (значення) був єдиним сервером GraphQL для WordPress. Але потім було більше і GraphQL API для WordPress.

Ці два плагіни служать одній меті: прив’язування API GraphQL до сайту WordPress. Ви можете запитати: чому інший плагін, якщо вже є WPGraphQL? Чи роблять ці два плагіни те ж саме? Або вони для різних ситуацій?

Просто зверніть увагу на наступне: WPGraphQL відмінно справляється з усіма завданнями. Новий плагін не був створений в результаті будь-яких проблем з WPGraphQL.

Плагіни мають різні архітектури, що дає їм різні характеристики і спрощує виконання певних завдань в залежності від використовуваного рішення.

У цій статті я покажу, в якій ситуації WPGraphQL буде найкращим варіантом, і в якій ситуації найкращим варіантом буде GraphQL API для WordPress.

Використання WPGraphQL під час роботи з Гетсбі

Якщо ви розробляєте веб-сайт за допомогою Гетсбі, то у вас є один варіант: WPGraphQL. Творець WPGraphQL Джейсон Болл до недавнього часу працював у самого Гетсбі. З цієї причини WPGraphQL прекрасно працює в поєднанні з додаток джерела для Гетсбі.

Гетсбі отримує всі дані з сайту WordPress, і з цього моменту вся логіка програми лягає на плечі Гетсбі, а не WP. Отже, доповнення до WPGraphQL (наприклад, @stream директиви або @defer) більше не мають значення.

WPGraphQL вже так добре, як Гетсбі потреби.

Використовуйте WPGraphQL, якщо ви працюєте з одним з нових фреймворк без голови

Як згадувалося раніше, останнім часом в просторі без голови WordPress спостерігається сплеск активності – з’ясовуються нові фреймворки, а також стартап-проекти на основі Next.js:

Якщо ви хочете спробувати будь-який з цих фреймворк, то вам знадобиться плагін WPGraphQL, так як всі вони засновані на ньому, і в передбачуваному майбутньому навряд чи щось зміниться (творці цих рішень не хочуть реалізовувати інтерфейс для заміни серверів GraphQL).

Ми використовуємо будь-який плагін, якщо працюємо з Frontity

Фронтальність є React-фреймворк для WordPress. Він дозволяє створювати React-додатки з бекендом на WordPress. Навіть створення записів блогу за допомогою редактора WordPress підтримується з коробки.

Фронтальність базується на REST за замовчуванням, але ви можете використовувати GraphQL для неї підключення вихідного компонента plug-in.

У цьому контексті Frontity функціонує дуже грамотно: додаток source — це інтерфейс для взаємодії з постачальником даних. Зараз єдиним доступним додатком джерела є плагін для WordPress REST API. Однак будь-який розробник може зробити вихідний плагін для WPGraphQL або GraphQL API для WordPress (це підхід, який повинні мати всі фреймворки Next.js в ідеалі).

Висновок: обидва плагіни підходять для роботи з Frontity, але вам потрібно буде підключити їх самостійно.

Використовуйте WPGraphQL, якщо ви створюєте статичний сайт

У перших двох розділах вихід був однаковим: використовуйте WPGraphQL. Однак моя реакція в цих розділах була іншою. Якщо у випадку з Гетсбі я нічого не пошкодував, у випадку з Next.js я відчував брак можливостей.

Чому це так?

Різниця полягає в тому, що Гетсбі є генератором статичних сайтів, а Next.js може генерувати як статичні, так і динамічні (живі) сайти.

Я вже згадував, що WPGraphQL вже досить добре для Гетсбі. Цю заяву можна продовжити: WPGraphQL вже досить хороший для будь-якого генератора статичних сайтів.

Навіть якщо Api GraphQL для WordPress пропонує додаткові функції, все це навряд чи якимось чином вплине на генератор статичних сайтів.

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

Використовуйте API GraphQL, якщо нам потрібно використовувати GraphQL на живому сайті (не статичний)

Ситуація, описана вище, змінюється, якщо ми хочемо, щоб GraphQL отримала дані з живого сайту – наприклад, при запуску мобільного додатку або при показі даних в режимі реального часу на сайті (для відображення аналітики і т.д.). Крім того, цей випадок використання буде актуальним при поєднанні статичного та живого підходу на одному сайті.

Скажімо, ми зробили простий статичний блог, використовуючи один з фреймворку Next.js і хочемо дозволити користувачам коментувати публікації в блозі. Як вирішити цю проблему?

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

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

У такій ситуації має сенс відображати сайт статично без коментарів, а потім витягувати коментарі з живого сайту і обробляти їх динамічно.

Next.js для цієї мети рекомендується використовувати еукати. Він краще здатний обробляти статичні та динамічні підходи, включаючи підтримку різних виходів для користувачів з різними правами.

Повернутися до обговорення GraphQL: Чому я рекомендую API GraphQL для WordPress при роботі з даними в режимі реального часу? Я роблю це тому, що сервер GraphQL може безпосередньо впливати на додаток – головним чином з точки зору швидкості та безпеки.

У разі чисто статичного підходу сайт WordPress можна залишити приватним (його можна зберігати навіть на ноутбуці розробника), а тому він безпечний. Користувач не буде чекати відповіді від сервера, а тому швидкість тут не грає вирішальної ролі.

Однак для живого сайту (динамічного) GraphQL API буде загальнодоступним, і тому безпека даних буде проблемою. Ми повинні переконатися, що зловмисники не отримують до них доступу. Крім того, користувач тут вже чекає відповіді, а тому швидкість стає вирішальним фактором.

У цьому відношенні GraphQL API для WordPress має ряд переваг перед WPGraphQL.

WPGraphQL пропонує деякі заходи безпеки, такі як відключення самоаналізу схеми за замовчуванням. Однак API GraphQL для WordPress йде ще далі, від’ємо одну кінцеву точку за замовчуванням (і вона також має інші заходи безпеки). Api GraphQL для WordPress спочатку пропонує постійні запити.

З точки зору швидкості, постійні запити дозволяють зробити API швидше, оскільки відповідь кешує через кешування HTTP на декількох рівнях, включаючи клієнт, CDN та сервер.

З цих причин API GraphQL для WordPress краще підходить для роботи з живими сайтами.

Використовуйте API GraphQL, якщо ми пропонуємо різні дані для окремих груп користувачів або додатків

WordPress – це універсальна система управління контентом. Залежно від контексту, нам може знадобитися API GraphQL для надання різних даних:

  • Ми пропонуємо певні дані платним користувачам, але не безкоштовно.
  • Ми пропонуємо певні дані в мобільний додаток, але не на сайт.

Щоб передати різні дані, нам потрібно надати різні версії схеми GraphQL.

WPGraphQL дозволяє змінювати схему (наприклад, ми можемо видалити зареєстроване поле). Однак процес непростий: зміни схеми повинні бути закодовані, і нелегко зрозуміти, що таке доступ до чого (наприклад, всі схеми повинні бути доступні через одну кінцеву точку / graphql).

На відміну від цього, API GraphQL для WordPress підтримує цю опцію: він пропонує користувальницькі кінцеві точки, які можуть передавати різні дані в різні контексти, наприклад:

  • /graphql/mobile-додаток та /graphql/веб-сайт,
  • /graphql/pro-користувачі та /graphql/regular-користувачі.

Кожна довільна кінцева точка налаштовується за допомогою ALS для забезпечення детальної градації користувачів в окремих полях, а також у публічному та приватному режимі API, щоб визначити, чи доступні метадані схеми для всіх або лише авторизованих користувачів.

Ці функції безпосередньо інтегровані з редактором WordPress (наприклад, Gutenberg). Створення різних діаграм виконується візуально, подібно до створення записів блогу. Тобто створити довільні гр.схеми aphQL можуть використовуватися будь-яким користувачем, а не тільки професійним розробником.

Api GraphQL для WordPress є хорошим варіантом для цього випадку використання.

Ми використовуємо API GraphQL, якщо взаємодіємо зі сторонніми сервісами

GraphQL – це не просто API для отримання та публікації даних. Так само важливо (хоча і часто нехтують), він також може обробляти і змінювати дані. Наприклад, в процесі перенесення їх на якийсь сторонній сервіс (відправка тексту в СТОРОННІЙ API для виправлення граматичних помилок, завантаження зображень в CDN).

Який найкращий спосіб зв’язати GraphQL зі сторонніми сервісами? На мій погляд, це найкраще досягається за допомогою директив, що застосовуються або при створенні або витягу даних (фільтри в WordPress працюють багато в чому таким же чином).

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

На відміну від цього, Api GraphQL для WordPress має надійну підтримку політики. Кожна директива в запиті виконується лише один раз в цілому (на відміну від одного разу на поле або на об’єкт). Ця можливість забезпечує ефективний зв’язок зі сторонніми API шляхом інтеграції API GraphQL з різними сервісами.

Наприклад, нижче наведено запит демонструє, як викликати API Google Translate через директиву @translate переклад заголовків та цитат різних записів з англійської на іспанську. Усі поля для всіх записів перекладаються разом за один виклик.

Api GraphQL для WordPress є хорошим варіантом для цього випадку використання.

Примітка: Двигун, на якому базується API GraphQL для WordPress – GraphQL від PoP – був спеціально розроблений для забезпечення розширених можливостей управління даними. Це одна з його відмінних характеристик. Як перший приклад того, що можна досягти з ним, ознайомтеся з керівництвом .Надсилання локалізованого інформаційного бюлетеня користувачем».

Використовуйте WPGraphQL, якщо вам потрібна підтримка спільноти

Джейсон Болл зробив велику роботу згуртування спільноти навколо WPGraphQL. Тому, якщо вам потрібно вирішити проблеми з GraphQL API, то ви зможете знайти людину, яка вам допоможе.

У випадку GraphQL API для WordPress, спільнота все ще створюється, і це, звичайно, дуже далеко від WPGraphQL.

Використовуйте API GraphQL, якщо вам подобаються інновації

Я називаю GraphQL API для WordPress “перспективним” сервером GraphQL. Причина в тому, що я часто переглядаю список міток специфікації GraphQL і реалізую деякі з них заздалегідь (особливо ті, які мені подобаються або які я можу підтримати з мінімумом витрат).

На сьогоднішній день GraphQL API для WordPress підтримує кілька інноваційних функцій (таких як запуск декількох запитів і іменування схем), і є плани додати додаткові опції.

Використовуйте WPGraphQL, якщо вам потрібна повна схема

WPGraphQL має повністю маркований модель даних WordPress, включаючи:

  • Записи та сторінки.
  • Довільні типи записів.
  • Категорії та теги.
  • Довільні таксономії
  • ЗМІ
  • Меню
  • Параметри
  • Користувачів
  • Коментарі
  • Компоненти plug-in
  • Темами
  • Віджети

GraphQL API для WordPress додає все більше точок моделі даних з кожним новим випуском. На сьогоднішній день до списку входять:

  • Записи та сторінки.
  • Довільні типи записів.
  • Категорії та теги.
  • Довільні таксономії
  • ЗМІ
  • Меню
  • Параметри
  • Користувачів
  • Коментарі

Якщо вам потрібно отримати дані з плагінів, тем або віджетів, то впоратися з цим зараз може тільки WPGraphQL.

Використовуйте WPGraphQL, якщо вам потрібні розширення

WPGraphQL пропонує розширення для багатьох плагінів, включаючи розширені користувацькі поля, WooCommerce, Yoast, Gravity Forms.

Api GraphQL для WordPress пропонує розширення для менеджера подій. У майбутньому будуть нові розширення.

Використовуйте будь-який з плагінів, якщо ви хочете створити блоки для редактора WordPress

Інтеграція GraphQL з Гутенбергом в даний час ведеться як WPGraphQL, так і GraphQL API для WordPress.

Джейсон Болл описав три підходи, за допомогою яких можна досягти такої інтеграції. Всі ці підходи мають свої проблеми. Джейсон виступає за введення реєстру на стороні сервера в WordPress, що дозволить вам визначити різні Гутенберг замки в схемі GraphQL.

Api GraphQL для WordPress використовує інтеграційний підхід Гутенберга, заснований на стратегії “створити один раз, опублікувати скрізь”. Спочатку з збереженого вмісту витягуються дані блоку, а потім для представлення всіх блоків використовується окремий тип Block. Такий підхід уникне введення серверної реєстру.

Рішення WPGraphQL можна назвати попереднім, оскільки воно сильно залежить від згоди спільноти на використання реєстру сервера. Ми не знаємо, чи буде така домовленість.

Для GraphQL API для WordPress вже розробляється рішення.

Ми використовуємо API GraphQL, якщо плануємо розподіляти блоки через плагіни

Те, що я знайшов, що не всі плагіни (якщо такі є) використовують GraphQL в WordPress.

Не захищай мене неправильно: інсталяції wpGraphQL перевищили 10 000. Тим не менш, я вважаю, що це в основному установки для роботи з Гетсбі (для запуску Гетсбі) або для роботи з Next.js (для запуску одного з безжйних рамок).

Аналогічним чином, WPGraphQL має багато розширень, як я вже говорив раніше. Однак ці розширення є просто розширеннями. Це не окремі плагіни.

Наприклад, WPGraphQL для WooCommerce залежить від плагінів wpGraphQL та WooCommerce. Якщо один з них не встановлений, то розширення не буде працювати, а це нормально. Але WooCommerce може працювати без WPGraphQL, тому плагін WooCommerce не матиме GraphQL.

Наскільки я розумію, немає плагінів, які використовують GraphQL для запуску своєї функціональності в WordPress або для підтримки своїх блоків Gutenberg.

Причина проста: ні WPGraphQL, ні GraphQL API для WordPress не є частиною ядра WP. Таким чином, неможливо покладатися на GraphQL так само, як плагіни можуть покладатися на WordPress REST API. В результаті плагіни, які пропонують блоки для Gutenberg, можуть використовувати REST тільки для отримання даних.

Здається, що рішення полягає в тому, щоб дочекатися, коли рішення GraphQL з’явиться в ядрі WP. Але хто знає, скільки часу це займе? Півроку? рік? Два роки? Довше?

Ми знаємо, що додавання WPGraphQL до ядра WordPress потенційно можливе, як натякнув Метт Малленвег. Але спочатку має бути кілька змін: підвищення мінімальної версії WP до 7.1 (потрібно як для WPGraphQL, так і для graphQL API для WordPress), поява чіткої дорожньої карти для функціональності GraphQL.

Повне редагування сайту, яке зараз знаходиться в розробці, базується на REST. У фазі 4 розробки Гутенберга повинні з’явитися багатомовні блоки. Можливо, саме тоді нам слід чекати, коли з’явиться GraphQL?

А тепер, окресливши проблему, перейдемо до готового рішення, яке не вимагає очікування.

Я створив наступну реалізацію: я взяв api GraphQL для коду WordPress за основу і дещо обріїв його, відкинувши всі зайві. Залишив тільки рушій GraphQL і більше нічого (ні інтерфейсу, ні довільних кінцевих точок, ні кешування HTTP, ні контролю доступу і т.д.). Ця версія може бути поширена як залежність від Composer, тобто вона може бути використана в плагінах для запуску блоків.

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

Мені вдалося вирішити проблему за допомогою API GraphQL для WordPress. В результаті я підготував версію плагіна, яка не буде конфліктувати з будь-яким іншим кодом на сайті.

Це означає, що компонент буде працювати для будь-якої з наступних комбінацій подій:

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

У будь-якій з описаних вище ситуацій плагін матиме власний автономний приватний рушій GraphQL, на базі якого будуть функціонувати блоки Gutenberg (і конфліктів не буде).

Цей компонент буде називатися Private GraphQL API. Робота над ним під час.

джерело: www.smashingmagazine.com

InstaWP: новий сервіс для створення одноразових тестових сайтів WordPress

Конкуренція в сфері пісочниці стала ще вищою – нещодавно з’явився новий сервіс InstaWP для створення одноразових тестових сайтів WordPress. Вікас Сінгхал, його засновник, розробив InstaWP для швидкого запуску тестових сайтів в Інтернеті, а також для демонстрації клієнтам або команді будь-яких необхідних веб-функцій.

InstaWP приєднався до рядів таких сервісів, як TasteWP і WPSandbox, але у нього є свої унікальні варіанти. При налаштуванні сайту користувачі можуть вибрати будь-яку версію WordPress до 4.7. Ви можете створити веб-сайт з кандидатом на випуск або бета-версією WP. Також сервіс InstaWP, як і інші аналоги, дозволяє вибрати PHP версію. Найближчим часом можна буде відключити wp кеш і кеш браузера. Користувачі можуть встановлювати довільні імена для своїх сайтів (включаючи порожні або випадково згенеровані).

Безкоштовні екземпляри WordPress триватимуть протягом 8 годин. Користувачі можуть пов’язувати свою електронну пошту, продовжуючи термін служби своїх екземплярів до 48 годин.

InstaWP (не плутати з InstantWP) був побудований поверх nginx + Apache без будь-яких контейнерів. Вікас зазначив, що вважає контейнери занадто важкими для цього конкретного випадку використання. Вікас запустив свій магазин плагінів / тем разом з агентством, і тестування сайтів WordPress допомогло йому в обох випадках.

“Я хотів створити рішення, яке допомогло б нам швидко запустити екземпляри WP – перевірити функціональність WP, протестувати плагіни / теми, вивчити сайти з різними версіями WP / PHP. Так само важливо, ми хотіли запропонувати це тестове середовище для наших клієнтів, щоб вони могли перевірити наші теми / плагіни самі “.

Віка запустила InstaWP місяць тому і отримала багато позитивних відгуків на Reddit і в спільноті Post Status. В результаті він вирішив найняти для свого проекту ще кількох розробників. Тестувальники були вражені тим, як швидко сервіс дозволяє запускати сайти. Версія 1.1.0 InstaWP представила слабку інтеграцію, яка дозволила користувачам миттєво запустити сайт, ввівши / wp в Slack. Реліз також ввів автоматичний логін під адміністратором без введення логіна і пароля.

InstaWP має публічну дорожню карту. Функції в майбутніх випусках включають в себе наступне:

  1. Команди slack і cli.
  2. Завантаження файлів і резервних копій баз даних з інтерфейсу.
  3. Пряма відправка на FTP або cPanel.
  4. конфігурації nginx і nginx + Apache.
  5. Детальний контроль над налаштуваннями PHP.
  6. Збережіть конфігурації, щоб миттєво запустити попередньо налаштований WP.
  7. Інтеграція з хостингом.
  8. Зв’язування довільних доменів (картографування).
  9. Кілька різних серверів у світі (США, Сінгапур, Лондон і т.д.).

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

«Я хочу зробити InstaWP інструментом за замовчуванням для початківців WP, ентузіастів, фрілансерів та агентств – і дійсно для всіх користувачів», – сказав Вікас.

Vikas планує монетизувати інструмент як для звичайних користувачів, так і для розробників тем та плагінів. Користувачам потрібно буде виконати оновлення, щоб отримати доступ до збільшених лімітів, довільних доменів, FTP та можливості резервування сайту. Розробники продуктів WordPress можуть оновити, щоб отримати доступ до швидких (1 клік) демонстраційних збірки сайтів для своїх користувачів та потенційних клієнтів.

До цих пір побудовано більше 500 екземплярів, і команди Yoast і деякі агентства вже використовують цей інструмент. Деякі добре відомі компанії, пов’язані з WordPress, вже пропонують екземпляри на основі InstaWP, щоб їхні користувачі могли тестувати плагіни за допомогою попередньо налаштованої збірки в 1 клік. Сервіс все ще знаходиться в активній розробці, і Віка планує скоригувати ціни в найближчому майбутньому. Тестувальники, які мають пропозиції щодо InstaWP, можуть залишити їх ідея ради для подальшого обговорення.

джерело: wptavern.com

WordPress 5.8

Вийшла свіжа версія движка WordPress 5.8 з новими приголомшливими можливостями! Завдяки цьому розробники і власники зможуть зробити свій сайт швидше, підвищити site rank, поліпшити візуальну складову, до того ж отримають більше можливостей для створення і адміністрування контенту.

Звучить надто добре, щоб бути правдою? Ось анонс можливостей нової версії:

  • У редактор WordPress 5.8 інтегровані “шаблони” – каталог готових макетів, які ви можете додати на будь-який сайт за допомогою ctrl + c / ctrl + v
  • У WP 5.8 нарешті додана підтримка зображень формату WebP, розмір яких на 30% менший, що прискорює завантаження сайту, покращує взаємодію з відвідувачами і може сприяти підвищенню рейтингу в пошукових системах.
  • Для любителів створювати складні сторінки з безлічі блоків в редактор додана функція “Перегляд Списком” – з її допомогою ви легко зможете управляти відразу декількома блоками на сторінці або в публікації.
  • Дні нудних сайдбарі полічені! Тепер в віджети доступні для використання блоки, а редагувати їх можна прямо в редакторі Блоків.

Детальні про всі новинки ми розповімо пізніше. Рекламное Агентство

BLOG:NET.UA працює на останній версії wordpress та регулярно оновлюється

Що таке Граватар(ки)

Це сервіс, який дозволяє користувачам засвідчити свою аватарку при коментуванні на любому з тисяч сайтів, які підтримують Gravatar, без реєстрації та входу.

Як це працює?

Користувач реєструється на сервісі Gravatar.com та завантажує аватарку.

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

При відображенні коментаря, блог запитує у gravatar.com аватарку користувача по його електронній адресі. Якщо аватарка існує, вона відображається. Якщо не існує – відображається стандартна картинка.