Випадок із життя: чому Elementor “падає” при збереженні шаблонів (і як це виправити)

Під час роботи з кількома сайтами на WordPress, зокрема на VPS-сервері, я зіткнувся з на перший погляд загадковою проблемою: на сайтах які ми підтримуємо daranener.shop та daranener.biz, які працюють на WordPress з Elementor, неможливо було зберегти шаблон — одразу з’являлась помилка “There has been a critical error on this website…”, а в логах фігурував Fatal error: Argument #2 ($post) must be of type WP_Post, null given.

У цій статті я розповім:

• як виявити справжню причину цієї помилки,
• чому це не має нічого спільного з Elementor чи хостингом,
• та як буквально в 2 SQL-команди повернути сайт до життя.

Симптоми проблеми

Все почалось із невеликого завдання: потрібно було експортувати шаблон сторінки з Elementor. На одному сайті (розміщеному на хостингу) все працювало чудово, а на іншому (на VPS) — при спробі зберегти шаблон я отримував фатальну помилку. Також не вдавалося створити новий запис у розділі “Записи” — одразу падіння з “Critical Error”.

Сторінки Elementor, які вже існували, відкривалися і навіть редагувалися. Але нові шаблони створити було неможливо.

Перевірка логів: розкривається суть

Першою підказкою стало повідомлення в debug.log:

Fatal error: Uncaught TypeError: Elementor\TemplateLibrary\Source_Local::on_save_post(): 
Argument #2 ($post) must be of type WP_Post, null given

Fatal error: Uncaught TypeError: Elementor\TemplateLibrary\Source_Local::on_save_post(): 
Argument #2 ($post) must be of type WP_Post, null given

Це означає, що при спробі створити новий шаблон Elementor намагається викликати функцію on_save_post(), передаючи туди об’єкт $post, але… його не існує — тобто WordPress не створює запис в базі, або створює некоректно.

З цього моменту стало зрозуміло: проблема не в Elementor, не в правах доступу, не в клоні шаблону, а — в базі даних.

Пошук причини: база роздута і несправна

Оскільки перед цим я робив резервні копії всіх сайтів, я помітив, що .sql дампи двох маленьких інформаційних сайтів займають по 130+ мегабайт кожен. Це вже сигнал до перевірки.

Виконуючи SQL-запит:

SELECT table_name, round(data_length/1024/1024, 2) as size_mb 
FROM information_schema.tables 
WHERE table_schema = 'daranener-shop' 
ORDER BY size_mb DESC;

SELECT table_name, round(data_length/1024/1024, 2) as size_mb 
FROM information_schema.tables 
WHERE table_schema = 'daranener-shop' 
ORDER BY size_mb DESC;

я побачив, що таблиця wp_actionscheduler_logs займає понад 112 МБ! А разом з wp_postmeta та wp_posts база ставала непомірно великою для сайту з 15–20 сторінками.

Після очищення wp_actionscheduler_logs:

DELETE FROM wp_actionscheduler_logs;

DELETE FROM wp_actionscheduler_logs;

і ще кількох технічних таблиць (mailpoet, statistics, yoast) — база суттєво схудла. Але головна проблема залишалась — створення постів не працювало.

Порівняння сайтів: знайшлась причина

Для діагностики я порівняв сайт із проблемою з іншим, також на VPS, де все працювало. Обидва WordPress, обидва з Elementor, обидва на Apache + MariaDB.

Єдина реальна різниця — в структурі таблиць wp_posts та wp_users.

Ось як виглядала таблиця wp_posts на зламаному сайті:

CREATE TABLE `wp_posts` (
  `ID` bigint(20) unsigned NOT NULL,
  ...
  PRIMARY KEY (`ID`)
)

CREATE TABLE `wp_posts` (
  `ID` bigint(20) unsigned NOT NULL,
  ...
  PRIMARY KEY (`ID`)
)

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

Іншими словами: wp_posts.ID не був AUTO_INCREMENT.

Виправлення: проста SQL-команда — і все працює

Вирішення проблеми:

ALTER TABLE wp_posts
MODIFY COLUMN ID BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT;

ALTER TABLE wp_posts
MODIFY COLUMN ID BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT;

А якщо первинного ключа (PRIMARY KEY) нема (або змінено некоректно), спершу виконай:

ALTER TABLE wp_posts
MODIFY COLUMN ID BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
ADD PRIMARY KEY (ID);

ALTER TABLE wp_posts
MODIFY COLUMN ID BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
ADD PRIMARY KEY (ID);

Аналогічно для wp_users:

ALTER TABLE wp_users
MODIFY COLUMN ID BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT;

ALTER TABLE wp_users
MODIFY COLUMN ID BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT;

Після цього:

• можна знову створювати записи,
• Elementor успішно зберігає шаблони,
• WordPress поводиться повністю стабільно.

Як так вийшло?

Це могло статись з кількох причин:

• ручна зміна структури бази без врахування автоінкрементів;
• некоректний експорт/імпорт через phpMyAdmin чи mysqldump, де AUTO_INCREMENT не включили;
• резервне копіювання через сторонні плагіни, які не зберігають метаінформацію про стовпці;
• очищення бази вручну, яке “збило” індекси чи автоінкременти.

Висновки та поради

🔹 Якщо у вас WordPress “падає” при створенні записів або Elementor не дозволяє зберегти шаблони — першим ділом перевірте таблиці wp_posts та wp_users на наявність AUTO_INCREMENT.

🔹 Це особливо важливо після переносу сайтів, імпорту баз даних, або очищення великих логів вручну.

🔹 Перевірка:

SHOW CREATE TABLE wp_posts\G
SHOW CREATE TABLE wp_users\G

SHOW CREATE TABLE wp_posts\G
SHOW CREATE TABLE wp_users\G

🔹 Якщо бачите ID BIGINT(20) UNSIGNED NOT NULL без AUTO_INCREMENT, то WordPress буде “німіти” при кожній спробі створити новий запис.

Заключне слово

Цей випадок змусив мене глибше зануритись у структуру WordPress-бази і згадати, що іноді проблема не в плагінах, не в правах доступу, не в PHP-версії чи хостингу — а в простій технічній деталі, про яку легко забути: автоінкрементному ключі ID.

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

🔧 Автор: Ra Web Studio – Віталій Радчук
📅 Досвід: VPS, WordPress, Elementor, MariaDB
🔗 https://raweb.net/