Сценарій Яндекс.Метрики (тег.js) негативно впливає на PageSpeed: що робити

Таким чином, ви вирішили поліпшити свій рейтинг PageSpeed. Але в процесі верифікації ви помітили, що скрипти Яндекс.Метріка серйозно погіршують ситуацію (що особливо помітно при перевірці сайту на мобільних пристроях). Давайте розглянемо приклад з нашим веб-сайтом oddstyle.ru.

Підтримка Яндекса визнала цю проблему (але поки що нічого не виходить за рамки тестування):

У нас є наступний код для підключення Яндекс.Метріка:

<script type="text/javascript" >
   (function(m,e,t,r,i,k,a){m[i]=m[i]||function(){(m[i].a=m[i].a||[]).push(arguments)};
   m[i].l=1*new Date();k=e.createElement

[0],k.async=1,k.src=r,a.parentNode.insertBefore(k,a)})
   (window, document, "script", "https://mc.yandex.ru/metrika/tag.js", "ym");

   ym(xxxxxxxx, "init", {
        clickmap:true,
        trackLinks:true,
        accurateTrackBounce:true
   });
</script>

При перевірці отримуємо наступні показники.

Природно, що ці показники так і є. Подивіться нижче і дивіться наступне:

Як ви можете бачити звідси, Metrica сильно блокує основний потік завантаження.

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

У багато разів краще.

Але що робити, якщо показник все ще потрібен, я хочу використовувати деякі його функції?

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

Ось як буде виглядати код сценарію (не забудьте замінити номер лічильника замість xxxxxxx):

<script data-cfasync="false" type="text/javascript">
  setTimeout(function(){
       (function(m,e,t,r,i,k,a){m[i]=m[i]||function(){(m[i].a=m[i].a||[]).push(arguments)};
   m[i].l=1*new Date();k=e.createElement

[0],k.async=1,k.src=r,a.parentNode.insertBefore(k,a)})
   (window, document, "script", "https://mc.yandex.ru/metrika/tag.js", "ym");

       ym(xxxxxxxx, "init", {
            clickmap:true,
            trackLinks:true,
            accurateTrackBounce:true 
       });
    }, 5000); //set this as high as you can without ruining your stats.
</script> 

Замість 5000 вам потрібно буде вибрати значення, яке дозволить вам підтримувати хороший рейтинг PageSpeed (ви можете встановити більше 5000).

Вставте цей код у верхній колонтитул.php і мати такі елементи:

Трохи гірше, ніж немає сценарію метрики на всіх, але все ще більше.

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

Для настільних комп’ютерів, у нас є наступне з цим кодом:

Якщо ви знаєте інші способи покращення PageSpeed для сценаріїв показників, поділіться ними в коментарях.

Увімкнення та вимкнення нових функцій у WordPress 5.8

Реліз WordPress 5.8 став одним з найбільш масштабних функціональних оновлень в історії двигуна. Кожен зміг знайти в ньому щось цікаве, і було багато функцій, які користувачі воліли б вимкнути.

Включення класичних віджетів, повернення нескінченної прокрутки в бібліотеку, включення редактора шаблонів – все це, безумовно, може бути реалізовано в системі, яка обслуговує більше 40% світових інтернет-сайтів. Є плагіни для всього цього. Про них ми поговоримо далі в статті.

Увімкнення редактора шаблонів

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

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

Компонент plug-in Редактор шаблонів від Webd Ltd дозволяє це зробити. Він не має жодних налаштувань. Досить встановити його і активувати.

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

Керування форматами WebP і зображень

У WordPress 5.8 запроваджено підтримку зображень WebP. Цей тип зображення може зменшити розмір файлу приблизно на 25-34%, залежно від вихідного формату. Проте формат завантажених зображень не змінюється автоматично на WebP. Плагін розробники просто новий гачок image_editor_output_format.

