Посібник з усунення неполадок

Цей розділ охоплює найпоширеніші проблеми, з якими ви можете зіткнутися з Field Forge, та способи їх вирішення. Для кожної проблеми ми описуємо симптоми, ймовірні причини та покрокові рішення.

Підказка Допомога Відкриває Головну Сторінку Замість Статті

Симптоми: Натискання на маленьку іконку допомоги ? в адмінці Field Forge відкриває головну сторінку Field Forge або домашню сторінку документації замість конкретної статті для цього налаштування. Виправлення: Оновіть Field Forge до поточної версії. Посилання на допомогу в адмінці тепер ведуть до точних URL-адрес розділів Посібника користувача або Посібника для розробників. Якщо кешована адмін-сторінка все ще має старе посилання, оновіть сторінку один раз.

Forge Suite Деактивація на клоні впливає на інший сайт

Симптоми: Ви клонували або відновили сайт WordPress, а потім натиснули Forge Suite > Deactivate на клону. Інший сайт, що використовує ту ж ліцензію, здавалося, втратив стан PRO або Connect. Причина: Старі версії довіряли ідентифікатору установки Freemius, збереженому в fs_accounts. Клонована база даних може містити ідентифікатор установки та URL оригінального сайту, тому навіть деактивація Freemius, що стосується установки, може націлюватися на оригінальну віддалену установку. Виправлення: Оновіть Field Forge до останньої версії. Forge Suite тепер порівнює збережений URL сайту Freemius з поточними site_url() / home_url() WordPress перед будь-якою віддаленою деактивацією. Якщо стан належить іншому сайту, він пропускає віддалений виклик Freemius і лише очищає локальний стан ліцензії для поточної установки WordPress. Підключіть клон через Field Forge > License > Connect to Avakode, коли ви хочете, щоб він знову отримав ліцензію.

Поля не відображаються в редакторі постів

Симптоми: Ви створили групу полів, але поля не з’являються, коли ви редагуєте пост або сторінку. Можливі причини та виправлення:

Правила розташування не відповідають посту. Відкрийте групу полів і перевірте розділ Правила розташування. Переконайтеся, що умови відповідають посту, який ви редагуєте. Наприклад, якщо правило говорить “Тип поста дорівнює Продукт”, але ви редагуєте Сторінку, поля не з’являться.
Група полів встановлена на Неактивну. У списку груп полів перевірте, щоб стовпець Статус показував “Активна”. Якщо там написано “Неактивна”, відкрийте групу полів і змініть її статус.
Інший плагін приховує метабокс. Деякі плагіни для створення сторінок або плагіни для очищення адміністративної панелі приховують метабокси. Перевірте Опції екрана (у верхньому правому куті екрана редагування) і переконайтеся, що метабокс вашої групи полів відмічений.
Група полів не має полів. Порожня група полів з нульовою кількістю полів не відобразить метабокс. Відкрийте групу полів і додайте принаймні одне поле.
Проблема з кешем. Якщо ви тільки що створили групу полів, спробуйте оновити сторінку редактора постів. У деяких середовищах хостингу кеш об’єктів може затримувати появу нових метабоксів.

get_field() повертає null

Симптоми: Ваш шаблон теми використовує get_field('field_name'), але він повертає null або порожнє значення, хоча дані були введені в редакторі. Можливі причини та виправлення:

