Подготовката на нашия блог за Gutenberg и WordPress 5+ (case study)

В предишни статии описахме нуждата от подготовка на сайта за Gutenberg чрез тестване на съществуващото съдържание, още преди да е пусната версия 5.0 на WordPress. Вече е налична следващата версия WordPress 5.1.

Тъй като много наши клиенти се обърнаха към нас за помощна информация за преминаването към Gutenberg, решихме да опишем стъпка по стъпка процеса, който извършихме в нашия блог. Да, ние сме запалени WordPress фенове – използваме го както за нашия блог, така и за Помощната ни страница. 🙂

Нашият блог се използва единствено за блог публикации и няма допълнителни сложни функционалности и разновидности на самото съдържание. Това прави подготовката за блок редактора една идея по-лесна, отколкото например при сайт с нестандартни функционалности и много различни типове съдържание с различна презентация.

За по-сложни WordPress сайтове, подготовката за Gutenberg може да изисква проверка на всички допълнителни функционалности в класическия редактор, добавени от темата и/или плъгините. Прибавените в WordPress функционалности към класическия редактор е по-вероятно да са засегнати от новия блок редактор.

Подготовката на нашия блог – стъпка по стъпка

В началото подготовката на сайта за преминаване към Gutenberg и WordPress 5+ ни се стори сложен и труден процес. Оказа се, че не е толкова страшно, ако се изпълни стъпка по стъпка:

  1. Подготовка за тестване на Gutenberg
    • Създаване на работно копие на блога.
    • Подготовка на работното копие.
      • Обновяване на системата и плъгините до последни версии.
      • Активиране на нова PHP версия.
      • Подсигуряване на child тема.
      • Инсталиране на допълнителни плъгини.
  2. Проверка на вече създадено съдържание и стиловете
    • Проверка на плъгините и темата.
    • Проверка на съществуваща статия.
    • Проверка на мета информацията към статията.
  3. Извършване на корекции в блога
    • Създаване на използвано досега потребителско поле.
    • Добавяне на стила на темата в Gutenberg.
    • Обновяване на някои потребителски стилове.
    • Обновяване на наръчника за използване на потребителски стилове.

Параметри на системата по време на тестването на Gutenberg

Тестовете на блок редактора в нашия блог започнахме още от версия 4.9.8 на WordPress, когато Gutenberg беше още плъгин. Резултатите от първите тестове показаха, че блок редакторът все още не е напълно готов за пускане в нашия блог. Последните тестове с WordPress версия 5.1 обаче преминаха успешно и всички забелязани до момента проблеми с блок редактора вече не се забелязват.

Ето окончателно параметрите на системата по време на последните тестове:

  • WordPress 5.1 + Gutenberg (блок редакторът, вграден в системата)
  • Активиран плъгин Classic Editor v.1.4
  • Активиран плъгин Advanced Custom Fields v.5.7.12
  • Активирана нова PHP версия 7.2
  • Не се използват плъгини или теми тип page-builder, както и такива предоставящи допълнителни функционалности в класическия редактор например кратки кодове (shortcodes).
  • Използват се потребителски стилове (CSS), под формата на стилови класове (Help: Какво е CSS клас(стилов клас)?).

1. Подготовка за тестване на Gutenberg

Създаване на работно копие на блога

За да не се засегне работата на блога и достъпа на читателите ни до статиите, подготовката извършихме на тестово копие на сайта.

Съвсем първата стъпка от тестването, е създаването на работно копие на сайта. Върху копието може на воля да се извършат всички тестове и проверки, без това да засегне по някакъв начин реалния блог.

За създаването на тестово копие на блога ни беше необходим единствено подходящ поддомейн. А самото създаване на работното копие направихме с два клика на мишката през cPanel » Staging.

Подготовка на работното копие

Тестовото копие е напълно идентично с реалния блог, с една малка разлика – домейнът е различен.

По принцип разликата в домейна не би трябвало да попречи на работата на копието, освен ако не се използва изрично за функционирането на някой плъгин. В нашия случай, единствено плъгинът WPML използва домейна на сайта, но само за предоставяне на обновления. Поради това направихме допълнителна регистрация за различния домейн във WPML, за да можем да обновяваме плъгина в копието.