Компонент plug-in Сучасні зображення WP від Адама Сільверштейна базується на цьому гачку. Плагін дозволяє користувачам налаштовувати формат завантажених зображень для всіх розширень. Наприклад, користувачі можуть перетворювати свої зображення JPEG на WebP або залишати їх у базовому форматі.

Класичні віджети

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

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

Якщо вам не потрібно все, що пов’язано з блоками, ви можете використовувати плагін Вимкнути Гутенберг від Джеффа Старра. Це найнадійніше доступне рішення, що дозволяє власникам сайтів отримати бажаний досвід взаємодії.

Увімкніть нескінченну прокрутку для вашої бібліотеки

У WordPress 5.8 Замість нескінченної прокрутки в бібліотеці в Ajax була введена кнопка “Завантажити більше”. В результаті кожна “сторінка” тепер відображає 40 зображень та інших носіїв. Ця зміна була потрібна користувачам клавіатури та екранних редакторів. Нескінченне завантаження також хіт продуктивності для повільного підключення до Інтернету.

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

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

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

джерело: wptavern.com

3 Поради щодо вдосконалення показників PageSpeed та Core Web Vitals в WordPress

Вам потрібно терміново підняти свої цифри PageSpeed & Core Web Vitals? Нижче ми перерахували три швидкі поради, які допоможуть вам зробити саме це.

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

Оновлення Page Experience схоже на оновлення HTTPS. Коли був запущений новий алгоритм, він не здавався нам усім на той час, перестановками в рейтингу сайтів. Але скільки HTTP сайтів можна побачити в вершинах Google сьогодні? Природно, можна стверджувати, що це не наслідок будь-яких санкцій, а простий ефект переходу на HTTPS, адже такий перемикач легко зробити, і практично всі нові сайти запускають відразу на HTTPS.

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

Давайте розглянемо наступні прості поради про те, як отримати переваги ранжирування, покращуючи показники PageSpeed та Core Web Vitals в WordPress.

Порада 1. Хмарна область

Ця порада не є виключною для WordPress.

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

Ще до реалізації всіх порад, швидкість мого сайту була наступною:

Ми активували безкоштовний тариф CloudFlare і включили компоненти оптимізації швидкості:

Суттєва різниця! І це близько 20 хвилин роботи, включаючи створення облікового запису. Після оновлення до версії Pro (приблизно $ 20 на місяць) і налаштування практично всіх параметрів ми отримали наступне:

+ 11 пунктів за $ 20. Не погано.

Я підключив наступні настройки:

  • Польська оптимізація зображень.
  • Міраж.

А оскільки мій сайт був на WP, у мене був наступний варіант:

В результаті я встановив плагін, застосував рекомендовані настройки, а потім отримав наступне:

Тут щось веселе. Мій FCP і індекс швидкості покращився, але LCP затонув.

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

Все завжди потрібно протестувати.

Порада 2. колібрі

У цьому випадку я говорю не про вагінний алгоритм Google 2013, а плагін. WordPress з таким ім’ям. Я перевірив купу різних плагінів для швидкості та кешування. Деякі працювали краще, деякі гірше. Але стабільно високі результати показали плагін колібрі – звичайно, якщо ви працюєте з хорошим хостингом.

Колібрі – це не просто додаток кешування (адже у нас вже є кешування на стороні хостингу та кешування cloudFlare). В цьому випадку кешування колібрі нас зовсім не зацікавить. Що мені сподобалося, так це те, що Колібрі можна прикріпити до CloudFlare.

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

Для чистоти експерименту я відключив всі функції швидкості та кешування в CloudFlare. Таким чином, на момент написання цього розділу, моя початкова позиція швидкості становить 34.

Я перемістив всі свої CSS і JS код в нижній колонтитул і стиснутий його. Не всі зможуть це зробити, адже багато сайтів ламаються після цього. Деякі сайти повинні JQuery для завантаження раніше (без цього різні повзунки не будуть працювати і т.д.).

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

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