Неправильне ім’я поля. Ім’я, передане в get_field(), повинно відповідати імені поля (slug), а не мітці. Відкрийте редактор групи полів і перевірте стовпець Ім’я. Наприклад, якщо мітка “Hero Title”, але ім’я hero_title, використовуйте get_field('hero_title').
Відсутній ID поста. Якщо ви викликаєте get_field() поза циклом The Loop (наприклад, у шаблоні заголовка або підвалу), ви повинні явно передати ID поста: get_field('hero_title', $post_id). Без другого параметра за замовчуванням використовується поточний пост у The Loop, який може не існувати у вашому контексті.
Використання даних сторінки параметрів без ‘options’. Для полів сторінки параметрів ви повинні передати 'options' як другий параметр: get_field('site_phone', 'options'). Без цього Field Forge шукає поле в поточному пості і нічого не знаходить.
Field Forge деактивовано. Якщо Field Forge не активний, а ваша тема не має резервного варіанту, get_field() буде невизначеним і викличе фатальну помилку (або поверне null, якщо інший плагін надає заміну). Перевірте, що Field Forge активовано в плагінах.
Дані були введені з ACF, але не мігрували. Якщо дані спочатку були збережені ACF і ви не виконали міграцію, таблиці Field Forge будуть порожніми. Перейдіть до Field Forge > Міграція та імпортуйте значення.
ACF активний під час перевірки сторінки параметрів LangForge. Коли ACF володіє get_field(), Field Forge тепер з’єднує порожні зчитування параметрів ACF з тією ж таблицею параметрів Field Forge, яка враховує мову, що використовується шаром сумісності ACF. Це призначено для вікон міграції/QA, де ACF, Field Forge і LangForge активні разом.

Зміни в полі всередині групи не зберігаються

Симптоми: Ви змінюєте текст, значення текстового поля або WYSIWYG, яке знаходиться всередині поля Групи, натискаєте Оновити, і значення повертається до попереднього вмісту після перезавантаження. Інші поля в тому ж пості зберігаються нормально. Поля поза Групою зберігаються нормально. Чому це відбувається: Це була регресія, специфічна для Груп, дані яких були імпортовані з ACF (або мігрували з попереднього плагіна) і, отже, зберігалися ієрархічно — сама група займає один рядок у таблиці значень Field Forge, а кожне підполе пов’язане з ID запису групи. Підполя адміністративної форми в цій структурі надсилалися під ключем POST, який обробник збереження Field Forge не читав, тому редагування підполів тихо відкидалися. Групи, які ніколи не торкалися імпорту ACF, продовжували працювати, оскільки використовували застарілий шлях зберігання, який обробник збереження дійсно читав. Що робить поточна версія: Тепер обробник збереження розпізнає ієрархічні підполя групи і маршрутизує їх через той же валідатор + шлях зберігання, що й будь-яке інше поле. Виправлення охоплює текст, текстове поле, WYSIWYG, число, вибір та інші типи “простих” полів всередині Груп, а також Групи, вкладені всередині Повторювачів та Гнучких макетів контенту. Відновлення вже втрачених редагувань: Редагування, зроблені до виправлення, ніколи не зберігалися — немає запису про них для відновлення. Введіть вміст знову і натисніть Оновити; значення збережеться правильно.

Значення накопичують зворотні слеші при кожному збереженні

Симптоми: Поле з лапками у його значенні (найчастіше вбудоване iframe, блок WYSIWYG, що містить атрибути data-*, або текстове поле з сирим HTML) починає показувати додаткові зворотні слеші щоразу, коли пост зберігається: width="900" стає width=\"900\", потім width=\\\"900\\\" і так далі — до десятка або більше зворотних слешів після кількох раундів редагування. Повторне редагування поля, створення перекладів або використання сторонніх інструментів “дублювання постів” прискорює накопичення. Чому це відбувається: WordPress автоматично додає зворотний слеш перед кожною лапкою у формі даних. Обробник збереження Field Forge раніше зберігав отримане значення без видалення цих доданих слешів, тому кожен раунд збереження зберігав попередні слеші і додавав новий шар зверху. Значення, які ніколи не містили лапок, не піддавалися впливу. Що робить поточна версія: Обробник збереження один раз на початку знімає екранізацію з вхідних даних форми, тому збережене значення відповідає тому, що насправді ввів користувач. Майбутні збереження більше не додають слеші. Очищення вже пошкоджених значень:

Відкрийте кожен пост, що підлягає впливу, в адмінці. Якщо значення відображається з видимими зворотними слешами перед лапками, збережений вміст пошкоджений.
У редакторі поля вручну видаліть зворотні слеші та збережіть один раз — виправлене значення збережеться надалі.
Для масового ремонту на сайті з багатьма пошкодженими рядками можна використовувати скрипт WP-CLI, який ітерує stripslashes() над значеннями в wp_fieldforge_values, поки значення не стабілізується. Обмежте проходження текстовими типами полів (wysiwyg, textarea, text, url, email) — бінарні ідентифікатори та кольорові значення не повинні бути змінені. Зверніться до служби підтримки, якщо вам потрібен точний запит.

