Skip to content

Все для WordPress, веб-розробки — і не тільки

✏️ Редагуємо сторінки Grav з фронтенду: встановлення та права доступу

✏️ Редагуємо сторінки Grav з фронтенду: встановлення та права доступу

Контент-менеджер зайшов в адмінку, знайшов сторінку в списку з 50 інших, відкрив редактор, виправив заголовок, зберіг, повернувся на сайт, оновив вкладку. Шість кліків заради одного виправлення. Для Grav CMS існує просте рішення, плагін Editable with ContentTools вбудовує WYSIWYG-редактор просто на сторінку сайту: відкрили, натиснули «змінити», виправили текст і зберегли назад у Markdown-файл без заходу в адмінку.

Плагін не оновлювався з 2022 року (автор офіційно припинив підтримку), але працює стабільно на Grav 1.7 і покриває базовий сценарій, редагування простих Markdown-сторінок без динамічної логіки. Встановлення займе п’ять хвилин, далі правити тексти на фронтенді стане в рази простіше.

Нижче, повна інструкція від встановлення до прав доступу, з розбором обмежень і альтернативою (Fred).

💡 Швидкий огляд:

  • Встановити плагін через GPM або zip-архів і скопіювати конфіг.
  • Налаштувати git-sync для фіксації правок у репозиторії (опціонально).
  • Розмітити редаговані області шорткодом editable з унікальними іменами.
  • Видати права site.editable фронтенд-користувачам.
  • Об’єднати сесії адмінки з фронтендом через session.split: false.
  • Враховувати обмеження: тільки чистий Markdown, без Twig і динаміки.

Встановлення: через GPM або вручну

Плагін встановлюється через Grav Package Manager, стандартний спосіб для будь-якого доповнення в Grav:

1bin/gpm install editable-contenttools

Команду запускайте з кореневої папки сайту (там, де лежить bin/). GPM сам завантажить останню версію і розпакує в /user/plugins/editable-contenttools.

Альтернативно можна встановити вручну: завантажте zip-архів з GitHub, розпакуйте в /user/plugins/ і перейменуйте папку на editable-contenttools (без суфікса -master). Структура має виглядати так: /user/plugins/editable-contenttools/editable-contenttools.php.

Копіюємо конфіг у безпечне місце

Після встановлення обов’язково скопіюйте конфігураційний файл до користувацької директорії:

1cp user/plugins/editable-contenttools/editable-contenttools.yaml user/config/plugins/editable-contenttools.yaml

Цей крок важливий: якщо налаштування залишаться в папці плагіна, вони скинуться під час оновлення через GPM. Альтернативний варіант, встановлення через Admin-панель Grav (розділ Plugins → Add), у цьому випадку система сама створює конфіг у user/config/plugins/ і копіювати вручну не потрібно.

Налаштування: три опції конфігу

Файл editable-contenttools.yaml містить три параметри:

1enabled: true
2git-sync: false
3git-sync-mode: foreground

enabled, вмикає плагін. Без enabled: true редактор не з’явиться на фронтенді, навіть якщо права видано. За замовчуванням true.

git-sync, запускає синхронізацію з Git-репозиторієм після кожного збереження. Працює тільки за наявності встановленого плагіна Git Sync. Якщо ваш сайт живе в Git і ви хочете фіксувати кожну зміну в історії, ставте true. Інакше залиште false.

git-sync-mode, визначає, чи чекати завершення синхронізації перед поверненням керування користувачеві. foreground означає, що кнопка «Зберегти» розблокується тільки після завершення коміту і пушу. background працює асинхронно, але на деяких Linux-серверах можуть бути проблеми з фоновими процесами. Для більшості сценаріїв достатньо foreground.

Розмітка редагованих областей: шорткод [editable]

Приклад шорткоду [editable] у Markdown-файлі сторінки Grav

Плагін не робить редагованою всю сторінку автоматично. Ви самі визначаєте, які блоки можна правити, через шорткод [editable]:

1[editable]
2## Заголовок раздела
3
4Текст, который можно редактировать из фронтенда.
5[/editable]