В результаті ми підняли рейтинг з 34 до 58:

Все гаразд. Я хотів довести це принаймні до 60. Це дозволяє убезпечити себе від незначних перерв і дає можливість завжди залишатися вище 50, що є порогом значення “поганих” результатів.

Порада 3. Очищення активів

Компонент plug-in Очищення активів – Ще один спосіб швидко виправити PageSpeed і основні веб-життєво важливі в WordPress.

Основна мета плагіна – дозволити власникам сайтів припинити завантаження сценаріїв для певних сторінок або груп з них. Дивіться пропозиції:

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

Давайте протестувати, як вони впливають на оцінку продуктивності. Після деактивації плагіна Колібрі, ми отримали оцінку 35.

Після установки і активації плагіна ви побачите наступні налаштування:

Тут тестовий режим, доступний у додатку, буде дуже корисним. Деякі скрипти, які ви можете перевірити (наприклад, скрипти-повзунки на всіх сторінках). Ви можете відключити всі скрипти і включити їх по одному, тестування функціональності. Це саме те, що я і зробив.

Після 20-30 хвилин роботи PageSpeed став 68.

Сфери занепокоєння залишилися наступними:

Стабільний прогрес. Тепер давайте об’єднаємо всі три поради.

Комбінація не працює. Оцінки та терміни багато прослизнули. Це було несподівано, оскільки CloudFlare і очищення активів, я подумав, повинні добре працювати разом.

На жаль, лише 59.

У нашому випадку ми вирішили зупинитися на одному CloudFlare.

Як ви вже помітили, в цій статті ми проаналізували показник для мобільних пристроїв. Для настільних комп’ютерів наша продуктивність за допомогою Cloud Flare стала 99:

Природно, у вашому випадку може спрацювати щось інше. Радимо дивитися далі на Jetpack Boost.

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

Процедура перевірки теми WordPress хочуть переглянути: запланована зустріч з розробниками

Команда тем WordPress.org (Команда тем) оголошено відкрити нараду під час масштабування з розробниками тем. Є плани обговорити нові правила перевірки та додавання тем. Коментарі щодо пропозиції відкриті до 26 липня, а сама зустріч запланована на 28 липня о 16:00 за московським часом.

Зустріч є наступним кроком на шляху до оновлення системи перевірки теми та полегшення додавання тем до ширшої спільноти розробників.

У січні система перевірки тем була на роздоріжжі. Теми Команди, відстеження додавання тем до офіційного каталогу WordPress.org, зробив значні успіхи за останні кілька років. Члени команди очистили чергу накопичених заявок, але поки що перед ними стоїть завдання поліпшити процес перевірки тем. Ряд додаткових поліпшень, здається, дали результати, хоча і не так швидко, як хотілося б.

Це було більш-менш, поки Метт Малленвег не висловив своє невдоволення постом Status Slack:

“Каталог тем .org відверто поганий, особливо якщо порівнювати з деякою тестериною маркетинговою сторінкою для комерційних тем або сторінок, доступних на інших сервісах створення веб-сайтів, в каталогах Themeforest. Правила каталогу .org і механізм оновлення тем поклали кінець творчим темам, їх замінили рішеннями, мотивованими додатковими продажами».

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

Чи пропустили користувачі WordPress кращі проекти у зв’язку з тим, що розробники найбільш інноваційних тем вирішили відмовитися від пісочниці .org? Якщо так, то які правила їх відчужили?

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

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

Пропозиції та запитання щодо правил додавання тем

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

Кароліна попросила авторів тем розглянути цю пропозицію і відповісти на наступні питання в коментарях перед зустріччю:

  • Чи полегшаться оновлені вимоги для надсилання тем до каталогу? Якщо ні, то що заважає вам надсилати теми?
  • Чи полегшаться оновлені вимоги для перевірки тем? Якщо ні, то що заважає вам аналізувати теми?
  • Які вимоги ви вважаєте зайвими в списку? Навіщо їх видаляти?
  • Які вимоги ви виявите незрозумілими? Опишіть проблеми.
  • Чи можна покращити форматування сторінки, щоб полегшити читання?

