Full Site Editing у WordPress: практичний гайд

Full Site Editing — уже не експеримент. Це основний спосіб, яким WordPress будує теми, і у 2026 році для клієнтського проєкту питання не в тому, «чи працює», а в тому, де це окупається, а де ні.

У цьому гайді про Full Site Editing у WordPress розберемо, з чого складається блокова тема, що змінилося останнім часом, як я будую клієнтський проєкт навколо theme.json, шаблонів і патернів, як зробити редактор безпечним для людей без технічного досвіду і коли класична тема чи конструктор усе ще розумніший вибір.

Що таке Full Site Editing насправді

У класичній темі шапка, футер і макети сторінок живуть у PHP-файлах, які може змінити лише розробник. У блоковій темі вони складаються з блоків — тих самих, якими пишуть записи. Шаблони й частини шаблонів можна відкрити та змінити в редакторі сайту (Вигляд → Редактор), а один файл, theme.json, описує кольори, типографіку, відступи й ширину контенту.

«Full Site Editing» — загальна назва всього цього набору: блокові теми, редактор сайту, глобальні стилі, патерни та налаштування блоків. Для клієнта це означає, що шапку чи футер можна змінити без розробника. Для розробника — що дизайн-система лежить в одному передбачуваному місці, а не розкидана по PHP, CSS і налаштуваннях плагінів.

Де WordPress у 2026 році

Кілька фактів, які варто знати перед плануванням проєкту (станом на жовтень 2026 року):

WordPress 7.0 вийшов 20 травня 2026 року. Поточна гілка — 7.1, технічний випуск 7.1.3 з’явився в жовтні. WordPress 7.2 заплановано на 8 грудня 2026 року, зі новою стандартною темою Ipsum.
theme.json версії 3 — актуальна схема з WordPress 6.6. Якщо в старій темі ще стоїть "version": 2, вона працює, але нові проєкти варто починати з версії 3.
Block Bindings (з WordPress 6.5) зв’язують атрибути блоків із динамічними даними, наприклад із власним полем, тож абзац, заголовок, зображення чи кнопка можуть показувати дані, які зберігаються деінде.
Перевизначення патернів (pattern overrides) дозволяють одному синхронізованому патерну зберігати дизайн, а в кожному екземплярі змінювати вибраний текст чи зображення. За оглядами релізу 7.0, вони тепер працюють і з власними блоками, не лише з базовими.
Підтримка стилів у блоках зростає. Останні випуски Gutenberg додали параметри майже до кожного базового блоку, тож стилі, для яких раніше потрібен був власний CSS, часто можна перенести в styles.blocks у theme.json.

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

Анатомія блокової теми

Мінімальна блокова тема менша, ніж більшість очікує:

my-theme/
├── style.css          (заголовок теми, обов'язковий)
├── theme.json         (дизайн-токени й налаштування)
├── templates/         (index.html, single.html, page.html, 404.html ...)
├── parts/             (header.html, footer.html)
├── patterns/          (hero.php, pricing.php ...)
└── styles/            (необов'язкові варіації стилів у JSON)

Шаблони й частини шаблонів — звичайні HTML-файли з розміткою блоків. Патерни — PHP-файли з коротким коментарем у заголовку, вони реєструються автоматично. Варіації стилів — JSON-файли, що перевизначають частини theme.json, наприклад темну версію того самого дизайну.

theme.json: дизайн-система в одному файлі

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

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "appearanceTools": true,
    "layout": { "contentSize": "720px", "wideSize": "1200px" },
    "color": {
      "palette": [
        { "slug": "base", "name": "Base", "color": "#ffffff" },
        { "slug": "contrast", "name": "Contrast", "color": "#111827" },
        { "slug": "accent", "name": "Accent", "color": "#1d5fbf" }
      ]
    },
    "typography": {
      "fontFamilies": [
        {
          "slug": "system",
          "name": "System",
          "fontFamily": "-apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif"
        }
      ]
    }
  },
  "styles": {
    "color": {
      "background": "var(--wp--preset--color--base)",
      "text": "var(--wp--preset--color--contrast)"
    },
    "elements": {
      "link": { "color": { "text": "var(--wp--preset--color--accent)" } }
    },
    "blocks": {
      "core/button": { "border": { "radius": "6px" } }
    }
  }
}

Дві деталі важливі на практиці. По-перше, змінні на кшталт --wp--preset--color--accent доступні в будь-якому власному CSS, тож рідкісний нестандартний компонент усе одно користується тими самими токенами. По-друге, стилі окремих блоків пишуться в styles.blocks, тож лишаються в тій самій системі, яку використовує редактор, і глобальні стилі показують клієнтові ті самі значення, що й на сторінці.