Сторінка може містити будь-яку кількість таких областей. Кожна область повинна мати унікальне ім’я, інакше ContentTools не зрозуміє, куди зберігати зміни.

Параметр name: обов’язкова унікальність

За замовчуванням плагін призначає імена автоматично (region-0, region-1 і так далі), але краще задавати осмислені імена вручну:

1[editable name="hero-block"]
2## Главный заголовок
3
4Текст, который можно редактировать.
5[/editable]

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

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

Спробувати можна на демо-сайті плагіна (збереження вимкнено, Grav 1.7.46).

Права доступу: фронтенд і бекенд

Щоб користувач побачив іконку олівця, йому потрібні права на редагування. Правила різні для фронтенд-користувачів (контент-менеджери) і бекенд-користувачів (адміністратори).

Фронтенд-користувачі

Користувач повинен уміти ввійти в систему через плагін Grav Login або Private Grav. Потім у файлі облікового запису (user/accounts/username.yaml) додайте:

1access:
2 site:
3 login: 'true'
4 editable: 'true'

Без дозволу site.editable іконка олівця не з'явиться, навіть якщо користувач залогінений і має інші права.

Бекенд-користувачі (адміністратори)

Типово Grav розділяє сесії адмінки та фронтенду. Щоб адміністратор міг редагувати сторінки прямо на сайті (не заходячи в адмінку), встановіть у system.yaml (або через адмін-панель Configuration → System):

1session:
2 split: false

Це об'єднає сесії: вхід в адмінку автоматично надасть доступ до фронтенд-редактора. Адміністратору також знадобиться дозвіл admin.super або admin.pages у файлі облікового запису.

Якщо після входу іконка не з'явилася, перевірте кешування адміна:

1admin:
2 super: 'true'
3 login: 'true'
4 cache: 'false'

Параметр cache: false вимикає кеш для адміна і може вирішити проблему з невидимою іконкою.

Обмеження: що плагін НЕ вміє

Плагін працює виключно з чистим Markdown. Це архітектурне обмеження, а не баг: ContentTools редагує HTML у браузері, а плагін конвертує HTML назад у Markdown. У процесі будь-яка динамічна розмітка буде зіпсована. Не редагуйте через ContentTools контент, який:

  • збирається шаблонами Twig (наприклад, модульні сторінки: дочірні блоки вставляються батьківським динамічно, плагін не бачить їхнє джерело);
  • впроваджується іншими плагінами (Page Inject та аналоги вставляють контент з інших сторінок — це односторонній процес);
  • змінюється через JavaScript у браузері (слайдери, акордеони та інші інтерактивні елементи будуть конвертовані в статичний HTML);
  • містить спецтеги Grav Markdown (зображення з параметрами ?lightbox і ?resize будуть пошкоджені під час конвертації HTML → Markdown, параметри обробки зникнуть).

Правила безпеки прості:

  • Тримайте зображення та складні шорткоди поза редагованими областями.
  • Робіть області невеликими, кількість не обмежена, краще 10 маленьких блоків, ніж один великий із ризиками.
  • Тестуйте на копії поста або staging-оточенні перед тим, як дати доступ редакторам.
  • Помітили різницю в Markdown-розмітці між версією з іконкою олівця та без, виносьте цей фрагмент за межі [editable].

Альтернатива: плагін Fred

Якщо функціональності Editable with ContentTools не вистачає, подивіться на Fred, новіший фронтенд-редактор для Grav, теж на базі ContentTools. З відмінностей:

  • Завантаження зображень через діалог (з поворотом і базовою обробкою).
  • Авто-обгортка контенту через подію onPageProcessed, менше ручної розмітки шорткодами.
  • Активна розробка: автор приймає issues на GitHub і допрацьовує функціонал.

Встановлення через клонування репозиторію в /user/plugins/fred:

1cd user/plugins
2git clone https://github.com/BugHunter2k/grav-plugin-fred.git fred

Права задаються аналогічно: site.editor: true в обліковому записі користувача (зверніть увагу, не site.editable, а site.editor).