Поточна пропозиція є більш широкою, ніж Короткий список Виконавчий директор WordPress Жозефа Хаден Хомфосі.

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

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

Ще одним пунктом оригінальної пропозиції було відзначити теми “знаками якості”. Наприклад, інтернаціоналізація і доступність – це такі питання, відсутність яких в технічному плані не заважає темі нормально працювати. Замість того, щоб вирізати тему в бутоні і тримати її поза каталогом, можна просто позначити її «знаками якості», коли проект відповідає таким стандартам.

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

Звичайно, багато хто може не погодитися. Для деяких доступність і інтернаціоналізація є центром Всесвіту. Гаразд, є менш суперечливі правила. Наприклад, чому в темах ви можете рекомендувати тільки ті плагіни, які розміщені безпосередньо на WordPress.org? Чому це перешкода для включення теми в каталог? Для цього немає вагомих причин. Самі теми все ще не мають права ставити будь-які плагіни.

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

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

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

Якщо ви розробник теми WordPress, який має свої власні проекти в каталозі, ви можете бути присутніми на засіданні 28 липня, щоб висловити свою думку з усіх доступних питань.

джерело: wptavern.com

Ліворуч WooCommerce 5.5.2: Проблеми з продуктивністю, вирішені через примусове виправлення безпеки

Нещодавно випущений WooCommerce 5.5.2. Цей реліз є продовженням примусового оновлення безпеки, яке виправив уразливість SQL ін’єкцій минулого тижня. Уразливість вплинула на версії 3.3-5.5 плагіна WooCommerce, а також версії 2.5-5.5 плагіна WooCommerce Блоки. Команда випустила патч для більш ніж 90 релізів, і цей патч був розгорнутий як примусове оновлення безпеки через WordPress.org, оскільки вразливість мала потенційну загрозу для мільйонів установок WooCommerce.

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

Приклад такого запиту:

SELECT SQL_CALC_FOUND_ROWS  wp_posts.*, low_stock_amount_meta.meta_value AS low_stock_amount, MAX( product_lookup.date_created ) AS last_order_date FROM wp_posts  LEFT JOIN wp_wc_product_meta_lookup wc_product_meta_lookup ON wp_posts.ID = wc_product_meta_lookup.product_id  LEFT JOIN wp_postmeta AS low_stock_amount_meta ON wp_posts.ID = low_stock_amount_meta.post_id AND low_stock_amount_meta.meta_key = '_low_stock_amount'  LEFT JOIN wp_wc_order_product_lookup product_lookup ON wp_posts.ID = CASE

WHEN wp_posts.post_type="product" THEN product_lookup.product_id

WHEN wp_posts.post_type="product_variation" THEN product_lookup.variation_id

END WHERE 1=1  AND wp_posts.post_type IN ('product', 'product_variation') AND ((wp_posts.post_status="publish"))

AND wc_product_meta_lookup.stock_quantity IS NOT NULL

AND wc_product_meta_lookup.stock_status IN('instock','outofstock')

AND (

(

low_stock_amount_meta.meta_value &gt; ''

AND wc_product_meta_lookup.stock_quantity &lt;= CAST(low_stock_amount_meta.meta_value AS SIGNED)

)

OR (

(

low_stock_amount_meta.meta_value IS NULL OR low_stock_amount_meta.meta_value &lt;= ''

)

AND wc_product_meta_lookup.stock_quantity &lt;= 2

)

) GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC, wp_posts.ID DESC LIMIT 0, 1

Найчастіше страждали ті, у кого було багато продуктів в БД. «У нас величезна продуктова база в 17 000, – сказав один з користувачів. Це був кошмар для нас.

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