Също така, премахнахме някои ненужни за копието данни от базата данни, за да не се получи неудобна ситуация. Например не бихме искали да се изпрати имейл нотификация до абонатите ни, в случай че публикуваме статия по време на тестовете. Поради това данните за реалните абонати е премахната от базата данни на копието.

1️⃣ Обновяване на системата и плъгините до последни версии

На тестовото копие на блога инсталирахме последната към момента версия на WordPress 5.1. Обновихме всички плъгини в сайта до последни версии. И премахнахме всички данни от базата данни, които не са нужни на тестовото копие.

2️⃣ Активиране на нова PHP версия

Подготовката за Gutenberg е удобен момент да тестваме и нова PHP версия за сайта. За тестовия сайт активирахме нова версия на PHP 7.2.

3️⃣ Подсигуряване на child тема

Към темата на блога създадохме child тема, по която след това извършихме промени по кода.

4️⃣ Инсталиране на допълнителни плъгини

В тестовия блог инсталирахме няколко допълнителни плъгини:

  • Плъгинът Classic Editor, за да тестваме превключването между класическия редактор и блок редактора.
  • Плъгинът Health Check & Troubleshooting. Този плъгин извършва проверка на техническите показатели на сайта и предоставя информация за системата, плъгините и темата. В случай че има някакъв проблем с темата или някой плъгин, диагностичната информация от този плъгин може да се използва за отстраняването му.

2. Проверка на вече създадено съдържание и стиловете

След като тестовото копие е подготвено, можем на спокойствие да се впуснем в тестване и проверки.

Всъщност, тази статия се оказа един вид тест за блок редактора, защото има 120 блока и над 80 параграфа 🤓.

Проверка на плъгините и темата

По подразбиране всеки плъгин и тема, които не добавят функционалност в класическия редактор, не са засегнати от Gutenberg и трябва да функционират както досега.

В нашия блог няма плъгини или теми, които да добавят функционалности в класическия редактор. И поради това работата и дизайна на сайта не са повлияни по никакъв начин от блок редактора.

Тъй като за тестовия сайт е активирана и нова PHP версия, направихме по-щателна и подробна проверка на плъгините.

Това включва проверка на настройките им, функционалностите им, и работата на сайта и front-end частта му. Извършхме подробна проверка и на тези плъгини, чиято функционалност не се вижда на сайта – изпращане на имейли, пренасочвания, проверките за счупени връзки и други.

След като проверихме всички плъгини и темата, за радост, не забелязахме никакви проблеми с функционирането им и работата на блога. Имейлите се изпращат, пренасочванията се случват. С новата PHP версия 7.2 всичко в блога функционира коректно.

Проверка на съществуваща статия и стила ѝ

Истинското тестване на новия блок редактор реално се извършва с проверка на вече създаденото в сайта съдържание.

Конвертирането или прехвърлянето на съществуваща статия към новия блок редактор извършихме с:

  • Отваряне на съществуваща статия в блок редактора.
  • Конвертиране на съдържанието в блокове.
  • Запис на статията и преглед в публичната част на сайта.
  • Проверка на всеки един блок от статията в блок редактора и документиране на всяка разлика в стила.

Вече съществуващата статия, редактирана и записана в блок редактора, се показва както досега в публичната част на блога.

При редакция на статията в блок редактора видяхме, че стилът на статията е различен от този, който се вижда в публичната част. Това се дължи на факта, че използваната тема не е подготвена за Gutenberg.

За да може при редактиране на статия да се получи каквото-виждаш-това-получаваш, ще е нужно да добавим стила на темата в блок редактора: ⚒ Нужна корекция в блога: Добавяне на стила на темата в блок редактора

Някои от потребителските стилове в блога се използват в комбинация от стилов клас и допълнителен код към определен HTML таг. Тъй като в бъдеще няма да се работи с код в блок редактора, извършихме и корекция на някои от потребителските стилове в темата: ⚒ Нужна корекция в блога: Обновяване на потребителските стилове