Міграція ACF неповна або зависла

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

Тайм-аут PHP. Великі сайти можуть досягти межі часу виконання PHP. Міграція виконується партіями по 50 постів, щоб уникнути цього, але дуже повільні сервери можуть все ще вийти з ладу. Збільшіть max_execution_time у ваших налаштуваннях PHP (або php.ini) до принаймні 300 секунд, а потім перезапустіть міграцію.
Обмеження пам’яті. Пости з багатьма складними полями (вкладені повторювачі, великі галереї) можуть споживати значну кількість пам’яті. Збільшіть memory_limit до принаймні 256M у ваших налаштуваннях PHP.
ACF було деактивовано до завершення міграції. ACF має залишатися активним протягом усього процесу міграції, оскільки Field Forge читає дані через функції ACF. Реактивуйте ACF і перезапустіть міграцію.
Фонове оброблення завершилося без помилок. Перевірте сторінку статусу міграції Field Forge на наявність повідомлень про помилки. Якщо фоновий процес був перерваний (перезавантаження сервера, технічне обслуговування хостингу), натисніть “Продовжити міграцію”, щоб продовжити з того місця, де зупинився.
Часткова міграція очікується у безкоштовній версії. Безкоштовна версія мігрує лише визначення груп полів, а не значення полів. Якщо ваші пости мають правильні поля, але без даних, оновіть до PRO, щоб мігрувати значення.
Несумісність локального QA завантаження. На локальних сайтах Forge QA, які визначають FORGE_SKIP_LICENSE_REVALIDATION, або forge_e2e_plan=pro, або дійсний запис локальної ліцензії fieldforge_license_data['plan']='pro' відкриває міграцію значень. Така ж локальна константа також переводить Freemius в анонімний режим для запитів адміністратора Field Forge, тому свіжий QA сайт не повинен бути заблокований екраном згоди Freemius перед відкриттям сторінок Field Forge.

Локальний JSON не синхронізується

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

Локальний JSON не увімкнено. Перейдіть до Field Forge > Налаштування та перевірте, що синхронізація локального JSON увімкнена.
Неправильний шлях до каталогу. Field Forge шукає JSON-файли у папці fieldforge-json/ всередині вашої активної теми (або у вказаному користувачем шляху, якщо налаштовано). Перевірте, чи існує папка та чи містить вона файли .json. Шлях чутливий до регістру.
Права доступу до файлів. Веб-серверу потрібен доступ на читання до каталогу JSON. На більшості хостингів правильними є права 755 для папки та 644 для файлів.
Повідомлення про синхронізацію закрито. Коли Field Forge виявляє оновлені JSON-файли, він показує повідомлення про синхронізацію в адмінці. Якщо хтось закрив повідомлення, не натиснувши “Синхронізувати”, зміни не були застосовані. Перейдіть до Field Forge > Групи полів і перевірте наявність будь-яких очікуючих повідомлень про синхронізацію.
Тема була змінена. Якщо активна тема змінилася, Field Forge шукає у каталозі нової теми. Переконайтеся, що JSON-файли існують в активній темі.
Ви імпортуєте ACF Local JSON, а не синхронізуєте Field Forge JSON. Файли джерела ACF повинні знаходитися в acf-json/ і обробляються інструментом міграції ACF. Власні файли синхронізації Field Forge повинні знаходитися в fieldforge-json/.

Сторінка параметрів не з’являється

Симптоми: Ви створили сторінку параметрів, але вона не з’являється в бічній панелі адміністратора WordPress. Можливі причини та рішення:

PRO не активовано. Сторінки параметрів вимагають ліцензію PRO. Перейдіть до Field Forge > License і перевірте, чи ваша ліцензія активна.
Несумісність можливостей. Якщо сторінка параметрів була створена з кастомною можливістю, ваш обліковий запис може її не мати. Увійдіть як адміністратор, щоб підтвердити існування сторінки, а потім при необхідності відкоригуйте налаштування можливостей.
Конфлікт позицій меню. Якщо інший плагін або елемент меню займає той же номер позиції, сторінка параметрів може бути прихована за ним. Спробуйте змінити позицію меню в налаштуваннях сторінки параметрів.
Кеш. Деякі плагіни кешування або об’єктні кеші можуть кешувати меню адміністратора. Очистіть кеш і оновіть панель адміністратора.