Тиждень тому розробник WooCommerce Адріан Даффелл сказав, що вони знайшли дві причини проблеми:

  1. Повільний запит SQL використовується для отримання продуктів, які є дефіцитні. Цей запит SQL присутній у WooCommerce у кількох випусках.
  2. API REST, пов’язаний із цим запитом SQL, викликано WooCommerce 5.5 в кілька разів частіше, ніж в попередніх версіях.

поєднання цих факторів призвело до низької продуктивності сервера під час WooCommerce 5.5. Fix був випущений в WooCommerce Адміністратор 2.4.4 і в WooCommerce 5.5.2. Користувачі, які використовують обхідні шляхи для вирішення проблеми, можуть відмовитися після оновлення до недавнього випуску.

джерело: wptavern.com

Випущено Gutenberg 11.1: додано підтримку перетягування для режиму перегляду списку, оновлено межі блоків

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

Автори теми зможуть налаштувати вивід блоку Стовпці на мобільних пристроях (чи перекладати стовпці в рядки чи ні). Також додано деякі оновлені засоби конструктора для навігаційних меню. Розробники тем мають перевірити останні зміни для блокування стилів RSS-каналщоб дизайн їх проектів не розійшовся.

Перетягування блоків у режимі перегляду списку

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

У версії 11.1 користувачі можуть перетягувати блоки зі списку для впорядкування та структурування вмісту. Однак користувачі не обмежуються лише переміщенням об’єктів у самому списку. Блоки зі списку можна перетягувати на полотно вмісту та назад.

Ця функціональність працює просто чудово.

Прикордонна підтримка

Gutenberg 11.1 покращив досвід сумісності для варіантів кордону. Команда розробників вдосконалила інтерфейс і розбила параметри на відповідні групи.

Поки що тільки наступні блоки мають прикордонну підтримку (часткову або повну):

  • Кнопку
  • група
  • образ
  • шукати
  • стіл

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

Блок стовпців: перекладіть стовпці в рядки на мобільних пристроях

Стек

За промовчанням окремі блоки стовпців на мобільних пристроях переміщуються до рядків один до одного для кращої зручності використання. Тепер користувачі можуть вимкнути таку поведінку в батьківському блоці стовпців окремо. Це також покращить управління розміткою в темах блоків.

Перемикач “Стек на мобільному” дозволяє впоратися з існуючими проблемами. Однак це тимчасове рішення, яке не дозволяє дизайнерам тем досягти належної гнучкості, реалізованої за допомогою CSS.

Перед блокуванням теми та редактор сайтів включено до ядра WordPress, розробникам тем знадобиться покращений адаптивний контроль над блоком Columns, щось на з’єднання блоків рядків / вбудованих / flex.

Розробники тем можуть перевірити, чи вимкнено мобільний переклад у рядки блоків стовпців, чи ні за допомогою класу .is-not-stacked-on-mobile.

Поштові терміни та хмара тегів

У минулих випусках Gutenberg блок Post Terms (варіація поштових тегів та категорій постів) відображав розділювач за замовчуванням (|) між окремими елементами. Тепер на ньому відображається кома, за яким слідує пробіл.

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

Блок Хмара тегів також був оновлений. Тепер користувачі можуть встановити обмеження на кількість відображуваних міток. Типовим значенням є 45 міток.

Кольори підменю навігації

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

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

Загалом, тепер у нас є кольори тексту і фону для підменю. Однак їх називають не зовсім коректно: “Накладання тексту” і “Накладання фону”. Я не впевнений, що вони будуть працювати в адаптивному меню для мобільних пристроїв.

джерело: wptavern.com

BuddyPress 9.0.0 випущений: старі віджети тепер можна перетворити на блоки