І Editable with ContentTools, і Fred вирішують одне завдання, дають контент-менеджеру інструмент швидкого редагування без заходу в адмінку. Перший підійде, якщо потрібен простий налагоджений інструмент для Markdown-сторінок без експериментів. Другий, якщо хочете більше автоматики та готові до можливих шорсткостей активної розробки.

Відео: як працює ContentTools

Двохвилинна демонстрація редагування сторінки Grav у браузері: автор показує, як виділяються редаговані області, вносяться зміни та зберігаються назад у Markdown. Гарний спосіб побачити плагін у дії до встановлення.

⁉️🤔 Часті запитання

Чому іконка олівця не з’являється після встановлення?

Перевірте чотири пункти. Перше, enabled: true у конфігурації плагіна (user/config/plugins/editable-contenttools.yaml). Друге, користувач повинен мати право site.editable у файлі облікового запису. Третє, для бекенд-користувачів session.split має бути false у system.yaml. Четверте, очистіть кеш Grav: bin/grav clear-cache. Зазвичай проблема або в правах, або в split-сесіях.

Чи можна редагувати модульні сторінки?

Ні. Модульні сторінки збираються з дочірніх через Twig-шаблони — це односторонній процес, плагін не може «розібрати» результат назад на частини. На фронтенді ви бачите готовий HTML, але джерело (окремі Markdown-файли дочірніх модулів) знаходиться в інших папках, плагін не знає, куди зберігати зміни. Для модульних сторінок використовуйте стандартний Admin-інтерфейс Grav.

Що буде, якщо залишити зображення всередині [editable]?

Спецтеги Grav Markdown для зображень (з параметрами ?lightbox, ?resize, ?cropResize) будуть пошкоджені під час конвертації HTML у Markdown. Саме зображення залишиться на місці (тег <img> конвертується у звичайний Markdown ![](url)), але параметри обробки зникнуть. Висновок: зображення з параметрами завжди зовні редагованої області. Якщо зображення просте (без параметрів), технічно можна залишити всередині, але на практиці безпечніше виносити всі медіа за межі [editable].

Плагін закинутий автором, чи безпечно його використовувати?

Автор офіційно оголосив про відмову від підтримки у 2022 році, останній коміт датований серпнем 2024 року (оновлення сумісності з Grav 1.7). Плагін стабільний на Grav 1.7 і не зачіпає критичні для безпеки компоненти: він працює тільки з Markdown-контентом і не має доступу до серверних операцій. Якщо плануєте перехід на Grav 2.0, краще дивитися в бік Fred або чекати офіційного рішення для фронтенд-редагування (на форумі обговорюються нові підходи на базі TinyMCE та Prosemirror).

Чим відрізняється Editable with SimpleMDE від версії з ContentTools?

Editable with SimpleMDE використовує той самий підхід (фронтенд-редагування), але замість візуального редактора ставить Markdown-редактор SimpleMDE з live-preview. Підійде тим, хто воліє писати розмітку руками і хоче бачити результат праворуч від редактора, а не в режимі WYSIWYG. Обидва плагіни від одного автора (bleutzinn) і обидва закинуті з 2022 року.

Чи варто ставити фронтенд-редактор для Grav у 2026 році

Якщо ваш сайт на Grav 1.7 складається з простих Markdown-сторінок і контент-менеджери втомилися заходити в адмінку заради кількох правок, ставте Editable with ContentTools. П’ять хвилин на встановлення, мінімум конфігурації: редагування стає однокліковим. Відкрили сторінку, натиснули олівець, виправили текст, зберегли. Жодних пошуків у списку сторінок, жодних перемикань вкладок.

Для нових проєктів або під час планування переходу на Grav 2.0 (реліз очікується у 2026 році, хоча точної дати немає) придивіться до Fred: він активніше розвивається і з більшою ймовірністю отримає сумісність із другою версією CMS. У будь-якому разі фронтенд-редагування економить десятки кліків і хвилини часу на кожній правці, особливо помітно на сайтах із частими оновленнями контенту. Спробуйте на тестовому оточенні та вирішіть, наскільки такий підхід пришвидшує ваш робочий процес.