Зміни на сторінці параметрів зникають після збереження

Симптоми: Ви відкриваєте сторінку налаштувань (налаштування теми “Общие”, кастомна сторінка налаштувань або будь-яка сторінка, зареєстрована через acf_add_options_page / fieldforge_add_options_page), редагуєте значення або додаєте новий рядок повторювача, натискаєте Зберегти, бачите зелене повідомлення “Опції збережено”, а потім при перезавантаженні форма показує СТАРЕ значення. Новий рядок повторювача зник, змінене посилання на карту повернулося назад, вибрана сторінка Політики конфіденційності порожня. Чому це відбувається (будь-яка з чотирьох основних причин, усі виправлені разом у v1.0.10):

Перекладена вкладка мови читала дані за замовчуванням. Сумісний шар не враховував перемикач адміністратора LangForge ?lf_lang=, тому вкладка EN/UZ відображала значення RU. Редагування їх потім записувало назад у сховище мови за замовчуванням, і перекладена мова залишалася порожньою.
Складні імена підполів відхилялися списком дозволених для збереження. Підполя, чиє ім’я містило підкреслення — map_link, privacy_policy, social_name, social_link — були тихо відкинуті з обробки POST, оскільки список дозволених розділяв ім’я на _ і вимагав, щоб кожна частина була зареєстрованим полем. Їх значення ніколи не потрапляли в базу даних.
Вкладені have_rows шукали сховище під неправильним префіксом. Тема, що викликала have_rows('socials') всередині have_rows('common', 'option'), шукала ключі з іменем лише socials замість common_socials. На фронтенді відображався порожній розділ, навіть коли дані були правильно збережені.
Прихований рахунок рядків не оновлювався, коли ви натискали Додати рядок або Видалити рядок. Дані нового рядка були збережені, але поле рахунку все ще показувало старе число. При повторному рендерингу сервер ітерував для ($i = 0; $i < count) і зовсім пропускав новий рядок. Рядок залишався в базі даних, невидимий як для адміністративної форми, так і для публічного сайту.

Що робить поточна версія: всі чотири помилки виправлені в v1.0.10. Читання та запис на сторінках налаштувань враховують активну мову; складні імена проходять через список дозволених за допомогою жадібного префіксного співпадіння; вкладені ітерації несуть префікс батьківського поля; Додати рядок / Видалити рядок оновлюють індекси та живо оновлюють поле рахунку, тому збереження/перезавантаження завжди відображає те, що ви надіслали. Якщо ви все ще бачите симптом після оновлення:

Жорстко перезавантажте адміністративну сторінку (Cmd+Shift+R / Ctrl+Shift+R), щоб отримати новий admin.js. Скидання кешу автоматичне, коли ви завантажуєте новий файл, але застарілий кеш браузера зберігатиме стару поведінку.
Перевірте, чи ваш PHP OPcache на хостингу підхопив нові PHP файли. На хостингу Hostinger / LiteSpeed OPcache може зберігати старі файли класів до години після завантаження. Перемикайте версію PHP в панелі або завантажте маленький скрипт , щоб скинути кеш.
Якщо ваш сайт використовує плагін перекладу, відмінний від LangForge (WPML, Polylang), фільтр fieldforge/options_post_id, підключений LangForge, не спрацює. Сумісність плагіна перекладу для сторінок налаштувань знаходиться в планах; наразі ACF Pro + ACFML аддон WPML є підтримуваним стеком на цих сайтах.

Підполя повторювача зображення / посилання на сторінку / текстова область показують сирі числові ID в редакторі