За день до релізу WordPress 5.8 побачив світ BuddyPress 9.0. Всі основні релізи BuddyPress були названі на честь піцерій – цей реліз не став винятком. Він отримав назву «Міко» на честь піцерії Chez Mico, невеликого ресторану на Французькій Рив’єрі, де можна замовити піцу з каперсами і анчоусами.

Реліз BuddyPress 9.0.0 був випущений в короткому циклі, щоб представити всі компонентні віджети BP як блоки. Це зробило можливим досягнення їх сумісності з новою функціональністю блок-віджетів в WordPress 5.8. BuddyPress 9.0 має 10 нових блоків BuddyPress, які будуть використовуватися замість старих віджетів.

У випуску 9.0 користувачі можуть перетворювати старі віджети в блоки двома кліками, зберігаючи при цьому всі налаштування цих віджетів. Наявність нових блоків є важливою віхою, яку Девід Кевінс, розробник BP, назвав “першим кроком до поетапного використання віджетів BuddyPress”.

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

«Мої колеги дуже схвильовані цими новими блоками BP, – сказав Девід під час чату на каналі BuddyPress на Slack. – «Наприклад, завдяки блоку форми Для входу ви можете відмовитися від непотрібних плагінів і легко розмістити форму на цільовій сторінці там, де вам це потрібно».

Реліз також включає в себе нову кінцеву точку Повідомлення сайту для BP REST API. Це дозволяє адміністраторам сайтів створювати, редагувати та видаляти сповіщення. Користувачі можуть використовувати його для отримання активного сповіщення. Повний список поліпшень і виправлень помилок в 9.0.0 ви можете знайти за посиланням.

джерело: wptavern.com

Каталог блок-моделей став доступний на WordPress.org

Учора каталог візерунків WordPress стала доступною для всієї світової спільноти. Команда розробників поставила на нього останні штрихи. З часом він буде функціонувати подібно до каталогів плагінів і тем. У WordPress 5.8 Користувачі можуть переглядати та використовувати шаблони блоків безпосередньо з редактора постів.

Офіційно каталог шаблонів є частиною випуску WordPress 5.8. Однак вчора ми не включили його в огляд, оскільки на момент виходу WP він був позначений «в розробці». Команда все ще вносити незначні зміни.

На даний момент в каталозі представлений куратор списку візерунків від більш ніж 20 добровольців. Команда попросила громаду взяти участь у розробці моделей ще в червні, і громада швидко відреагувала. Сьогодні більше 70 моделей доступні в різних категоріях:

  • Кнопки
  • Стовпці
  • галерея
  • заголовок
  • Зображення
  • Текст

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

Джастін Тадлок був рукою в розробці про мене карти і команди соціальних карт моделей. Його ідеї пізніше були реалізовані К’єллом Рейгстадом і Мелом Чойс-Духаном.

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

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

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

Шаблон каталогу має один недолік. Дуже складно знайти фотографії або ілюстрації, які б відповідали рекомендаціям по додаваню в каталог WordPress.org. Такі сервіси, як Unsplash, Pexels, Pixabay, мають обмеження на ліцензування зображень. Можливо, проблема буде трохи згладжена через потенційну інтеграцію з Openverse, колишньою пошуковою системою Creative Commons.

Я не можу чекати кращих дизайнерів робити. WordPress зможе вивантажити свої шаблони до каталогу. В результаті вона стане в кілька разів цікавіше і різноманітніше.

джерело: wptavern.com

Творці TinyMCE купують платформу Setka

Крихітні, творці TinyMCE, придбали Setka, платформу для створення та редагування контенту. Сума угоди не розголошується. До Tiny приєднаються засновники Setka – Катя Базилевська, Олексій Ам’ятов, Василь Есманов, Роман Худоногов, а також решта команди.

Tiny повідомили про підвищений попит на rich Text редагування компонентів від розробників. За останні 12 місяців було завантажено 8.1 мільйона TinyMCE (зростання на 77%) і 106 мільйонів завантажень компонентів редагування форматованого тексту в цілому з NPM (на 53% у річному обсягу).

