Приступаючи до роботи з налаштувачем WordPress, CMS та движки для сайтів

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

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

Виберемо приклад

Тема для прикладу, на яку ми посилатимемося. Ви також можете встановити її на своєму WordPress-сайті - вона є повністю робочою і готовою до використання відразу після встановлення.

Короткі зауваження щодо термінів

Терміни Customizer , Theme Modification API та Theme Customization API використовуються у спільноті WordPress , як тотожні та взаємно замінні. Але я думаю, що деякі відмінності між ними існують, і намагаюся їх поважати:

  • Customizer - це розділ інтерфейсу системи WordPress - /wp-admin/customize.php ;
  • Theme Modificaton API - це сімейство функцій, що створюють, зчитують, змінюють і видаляють дані, якими керує налаштувач;
  • Theme Customization API – це сімейство функцій для видалення та додавання параметрів у налаштувач.

Створіть тестовий сайт

Переконайтеся, що на вашому тестовому сайті встановлена ​​остання версія WordPress - на момент написання статті це WordPress 4.3.2. Насправді, для прикладу нам потрібен лише останній WordPress і зазначена вищетема, встановлена ​​та активована:

налаштувачем

Панель налаштувача

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

Ось як ми можемо собі це уявити:

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

Заходячи в панель налаштувача, ми відразу ж бачимо зліва два розділи меню: «Властивості сайту» та «Body»:

налаштувачем

"Властивості сайту" додаються в WordPress за замовчуванням, а "Body" створюється нашою темою.

Якщо ми натиснемо на пункт Body, то побачимо, що він містить кілька розділів: Colors і Layout Options. Нагадаю, що моя тема містить код, який додає пункт Body, розділи Colors і Layout Options:

роботи

Якщо ми зайдемо в розділ «Colors», то побачимо, що я зареєстрував кілька параметрів та елементів керування, за допомогою яких можна змінювати кольори теми. За замовчуванням я встановив значення «Помаранчевий» та «Чорний», які спочатку введені у відповідних полях:

wordpress

Декілька слів щодо даних: WordPress зберігає та витягує параметри за допомогою сімейства функцій Theme Modification . Ми також можемо використовувати ці функції, хоча я використовуватиму в цій темі лише одну функцію get_theme_mod().

Елементи управління

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

Ряд елементів керування додаються системою WordPress, у тому числі панель вибору кольору. Більше про типи елементів керування WordPress за умовчанням ви можете прочитати у кодексі.

Елементи WordPress за замовчуванням та як їх видалити

Давайте повернемося до верху панелі, а потім зайдемо в розділ «Властивості сайту». WordPress додає цю панель за промовчанням, пропускає рівень розділів і виводить відразу кілька параметрів, таких як «Назва сайту» та «Іконка сайту»:

движки

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

Щоб видалити компоненти за промовчанням, я підключаюся до дії customize_register і отримую доступ до об'єкта $wp_customize :

Я вибрав для видалення цих елементів, оскільки вони добре ілюструють ієрархічну структуру, про яку я говорив. Які елементи видаляти, я визначив, вивчивши код розмітки цієї області налаштування. Я використовував атрибут data-customize-setting-link цього елемента управління (ви можете побачити це на скріншоті, наведеному вище).

Щодо одного моменту прошу мене пробачити: видалення nav_menus виведе попередження у режимі налагодження. Я не зміг знайти способу уникнути цього.

Визначення нових панелей, розділів та параметрів

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

Наша тема містить клас, який називається CSST_TMD_Theme_Mods , в якому я створюю масив панелей, розділів і параметрів, що додаються до налаштування. Давайте розберемо приклад, в якому ми додамо панель Body, розділ Кольори в цю панель, а потім додамо параметр Колір фону в цей розділ. Іншими словами:

По-перше, панель з ім'ям body визначається наступним чином:

Потім до розділу colors додається параметр background_color :

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

Але ви не повинні робити це саме таким чином. Ви можете уможливити застосування правила лише в тому випадку, якщо в розділі body присутні певні класи. Можна відмовитися від використання багатовимірного масиву та оголошувати свої параметри по одному.

Якщо від усіх моїх циклів у вас закружляла голова, подивіться чудову тему Twenty Sixteen, яка реєструє параметри "Налаштування" взагалі без циклів. Я не вдаюсь до цієї техніки, тому що вважаю, що вона не надто компактна. Наприклад, рядок color_scheme є у цьому файлі в 83 місцях.

Передача модів теми на налаштувач

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

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

Все це простіше перетравити, якщо ви подивіться вихідний файл. Ознайомтеся з документацією кодексу WordPress щодо функцій, які я використовую для взаємодії з $wp_customize , таким як метод add_setting() .

wordpress

1: Вбудовані стилі для елемента

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

2: Вбудовані блоки стилів

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

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

Стилі для Front End

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

Тема містить клас CSST_TMD_Inline_Styles , який обробляє у циклі всі параметри та виводить відповідний CSS-код за допомогою функції add_inline_style() .

Це означає, що стилі користувача додаються в чергу завантаження вЗалежно від стилів теми. Ось як це виглядає у дії:

Ми викликаємо метод $this -> get_inline_styles(). Цей метод відповідає за обробку в циклі всіх налаштувань налаштування та виведення гігантського блоку CSS:

Блок вбудованих стилів збудовано. На даний момент це один рядок, в якому кожен селектор CSS та кожна властивість CSS визначено в масиві параметрів. Значення CSS – це раніше збережені через налаштування дані, які ми виймаємо.

Інші застосування параметрів налаштувача

Ресурси та наступні кроки

Я настійно рекомендую вам стежити за обговореннями теми налаштувача у блозі Make. У нещодавній статті там зазначається, що продуктивність front-end - це проблемна область налаштування. Я згоден з цим, але продуктивність у Chrome та Firefox може бути суттєво покращена. Також у статті згадується про можливість використання ревізій для налаштувача, подібно до ревізій для записів.

Я бачив кілька збірників елементів управління, розміщених на GitHub . Цей містить кілька корисних та складних елементів керування. А ось ще один.

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

Переклад статті "Getting Started with the WordPress Customizer" був підготовлений дружньою командою проекту Сайтобудування від А до Я.