Симптоми: У полі Repeater на екрані редагування поста стовпці, такі як Image або Image @2x, відображають просте число (800, 2954) у текстовому полі замість попереднього перегляду зображення з кнопками Вибрати / Видалити. Стовпець URL / Посилання на сторінку показує числовий ID поста. Стовпець текстової області показує однорядкове текстове поле, яке обрізає довгий контент. Причина (виправлено 2026-04-24): Рендерер Repeater жорстко закодував кожне підполе для рендерингу як , ігноруючи фактичний тип підполя. Поля верхнього рівня одного й того ж типу рендерилися правильно через рендерер, що враховує тип — лише шлях повторювача пропускав диспетчеризацію. Виправлення: Оновіть Field Forge до останньої версії. Підполя Repeater тепер диспетчеризуються до того ж рендерера, що враховує тип, який використовують поля верхнього рівня: підполя зображень повертаються з попередніми ескізами + кнопками Вибрати / Видалити, підполя page_link і post_object рендеряться як випадаючі списки опублікованих сторінок + постів, текстові області рендеряться як багаторядкові текстові області. Поведінка збереження та схема HTML input-name залишилися незмінними, тому раніше відредаговані значення зберігаються.

Вкладений повторювач всередині повторювача показує число в текстовому полі

Симптоми: Ретранслятор має підполе, яке само є ретранслятором (наприклад, щорічний блок Нагород, де кожен рік містить список окремих нагород). На екрані редагування поста зовнішні рядки відображаються правильно, але вкладений стовпець показує просте однозначне або двозначне число в текстовому полі — число відповідає кількості внутрішніх рядків для цього зовнішнього рядка. Натискання на “число” нічого не робить, і немає можливості редагувати внутрішні елементи з редактора. Публічний фронт відображається правильно, оскільки шлях читання ніколи не був зламаний. Причина (виправлено 2026-04-24): Диспетчер на рівні рядка, введений 2026-04-24, обробляв прості типи підполів (зображення, текстове поле, посилання на сторінку, об’єкт поста тощо), але все ще маршрутизував вкладені складні типи — Ретранслятор, Група, Гнучкий Контент — через резервний текстовий ввід. Резервне копіювання перетворювало значення кількості рядків вкладеного ретранслятора в рядок, що є причиною появи цифри замість реального інтерфейсу. Виправлення: Оновіть Field Forge до останньої версії. Рендерер ретранслятора тепер виявляє, коли тип підполя є одним з repeater / group / flexible_content і делегує до спільного рендерера складних типів з вкладеним ідентифікатором запису, який завантажувач значень зберігає на кожному рядку. Вкладені ретранслятори тепер рендерять свої власні рядки з ручками перетягування, кнопками видалення та повністю функціональними ввідними полями підполів (зображення, текстові області тощо), а вкладені групи рендерять свої сітки підполів. Поведінка збереження та схема імен вводу HTML залишаються незмінними — існуючі дані стають редагованими при наступному завантаженні сторінки без необхідності міграції даних.

Кнопка “Додати рядок” повторювача відображається без мітки (порожня пігулка внизу повторювача)

Симптоми: Внизу Repeater (а також у вкладених Repeater та блоках Flexible Content) є порожня овальна форма з рожевим контуром, де має бути кнопка “Додати рядок” / “Додати макет”. Натискання на неї все ще додає рядок, але немає видимого напису, щоб направити редактора. Причина (виправлено 2026-04-24): Для повторювачів, мігрованих з ACF, button_label зберігається як порожній рядок, а не null. Рендерер використовував $field['button_label'] ?? __('Add Row'), щоб повернутися до стандартного напису, але ?? спрацьовує лише на null — порожній рядок проходить, тому кнопка рендерилася без тексту. Виправлення: Оновіть Field Forge до останньої версії. Тепер резервне копіювання використовує !empty(...), тому як null, так і порожні рядки вирішуються на стандартний напис “Додати рядок” / “Додати макет”. Встановлення власного button_label у редакторі групи полів все ще працює так само, як і раніше.

Ширина підполя всередині повторювача ігнорується (всі стовпці відображаються з однаковою шириною)