При конвертирането на вече съществуващото съдържание в блокове, ако за даден HTML таг като p, a, li и други има вече зададен стилов клас, Gutenberg го прехвърля в настройката Допълнителен CSS клас за дадения блок. Поради това не се наложи да прехвърляме стиловете ръчно – с копиране и поставяне в тази опция. За новите статии, авторите ще поставят стила в тази опция Допълнителен CSS клас, като използват само името му, вместо както досега цял пасаж от код.

Например, ако досега е използван код: <p class=“stylename“>дума</p>, сега само ще се постави името на класа „stylename” в Допълнителен CSS клас. Това наложи да опишем стиловете така, че да се виждат само имената на класовете им: ⚒ Нужна корекция в блога: Обновяване на наръчника за използване на потребителски стил в статиите

Проверка на мета информацията към статията

При проверка на допълнителните данни за статията, намиращи се в мета кутии под самото съдържание, на ранен етап от тестовете установихме, че единствено липсват потребителските полета (custom fields). Това открихме впоследствие, че се дължи на активирания плъгин Модерни потребителски полета (ACF).

На чисто нова WordPress инсталация потребителските полета се показват в блок редактора, като се активира опцията в Настройки » Разширени панели » Потребителски полета.

Нужно е да пресъздадем едно потребителско поле, което е използвано до момента в класическия редактор при създаване на статия. Тъй като плъгинът ACF вече се използва в блога, чрез него ще добавим липсващото потребителско поле в блок редактора: ⚒ Нужна корекция в блога: Създаване на потребителско поле

Всички други допълнителни данни в статията се показват като настройките на All in One SEO, многоезичния плъгин WPML и други.

3. Извършване на корекции в блога

От извършените тестове и проверки се очертаха четири корекции в блога:

⚒ Създаване на потребителско поле

В блога се използва едно потребителско поле (custom field), в което се записва информация за картинката, която се използва при споделяне на статията във Facebook.

Съдържанието от това поле се извлича от темата и се добавя към HTML кода на страницата. Темата знае името на полето “fbImage” и ще го потърси в базата данни при генериране на окончателния HTML код на статията.

Досега това поле се използваше в класическия редактор, в кутията Потребителски полета под съдържанието на статията.

Кутията на потребителските полета в класическия редактор
Кутията на потребителските полета в класическия редактор

Докато тествахме блок редактора, въпреки включената опция в настройките му, кутията на Потребителските полета липсваше. Ако плъгинът ACF е активиран, кутията на Потребителските полета в блок редактора, не се показва.

Тъй като този плъгин се използва в блога, няма вариант да го деактивираме. Вместо това, ще го използваме, за да пресъздадем липсващото потребителско поле.

При създаването на полето в ACF посочихме името (Field Name) на оригиналното поле, което се съхранява в базата данни (wp_postmeta – meta_key). По този начин досега записаните данни ще се показват в блок редактора, а нововъведените ще са с коректния мета ключ в базата данни.

поле, което се съхранява в базата данни

След като създадохме полето, то вече се показва в блок редактора, в кутия под съдържанието на статията.

Пресъздаденото в ACF потребителско поле в блок редактор
Пресъздаденото в ACF потребителско поле в блок редактор

към началото на раздела 🔼

⚒ Добавяне на стила на темата в блок редактора

За да може статията да изглежда по същия начин, докато се редактира в блок редактора, както в публичната част на сайта, ще е нужно стилът на темата да се приложи (добави) към блок редактора. А за да може да се добави стила, ще е нужно да извършим малка корекция в кода на темата.

Всякакви корекции и модификации на кода на темата е препоръчително да се извършват от разработчиците ѝ. Ако се налага някаква промяна, задължително трябва да се изпрати запитване към поддръжката на темата. В краен случай, промяна по кода на темата трябва да се извършва единствено в нейна child тема. Такава тема може да се създаде и с плъгин като Child Theme Generator.

Възможността да се променя стила на редактора е специална функционалност, която се използва чрез темата на сайта. Налична е за класическия редактор още от WordPress версия 3.0. За да се използва стил за редактора, към функциите на темата (functions.php) се посочва кой ще е стиловият файл за редактора например:

