Плагін не встановлюється, завантаження теми обривається на середині? В адмінці з’являється «Allowed memory size exhausted»? Найчастіше винен один файл, php.ini.

Це головний конфіг PHP: він задає, скільки пам’яті виділяти скриптам, як довго їх виконувати та файли якого розміру приймати. На типовому хостингу ці ліміти занижені, хостер економить ресурси.

Далі, де знайти php.ini в будь-якому середовищі (WAMP, XAMPP, Linux, cPanel) та які п’ять директив правити під WordPress на 2026 рік. З конкретними цифрами, без ворожіння.

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

• Створюєте тестовий PHP-файл із функцією phpinfo і одразу бачите шлях до php.ini на будь-якому сервері
• У WAMP, XAMPP і cPanel шлях доступний через інтерфейс, без правки коду
• Ключові налаштування для WordPress: memory_limit, max_execution_time, upload_max_filesize, post_max_size та max_input_vars
• Після правок перевіряєте фактичні ліміти через phpinfo() або WP-CLI, щоб переконатися, що хостинг не проігнорував зміни

Що таке php.ini і навіщо його чіпати

php.ini — це текстовий файл із директивами, які керують поведінкою PHP на сервері. Він завантажується під час кожного запуску PHP-процесу та визначає ліміти: пам’ять, час виконання, розмір файлів для завантаження, рівень помилок.

Для WordPress критичні п’ять директив. memory_limit виділяє оперативну пам’ять на обробку сторінки, сучасні теми та конструктори (Gutenberg, Elementor) легко потребують 256 МБ і вище. max_execution_time обмежує секунди на виконання скрипту: якщо плагін імпортує демо-контент або WooCommerce генерує звіти, 30 секунд за замовчуванням — це гарантований обрив. upload_max_filesize і post_max_size керують завантаженням: тема в ZIP може важити 40+ МБ, а ліміт хостингу, 2 МБ. Нарешті, max_input_vars обмежує кількість POST-змінних, і за 1000 пунктів меню та 2000 значень за замовчуванням збереження меню обрізається без попередження.

Хороша новина: php.ini можна правити навіть на дешевому shared-хостингу. Погана: спочатку його потрібно знайти, а шлях залежить від операційної системи, панелі керування та способу встановлення PHP (модуль Apache, CGI/FastCGI, PHP-FPM).

Як знайти php.ini: універсальний метод через phpinfo()

Найнадійніший спосіб, що працює на будь-якому сервері,, створити тестовий PHP-файл із функцією phpinfo().

Створіть файл із будь-яким іменем і розширенням .php (наприклад, info.php) і помістіть у нього:

1
<?php phpinfo(); ?>

Завантажте файл у корінь сайту (через FTP, файловий менеджер хостингу або WP-CLI) і відкрийте в браузері: https://ваш-сайт.com/info.php.

На сторінці, що відкрилася, знайдіть рядок Loaded Configuration File — це і є повний шлях до активного php.ini. Якщо PHP працює як модуль Apache, шлях буде вказано в рядку Configuration File (php.ini) Path, у такому разі самого файлу може не існувати, і його потрібно створити вручну.

Після перевірки **обов’язково видаліть **info.php, він розкриває деталі серверної конфігурації, що небезпечно.

Де знаходиться php.ini у WAMP

У WAMP (Windows-збірка: Apache + MySQL + PHP) шлях до php.ini доступний прямо із системного трею.

Клацніть правою кнопкою по значку WAMP, наведіть на PHP і виберіть php.ini, файл відкриється в текстовому редакторі. Якщо у збірці кілька версій PHP, переконайтеся, що вибрано ту, з якою працює сайт (видно в треї: WAMP → PHP → Version).

Альтернативний шлях, через меню WAMP: лівий клік по значку → PHP → php.ini. Файл фізично лежить у папці C:\wamp64\bin\php\phpX.Y.Z\php.ini (або C:\wamp\bin\... для старих версій).

Де знаходиться php.ini у XAMPP

У XAMPP на Windows і Linux шлях до php.ini, через панель керування (Control Panel). Відкрийте XAMPP Control Panel і натисніть кнопку Config у рядку модуля Apache. У випадному меню виберіть PHP (php.ini), файл відкриється в редакторі.

Якщо кнопки Config немає (стара версія XAMPP), ідіть прямим шляхом: C:\xampp\php\php.ini на Windows або /opt/lampp/etc/php.ini на Linux.

Після правок перезапустіть Apache кнопкою Stop → Start на панелі керування.

Де знаходиться php.ini у Linux (VPS / dedicated)

На Linux-сервері без панелі керування php.ini шукається однією командою в терміналі:

1
php -i | grep "Loaded Configuration File"

Вивід буде приблизно таким:

1
Loaded Configuration File => /etc/php/8.2/cli/php.ini

Важливий нюанс: PHP для командного рядка (CLI) та для вебсервера (Apache/Nginx) часто використовують різні php.ini. Команда вище показує шлях для CLI-версії. Щоб дізнатися шлях для вебсервера, створіть info.php методом із попереднього розділу та відкрийте в браузері або виконайте:

1
ls /etc/php/*/apache2/php.ini
2
ls /etc/php/*/fpm/php.ini

Типові розташування залежать від версії PHP та вебсервера:

• Apache: /etc/php/8.2/apache2/php.ini
• PHP-FPM (Nginx): /etc/php/8.2/fpm/php.ini
• Загальний шлях (якщо PHP зібрано вручну): /usr/local/lib/php.ini

Після правок перезапустіть вебсервер: sudo systemctl restart apache2 або sudo systemctl restart php8.2-fpm.