Симптоми: У редакторі групи полів Ріпітер має підполя з явними значеннями Width % (наприклад, Рік 20% і Нагороди 80%), але на екрані редагування поста кожен стовпець підполя займає рівну частку рядка — два підполя займають 50%/50%, чотири — 25%/25%/25%/25% тощо. Налаштування Width % здається, що зберігається, але не має видимого ефекту. Причина (виправлено 2026-04-24): Макет рядка ріпітера використовував контейнер flex з flex: 1 на кожній клітинці, що переважало будь-яке wrapper.width, яке мало підполе. Поля верхнього рівня генерували інлайн-стиль з їхньої ширини обгортки, але шлях до клітинки ріпітера не мав такого гілки. Виправлення: Оновіть Field Forge до останньої версії. Кожна клітинка підполя ріпітера тепер генерує атрибут data-width="N" і інлайн-стиль flex: 0 0 calc(N% - 8px); max-width: calc(N% - 8px), що походить з wrapper.width підполя, всередині ряду flex з gap: 8px і flex-wrap: wrap. Ширини враховуються як для зовнішніх ріпітерів, так і для вкладених ріпітерів/груп/флексів. Клітинки без налаштованої ширини все ще повертаються до flex: 1 і ділять ряд рівномірно.

Ширина % значка в редакторі не оновлюється, коли ви вводите

Симптоми: У редакторі групи полів кожне підполе має маленький значок троянди поруч із міткою типу (наприклад, “Text 20%”), який відображає його wrapper.width. Введення нового значення в поле Width % змінює введене значення, але залишає значок незмінним, поки сторінка не буде збережена та перезавантажена — створюючи враження, що зміна не зберігається. Причина (виправлено 2026-04-24): Значок рендерився один раз з серверного значення при початковому завантаженні. Обробник живого введення оновлював стан поля JS, але не торкався елемента значка, тому два візуальних елементи віддалялися один від одного до наступного повного повторного рендерингу. Виправлення: Оновіть Field Forge до останньої версії. Обробник введення wrapper.width тепер відображає поточне значення в значку троянди в реальному часі — додаючи значок, коли ширина вперше встановлена, оновлюючи його текст під час введення та видаляючи його, коли поле очищається. Ніяких функціональних змін, лише покращення візуальної узгодженості.

Перекладена сторінка (WPML) відображає текст мови-джерела для групових полів

Симптоми: Після перекладу поста за допомогою WPML, публічний фронт-енд перекладеної мови показує вміст мови оригіналу для полів, збережених всередині Групи — навіть якщо метабокс Field Forge в адмінці чітко показує правильний переклад. Типова маніфестація: блок деталей проекту відображає англійські мітки під російським URL (або навпаки). Причина (виправлено 2026-04-24): WPML дублює метадані поста оригіналу на переклад під час перекладу і не синхронізує їх з подальшими редагуваннями. Ваші редагування підполів Групи перекладеного поста зберігаються в власній таблиці Field Forge (wp_fieldforge_values) під ідентифікатором перекладеного поста, але застаріла сумісна версія ACF читала значення Групи лише з get_post_meta(), що для перекладеного поста все ще повертало незмінну копію мови оригіналу. Виправлення: Оновіть Field Forge до останньої версії. Сумісна версія тепер надає перевагу значенням з wp_fieldforge_values, коли запис існує для поточного поста, повертається до get_post_meta() лише коли запис не знайдено, і обережно заповнює відсутні підполя з метаданих ACF, щоб частково мігрувані групи деградували граційно. Міграція даних не потрібна — існуючі переклади стануть правильними при наступному завантаженні сторінки.

Wysiwyg / зображення / текстовий контент зникає після вкладеного циклу `have_rows`

Симптоми: Шаблон теми ітерує одне поле repeater або flexible_content всередині іншого (наприклад, блок video або image, вкладений всередині групи topside), і відразу після внутрішнього циклу викликає the_sub_field('textblock') або the_sub_field('img') на зовнішньому рядку — значення повертається порожнім, тому навколишній розмітка виглядає зламаною. Зображення рендеряться з src="" і показують лише текст alt як запасний варіант; текстові блоки зникають зовсім. Причина (виправлено 2026-04-24): Коли ітерація have_rows() завершувалася, сумісний шар безумовно очищав вказівник на поточний рядок, навіть якщо ітерація була вкладена всередині все ще активного зовнішнього циклу. Реальна поведінка ACF полягає в тому, що поточний рядок зовнішнього циклу зберігається до завершення зовнішньої ітерації. Виправлення: Оновіть Field Forge до останньої версії. Наприкінці ітерації сумісний шар тепер відновлює поточний рядок до найбільш нещодавнього все ще активного циклу в стеку і очищає його лише тоді, коли жоден цикл не активний. Шаблони, які змішують вкладені виклики have_rows — поширений шаблон ACF — тепер працюють, як очікувалося.