«TinyMCE орієнтована на середніх бізнес-користувачів та інформаційних працівників; деякі з них знайомі з Microsoft Word або Google Docs”, – сказав засновник і генеральний директор Tiny Ендрю Робертс.

– Завдяки Setka тепер ми можемо позиціонувати себе на професійних творців контенту та дизайнерів, яким потрібні більш розширені можливості».

TinyMCE використовується мільйонами користувачів WordPress – В основному в класичному редакторі та додатках розширених інструментів редактора (раніше називався TinyMCE Advanced). Додаток Advanced Editor Tools додає блок Класичний абзац до редактора блоків, щоб користувачі могли увімкнути редактор TinyMCE з нетиповими рядками та кнопками. Це перехідне посилання для тих, хто ще не готовий повністю перейти до редактора блоків.

Крихітний є визнаним лідером в області редагування rich Text, він не потребує багато введення. Платформа Setka дозволяє створювати більш інтерактивний контент з можливістю організації тексту, зображень та інших візуальних елементів. За допомогою Setka можна створювати та зберігати шаблони записів, під час процесу розробки WYSIWYG легко використовувати елементи дизайну на всьому сайті. Крихітні плани об’єднати TinyMCE і Setka і створити спільну платформу, яка буде пропонувати набагато більше, ніж кожен продукт окремо.

«Сьогоднішні розробники контенту більш амбітні, і Setka дозволяє нам задовольняти їхні зростаючі потреби, – сказав Андрій.

– З часом ми плануємо створити комбіновану платформу редагування, яка є простою та потужною у використанні».

В даний час Setka пропонує інтеграцію для декількох CMS, інструментів управління документами та CRM, включаючи WordPress, Drupal, Magento, Ghost, Microsoft Sharepoint і Hubspot. Компонент plug-in Сетка для WordPress інтегрується з редактором блоків і пропонує власний блок вмісту, який взаємодіє з іншими блоками на сторінці.

Колишній генеральний директор Катя Басилевська, яка тепер буде виконувати обов’язки директора з партнерства та розвитку бізнесу в Tiny, зазначила, що команда має намір зосередитися на просторі CMS.

«Завдяки різноманітним інтеграціям ми сподіваємося зробити цю технологію візуального дизайну більш доступною для компаній, які вже мають CMS, але хочуть вичавити більше зі своїх інструментів редагування», – сказала Катя.

джерело: wptavern.com

Роль модерації коментарів: плагін від WPBeginner до помірних коментарів у WordPress

Минулого тижня команда WPBeginner випустила плагін Роль модерації приміток. Він робить одну просту річ: його можна використовувати для створення окремої ролі користувача для модерування коментарів.

Найбільш поширеним сценарієм використання такої ролі – під назвою WPB Comment Модератор в адмін-кімнаті – є виконання модерації у великих командах. У WordPress для цього немає вбудованої можливості. На жаль, це саме та область, де CMS. WordPress Не вдається.

Навіть 10 років тому (і мені здається, що це було вчора), я натрапив на помилку, яка зламала мій проект. Для нього навіть був створений окремий. квиток. Мені потрібно було надати деяким користувачам WordPress- Мені дозволено модерувати коментарі, але я не хочу, щоб вони могли редагувати інші речі в адміністратора.

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

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

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

WPBeginner’s коментар модерації роль плагіна працює нормально.

Адміністратори сайту можуть додати роль модератора коментарів WPB до будь-якого облікового запису на сторінці керування користувачем. Процес подібний до додавання або видалення будь-якої іншої ролі в WordPress.

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

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

Поки ця проблема не буде вирішена в ядрі, нам доведеться використовувати цей плагін. Якщо мені це буде потрібно для мого наступного проекту, я буду радий встановити його.

джерело: wptavern.com