Де знаходиться php.ini у cPanel та інших панелях хостингу

На shared-хостингу з cPanel файл php.ini зазвичай лежить у кореневій директорії сайту, public_html. Щоб його побачити:

• Увійдіть у cPanel і відкрийте File Manager
• Перейдіть до папки public_html
• Знайдіть php.ini у списку файлів

Якщо файлу немає, створіть його кнопкою + File. Пропишіть потрібні директиви та збережіть. Хостинг підхопить налаштування протягом кількох хвилин.

На сучасних хостингах дедалі частіше трапляється MultiPHP Manager (cPanel) або Select PHP Version, вони дають змогу правити php.ini через вебінтерфейс, не заходячи до файлового менеджера. Якщо ваша панель підтримує такий інструмент, використовуйте його: менше шансів помилитися із синтаксисом.

Окремий випадок, .user.ini. На хостингах із PHP-FPM (FastCGI) php.ini у корені сайту може ігноруватися; замість нього створюється файл .user.ini із тими самими директивами. Уточніть у документації хостингу, який файл використовувати.

Рекомендовані налаштування php.ini для WordPress (актуально на 2026)

Базові значення «за замовчуванням» у php.ini не змінювалися десятиліттями й розраховані на прості скрипти, а не на сучасні CMS. WordPress з актуальними плагінами потребує значно більших лімітів. Нижче рекомендовані значення, перевірені на практиці.

Основні директиви

1
memory_limit = 512M
2
max_execution_time = 300
3
upload_max_filesize = 128M
4
post_max_size = 128M
5
max_input_vars = 4000
6
max_input_time = 300
7
file_uploads = On

Директива safe_mode видалена з PHP починаючи з версії 5.4, не додавайте її до конфігурації. Якщо бачите цей рядок у старому php.ini, сміливо видаляйте.

Кешування (opcache)

Для production-сайту обов'язково увімкніть opcache — це дає приріст швидкості у 2-3 рази за рахунок кешування скомпільованого байт-коду:

1
opcache.enable = 1
2
opcache.memory_consumption = 256
3
opcache.max_accelerated_files = 10000
4
opcache.revalidate_freq = 2
5
opcache.validate_timestamps = 1

Логування помилок

На робочому сайті виведення помилок на екран має бути вимкнене, але логування, увімкнене:

1
display_errors = Off
2
log_errors = On
3
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

Альтернативні способи:.htaccess і wp-config.php

Не завжди є доступ до php.ini. На деяких хостингах працюють обхідні шляхи.

Через.htaccess (Apache + mod_php)

Додайте в .htaccess у корені сайту:

1
php_value memory_limit 512M
2
php_value upload_max_filesize 128M
3
php_value post_max_size 128M
4
php_value max_execution_time 300

Спрацює тільки якщо PHP працює як модуль Apache (mod_php). У разі PHP-FPM директиви php_value викличуть помилку 500, тоді використовуйте .user.ini.

Через wp-config.php

Додайте перед рядком /* That's all, stop editing! */:

1
define('WP_MEMORY_LIMIT', '512M');
2
define('WP_MAX_MEMORY_LIMIT', '512M');

WP_MEMORY_LIMIT задає ліміт для фронту, WP_MAX_MEMORY_LIMIT для адмінки. Це не замінює php.ini, але часто вирішує проблему «Allowed memory size exhausted» точково, коли доступ до серверної конфігурації обмежений.

Відео: пошук і редагування php.ini на практиці

Коротке відео з візуальною демонстрацією всіх описаних методів, від phpinfo() до MultiPHP Manager у cPanel:

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

Чому після редагування php.ini нічого не змінилося?

PHP-процес не перезапустився. Перезавантажте Apache (systemctl restart apache2 або кнопкою в панелі), PHP-FPM (systemctl restart phpX.Y-fpm) або зачекайте на автоматичний перезапуск на shared-хостингу (зазвичай 2-5 хвилин). Перевірте, що ви редагуєте саме той php.ini, який показує phpinfo() у рядку Loaded Configuration File (на одному сервері їх може бути кілька).

Після редагування завжди перевіряйте фактичний ліміт через phpinfo(): хостинг може перевизначати деякі директиви глобальними налаштуваннями. Якщо значення не змінилося, створіть .user.ini у корені сайту (для PHP-FPM) або зв'яжіться з підтримкою.

Який memory_limit реально потрібен WordPress у 2026 році?

256M: безпечний мінімум для типового сайту з 10-15 плагінами. Якщо встановлено конструктор сторінок (Elementor, Bricks, Breakdance), WooCommerce або комплексний плагін кешування, ставте 512M. Сайти на Gutenberg з великою кількістю блоків і патернів теж тяжіють до 512M. 128M, рекомендовані в старих посібниках, для сучасного WordPress уже недостатні: саме ядро з темою на Full Site Editing може впертися в цей ліміт.

Виняток: дешевий shared-хостинг із жорсткою стелею. Якщо хостер не дає підняти memory_limit вище 128M, подумайте про зміну тарифу або хостингу: сайт на такому ліміті падатиме при кожному другому оновленні.

Що важливіше: редагувати php.ini чи wp-config.php?

php.ini працює на системному рівні, wp-config.php на рівні застосунку. Якщо є доступ до php.ini, редагуйте його: ліміти діятимуть глобально і не скинуться під час оновлення ядра. wp-config.php використовуйте як fallback, коли хостинг заблокував php.ini. WP_MEMORY_LIMIT у wp-config.php перевизначає memory_limit з php.ini для WordPress, але не впливає на max_execution_time, upload_max_filesize та інші директиви: їх доведеться редагувати через .htaccess або .user.ini.