Кнопка “Додати рядок” повторювача не працює

Симптоми: Натискання на “Додати рядок” у полі повторювача нічого не робить, або кнопка сірого кольору. Можливі причини та рішення:

Досягнуто максимальну кількість рядків. Якщо у повторювача є налаштування максимальної кількості рядків і ви досягли цього ліміту, кнопка “Додати рядок” буде деактивована. Перевірте конфігурацію повторювача на наявність значення максимальних рядків.
Помилка JavaScript. Відкрийте консоль розробника вашого браузера (F12 або Cmd+Option+I) і перевірте наявність помилок JavaScript. Конфлікт з іншим плагіном або скриптом теми може заважати функціонуванню повторювача. Звичайними винуватцями є плагіни для побудови сторінок або плагіни оптимізації адміністративної панелі, які агресивно об’єднують скрипти.
Ліцензія PRO неактивна. Повторювач є полем типу PRO. Якщо ваша ліцензія закінчилася або була деактивована, функціональність повторювача може бути обмежена. Перевірте Field Forge > License.
Сумісність браузера. Спробуйте інший браузер або очистіть кеш браузера. Застарілі версії браузерів іноді мають проблеми з динамічними елементами форм.

Відсутні макети гнучкого контенту

Симптоми: Коли ви натискаєте “Додати макет” у полі Гнучкого вмісту, випадаючий список порожній або деякі макети відсутні. Можливі причини та рішення:

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

Проблеми з продуктивністю з багатьма групами полів

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

Занадто багато полів в одному пості. Якщо один пост відповідає багатьом групам полів (в результаті чого більше 50 полів), редактор може стати повільним. Консолідуйте групи полів, де це можливо, або використовуйте поля Tab для організації великих груп у секції. Вкладки завантажують поля ліниво, покращуючи сприйняту продуктивність.
Складна умовна логіка. Широка умовна логіка з багатьма взаємопов’язаними правилами вимагає більше обробки JavaScript. Спрощуйте умови, де це можливо.
Обмеження хостингу. Спільний хостинг з обмеженим процесором і пам’яттю може мати проблеми з складними адміністративними сторінками. Розгляньте можливість переходу на керований хостинг WordPress, якщо продуктивність адміністративної частини постійно погана.
Кешування об’єктів. Встановіть плагін кешування об’єктів (наприклад, Redis або Memcached), щоб зменшити запити до бази даних. Field Forge виграє від кешування об’єктів, оскільки визначення груп полів кешуються після першого завантаження.

Конфлікт з ACF (обидва активні)

Симптоми: Дивна поведінка, дублікати метабоксів, поля, що показують значення з неправильного плагіна, або помилки PHP, що згадують про повторне оголошення функцій. Можливі причини та рішення:

Деактивуйте один плагін. Використання ACF та Field Forge одночасно призначене лише під час міграції. Після міграції деактивуйте ACF. Field Forge надає всі ті ж функції, тому код вашої теми продовжує працювати.
Конфлікт функцій. Якщо обидва плагіни намагаються зареєструвати get_field(), PHP викидає фатальну помилку про дублікати оголошень функцій. Поточні версії Field Forge відсилають до ACF, коли ACF активний або активується через інструменти адміністратора/плагінів WordPress, тому ACF Pro можна активувати для міграції без виникнення фатальної помилки повторного оголошення get_field(). Якщо ви все ще бачите цю помилку, спочатку оновіть Field Forge, перезавантажте плагіни та знову активуйте ACF.
Резервна сторінка параметрів під час міграції. Якщо ACF активний і повертає порожнє значення параметра, тоді як Field Forge має специфічне для мови значення параметра, Field Forge постачає це значення через фільтр завантаження значень ACF. Цей вузький міст підтримує узгодженість запитів сторінки параметрів, обізнаних про LangForge, під час міграції; це не робить довгострокову двосторонню роботу ACF/Field Forge рекомендованою конфігурацією.
Подвійні метабокси. Якщо ви бачите два набори однакових полів у пості, один з ACF і один з Field Forge, це означає, що обидва плагіни мають відповідні групи полів та правила розташування. Деактивуйте ACF, щоб усунути дублікати.