add_editor_style( 'style-editor.css' )

Например за темата на нашия блог активирахме стила и стиловия файл за блок редактора, като добавихме следния код към функциите ѝ във functions.php:

function mytheme_setup() {
add_theme_support( 'editor-styles' );
add_editor_style( 'style-editor.css' );
}
add_action( 'after_setup_theme', 'mytheme_setup' );

С опцията add_theme_support се активира функционалността за промяна на стила на блок редактора, а с add_editor_style се указва файлът, който ще се използва за самия стил.

Ако досега не е съществувал стилов файл за редактора, той трябва да се създаде. И следващата стъпка е, да се поставят (част от) стиловете на темата в него (style-editor.css).

Не беше нужно да копираме цялото съдържание на стиловия файл на темата в стиловия файл на блок редактора. При тестове на съдържанието в блок редактора се “вижда” кой стил е нужно да се добави.

Стилът в редактора може да се задава и променя по същия начин както за темата, за потребителската част на сайта, със съвсем малки разлики. Например заглавието на статията в блок редактора също може да се стилизира.

За да се промени шрифта и размера на заглавието на статията в редактора, във файла style-editor.css използвахме стиловия клас: “.editor-post-title__block .editor-post-title__input”, вместо “.single .post-content h1”, който се използва от темата.

Промените и настройките на стила в блок редактора извършихме с помощта на официалната помощна документация за Gutenberg: Theme Support.

Блоковият редактор зарежда свои стилове по подразбиране за основните блокове. За някои от тях може да не се наложи промяна, но за други ще трябва да се извърши фина настройка, за да съвпаднат с тези на темата. Например шрифт, размер и цвят за заглавията (h1,h2,h3…), максималната ширина за блоковете, цитати, хоризонтална линия, параграфи (p), списъци (li), изображения (img), бутони, препратки и всички други, за които темата задава специфичен стил.

Активирането на стила на редактора не прави темата Gutenberg съвместима, но единствено позволява стилът в блок редактора да се доближи до този на front-end частта на сайта. Напълно съвместимите теми с блок редактора използват допълнителни възможности при създаване на съдържанието – допълнителни типове блокове, собствени настройки на блоковете, визуални елементи и оформление.

Без фина настройка на стиловете в блок редактора, единственото което ще се получи е „каквото-виждаш-може-би-това-получаваш“ като краен резултат в сайта.

Блок редакторът има собствен стил за основните блокове

Блок редакторът има собствен стил за основните блокове, например има зададени отстояния за параграфите. Това поражда видима разлика между back-end и front-end вида на статията. С още малко фини корекции по стила в блок редактора, статията може да се уеднакви на 100%.

към началото на раздела 🔼

⚒ Обновяване на потребителските стилове

В нашия блог има допълнителни потребителски стилове, използващи се чрез стилови класове. Досега в класическия редактор тези стилове се добавяха към съдържанието чрез поставянето на кода им – в режим Текстов редактор.

За да продължим да ги използваме, вместо в кода, стилът ще се поставя в настройките на блока в Допълнителен CSS клас. Това всъщност наистина е много по-лесен начин за задаване на стил от досега използвания – с бърникане в кода на статията.

Някои потребителски стилове се използват заедно с допълнителен стил към HTML таговете, което ги прави неприложими в блок редактора. Поради това се наложи да обновим и допълним тези стилове по подходящ начин.

Например стилът за кутийката tipsupport съдържа и наклонен текст в различен шрифт.

Потребителски стил за кутийка
Потребителски стил за кутийка

Тази кутийка се добавя в класическия редактор с поставяне на кода:

<div class="tipsupport">
<em style="color:#666666;font-family:'Trebuchet MS',Verdana,sans-serif;font-size:16px;"><strong>Съвет от support-а:</strong></em>
В случай че...
</div>

Което изглежда така в Текстов редактор:

В класическия редактор потребителският стил се добавя чрез добавяне на код в режим Текстов редактор
В класическия редактор потребителският стил се добавя чрез добавяне на код в режим Текстов редактор

За да се избегне ръчното добавяне на код в тага <em>, към стила добавихме:

.tipsupport em {
color:#666666;
font-family:'Trebuchet MS',Verdana,sans-serif;
font-size:16px;
}

По този начин няма да се налага поставянето на CSS код към HTML тага em, в режим на редакция на код в блок редактора.

Авторите единствено ще използват името на стиловия клас
Авторите единствено ще използват името на стиловия клас

Когато се правят промени по потребителските стилове в темата, то същите трябва да се нанасят и в стиловия файл на блок редактора.

към началото на раздела 🔼

Обновяване на наръчника за използване на потребителски стилове

За да е по-лесно избирането на потребителски стил за вмъкване в статията, докато се редактира, може да се създаде чернова статия, която да съдържа представяне на всички потребителски стилове.

Така ще е по-лесно авторите да си избират подходящ стил, след като видят как точно ще изглежда в статията. И ние си направихме такава статия 🙂

Чернова статия в класическия редактор, съдържаща представяне на потребителските стилове
Чернова статия в класическия редактор, съдържаща представяне на потребителските стилове

За потребителските стилове за блок редактора също създадохме чернова статия, в която се вижда как изглеждат и само имената на стиловите им класове.

Чернова статия в блок редактора, съдържаща представяне на потребителските стилове
Чернова статия в блок редактора, съдържаща представяне на потребителските стилове

Както за потребителските стилове, така и за стиловете на темата може да се създаде специална чернова статия, ако вече няма такава. В нея може да се добавят всички налични видове блокове и по тях да се настроят нужните стиловете от темата. Например заглавия h1, h2, h3 и т.н., списъци, цитати, бутони и всички останали елементи от дизайна, които са стилизирани за публичната част на сайта от темата.

към началото на раздела 🔼

Повишена сигурност и ускорено зареждане

След като подготовката за Gutenberg приключи успешно и новият блок редактор вече е в нашия блог, за в бъдеще ще можем да обновяваме WordPress системата към нови версии. Това ще ни позволи да използваме и нови PHP версии и блогът ни ще е по-сигурен и бърз.

С преминаването към блок редактора направихме стратегическа стъпка за повишена сигурност и ускорено зареждане на блога ни.

И още нещо важно – с блок редактора в нашия блог вече можем да се възползваме и от опростен процес за създаване на съдържание, който не разсейва креативната ни енергия и не нарушава фокуса на творческия процес. Единствено благодарение на лесното оформление на желаната презентация, без нужда авторите да се спират и да осмислят къде и как да използват HTML/CSS код.

А етап 2 от развитието на Gutenberg е стартиран и вече в разработка. Към момента повечето джаджи в WordPress вече са мигрирани в блокове. Вероятно следваща стъпка ще е мигриране на навигационните менюта в блокове. Изобщо не си мислим, че подготовката за Gutenberg се свършва с добавянето на стиловете на темата. Ще следим с голям интерес всяка завършена стъпка от етап 2 на блок редактора.

Ако искате и Вие да следите интересните новости, свързани с WordPress и блок редактора, абонирайте се за имейл нотификация при нова статия в нашия вече обновен блог 🙂

Мадлена Методиева
Мадлена Методиева
Меган е част от СуперМаркетинг екипа. Мисията ѝ е старателно да попълва е-библиотеката на СуперХостинг.БГ с полезни и помощни статии.
0 0 votes
.
Абониране
Уведоми ме при
guest

1 Коментар
Inline Feedbacks
View all comments
Зает домейн? Няма страшно!

Зает домейн? 9 тактики за успешна регистрация на име

0
Търсите име и то е заето. Какво правите след това? Отказвате се? Продължавате да търсите? Удряте пауза, за да помислите още?
Пренеси бизнеса си онлайн за няколко часа със собствен сайт

Пренеси бизнеса си онлайн за няколко часа със собствен сайт

0
Дойде моментът на практическите съвети как да пренесете бизнеса си от офлайн към онлайн със собствен сайт. Вижте повече!

Black Friday: WooCommerce магазинът ми продава повече от магазина ти!

0
Задаваме 7 въпроса, през които трябва да преминете, за да имате изряден WooCommerce магазин. Типично в наш стил, не Ви спестяваме и отговорите.