Правило, якого я дотримуюся: якщо щось можна описати в theme.json, воно не потрапляє в таблицю стилів. Тема лишається меншою, а редактор — чесним.

Шаблони, частини шаблонів і патерни

Шаблони

Кожен тип контенту має власний шаблон: окремий запис, сторінка, архів, пошук, 404 і будь-який власний тип запису, якому потрібен окремий макет. Тримайте їх небагато. Кожен зайвий шаблон — це те, що треба підтримувати і що клієнт може змінити.

Частини шаблонів

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

Патерни

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

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

Порядок роботи над клієнтським проєктом

Спершу дизайн-токени. Перенесіть кольори, шкалу шрифтів і відступи з макета в theme.json. Узгодьте їх із дизайнером до початку збірки.
Частини шаблонів. Зберіть шапку й футер, разом із навігацією та поведінкою на мобільному.
Патерни для кожної секції, що є в макеті, а не для кожної сторінки.
Шаблони для кожного типу контенту, зібрані з частин шаблонів і патернів.
Динамічний вміст. Підключіть власні поля чи дані запису через Block Bindings, а для списків записів чи товарів використовуйте цикл запиту (Query Loop) замість карток, прописаних вручну.
Захистіть редактор (див. наступний розділ).
Протестуйте очима клієнта. Увійдіть із роллю редактора, змініть заголовок, додайте секцію, замініть зображення. Виправте все, що збиває з пантелику, до передачі проєкту.
Передача проєкту й коротке навчання. Покажіть, що можна змінювати безпечно, а що краще лишити розробнику.

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

Найчастіша тривога щодо Full Site Editing — що клієнт зламає макет. Це слушне занепокоєння, і воно розв’язується кількома рішеннями на етапі збірки:

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

Коли Full Site Editing — правильний вибір, а коли ні

Коли підходить

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

Коли варто замислитися

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

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

Швидкість і підтримка

Блокова тема сама по собі не робить сайт швидким, але дає хорошу відправну точку. Стилі для базових блоків зазвичай підключаються лише на сторінках, де ці блоки є, а тема без конструктора сторінок містить значно менше CSS і JavaScript, ніж універсальна. Зображення, шрифти, сторонні скрипти й хостинг усе одно вирішують підсумковий результат, тож перед запуском варто прочитати про оптимізацію швидкості сайту та Core Web Vitals.

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

Типові помилки

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

Часті питання

Чи готовий Full Site Editing до клієнтських проєктів у 2026 році?

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

Чим блокова тема відрізняється від класичної?

Класична тема будує макет у PHP-файлах шаблонів. Блокова тема будує його з блоків, збережених у HTML-шаблонах, а налаштування дизайну лежать у theme.json. У блоковій темі клієнт може редагувати шаблони, шапку й футер у редакторі сайту; у класичній для цього зазвичай потрібен розробник.

Чи потрібно писати код, щоб цим користуватися?

Щоб користуватися готовою блоковою темою — ні. Щоб створити власну під конкретний дизайн, треба впевнено працювати з theme.json, HTML-шаблонами, трохи PHP для патернів і функціональності та CSS для рідкісних випадків, які токени не покривають.

Чи можна використовувати Elementor чи інший конструктор разом із блоковою темою?

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

Чи може клієнт зламати сайт у редакторі сайту?

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

Підсумок

Full Site Editing працює найкраще, коли його сприймають як дизайн-систему, а не як візуальну іграшку: токени в theme.json, структура в шаблонах і частинах шаблонів, гнучкість у патернах, огорожі для редактора. Так зібрана блокова тема дає клієнтові реальний контроль, а розробнику — код, що лишається невеликим і передбачуваним.

Якщо ви плануєте власну блокову тему або думаєте, чи варто переносити поточний сайт на таку, розкажіть про проєкт. Чесно скажу, чи підходить вам Full Site Editing і з чого розумно почати.

Джерела та додаткове читання

Theme.json version 3 (блог WordPress Core, англійською)
Block Bindings API (документація WordPress для розробників, англійською)
What’s new for developers? October 2026 (WordPress Developer Blog, англійською)
WordPress 7.0: release, new features and update guide (RAIDBOXES, англійською)

Читайте також

Іван Дикий WordPress Developer · 4 роки досвіду

Full Site Editing у 2026: практичний гайд для клієнтських проєктів