Значення полів втрачаються після зміни теми

Симптоми: Після переходу на нову тему дані користувацьких полів зникають на фронтенді. Можливі причини та рішення:

Шаблони теми не були оновлені. Дані полів все ще знаходяться в базі даних — вони не зникають при зміні теми. Проблема в тому, що нова тема не містить код шаблону (get_field(), the_field(), тощо) для їх відображення. Попросіть вашого розробника додати код виводу полів до шаблонів нової теми.
Змінився шлях до Local JSON. Якщо ви використовували Local JSON Sync, файли JSON знаходилися в папці старої теми. Скопіюйте директорію fieldforge-json/ зі старої теми до нової, або переналаштуйте шлях до Local JSON у Field Forge > Налаштування.
Групи полів не пошкоджені. Перейдіть до Field Forge > Групи полів, щоб підтвердити, що всі ваші групи полів все ще існують. Вони зберігаються в базі даних, а не в темі, тому вони зберігаються при зміні теми.

Помилки генерації TypeScript

Симптоми: Функція генерації TypeScript виробляє неправильні типи, викликає помилки або виводить порожні файли. Можливі причини та виправлення:

Необхідна ліцензія PRO. Генерація TypeScript є функцією PRO. Перевірте, що ваша ліцензія активна.
Не визначено груп полів. Інтерфейси TypeScript генеруються з ваших визначень груп полів. Якщо у вас немає груп полів, вихід буде порожнім.
Непідтримувані типи полів у користувацьких плагінах. Якщо ви зареєстрували користувацькі типи полів через плагін, генератор TypeScript може не знати, як їх відобразити. Перевірте згенерований вихід на наявність типів any і додайте користувацькі відображення типів, використовуючи фільтр fieldforge/typescript/type_map.
Права на запис файлів. Якщо файл виходу не може бути записаний, перевірте, чи має цільовий каталог права на запис для веб-сервера.

Збої імпорту/експорту

Симптоми: Імпорт JSON-файлу не вдається, або експортований файл порожній чи пошкоджений. Можливі причини та рішення:

Неправильний формат JSON. Якщо ви вручну редагували JSON-файл експорту, синтаксична помилка (відсутня кома, зайва дужка) призведе до невдачі імпорту. Використовуйте валідатор JSON (наприклад, jsonlint.com), щоб перевірити файл перед імпортом.
Файл занадто великий. Дуже великі експорти (сотні груп полів) можуть перевищувати обмеження upload_max_filesize або post_max_size PHP. Збільшіть ці значення у вашій конфігурації PHP або розділіть експорт на менші файли.
Невідомі або неправильно сформовані визначення полів. Field Forge відхиляє імпорти, які містять невідомий тип поля, неправильно сформовані підполя, неправильно сформовані макети Гнучкого Контенту або недійсні правила розташування. Оновіть обидва сайти до останньої версії Field Forge та експортуйте JSON знову з вихідного сайту замість ручного редагування цих секцій.
Несумісність версій. Імпорт файлу, експортованого з новішої версії Field Forge в старішу версію, може не вдасться, якщо новіша версія додала типи полів або налаштування, які старіша версія не розпізнає. Оновіть Field Forge до останньої версії перед імпортом.
Проблеми з правами доступу. Веб-серверу потрібен доступ на запис до каталогу uploads для обробки тимчасових файлів під час імпорту. Перевірте права доступу до папки.
Дублікати ключів полів. Якщо імпорт містить ключі полів, які вже існують у вашій базі даних, Field Forge відображає повідомлення про конфлікт. Виберіть, щоб перезаписати існуючі групи або пропустити дублікати.