Якщо WordPress не завантажує зображення, у медіабібліотеці може з’являтися повідомлення про помилку, файл може завантажуватися без мініатюри, а під час додавання зображення сторінка може зависати. Причина не завжди пов’язана із самим файлом: проблема може виникнути через права доступу до папки, обмеження PHP, конфлікт плагінів, неправильний шлях до uploads або наслідки перенесення сайту.
Перед зміною системних файлів, налаштувань сервера чи бази даних бажано створити резервну копію сайту та бази даних. Якщо доступ до панелі керування обмежений або сайт містить важливі матеріали, безпечніше спочатку провести діагностику, а не видаляти файли навмання.
Права папки uploads
WordPress зберігає завантажені зображення в каталозі wp-content/uploads. Вебсервер повинен мати право записувати файли в цю папку та її підкаталоги. Якщо права змінено після перенесення сайту, відновлення з резервної копії або оновлення хостингу, завантаження може завершуватися помилкою.
Перевірити потрібно:
- чи існує папка
wp-content/uploads; - чи належить вона правильному користувачу та групі на сервері;
- чи має вебсервер доступ на запис;
- чи не встановлено надто суворі або небезпечні права для каталогів і файлів;
- чи не блокують запис правила безпеки, SELinux або налаштування хостингу.
Зазвичай для каталогів використовують права на рівні 755, а для файлів — 644, але точні значення залежать від конфігурації сервера. Не варто встановлювати права 777 як універсальне рішення: це може створити додаткову вразливість і не усунути першопричину.
Якщо після зміни прав зображення почали завантажуватися, перевірте також створення мініатюр. Коли оригінальний файл записується, але мініатюри не генеруються, проблема може стосуватися бібліотек обробки зображень або ресурсів PHP.
Ліміти PHP
Великі зображення або файли, що обробляються в кількох розмірах, можуть перевищувати ліміти PHP. У результаті WordPress показує помилку завантаження, обриває процес або повертає загальне повідомлення без зрозумілого пояснення.
Потрібно перевірити такі параметри:
uploadmaxfilesize— максимально допустимий розмір одного файлу;postmaxsize— розмір усього POST-запиту, який має бути не меншим заuploadmaxfilesize;memory_limit— доступний PHP обсяг пам’яті;maxexecutiontime— час виконання операції;maxinputtime— час обробки вхідних даних.
Поточні значення частково можна побачити в адміністративній панелі WordPress у розділі стану сайту. Якщо доступу недостатньо, параметри перевіряють у панелі хостингу, конфігурації PHP або через технічну підтримку провайдера. Спосіб зміни залежить від сервера: це можуть бути налаштування PHP-FPM, php.ini, конфігурація хостингу або правила вебсервера.
Після збільшення лімітів не слід одразу завантажувати десятки великих файлів. Спочатку перевірте один невеликий файл, потім зображення більшого розміру. Якщо помилка виникає лише з конкретними файлами, варто перевірити їхній формат, пошкодження, колірний профіль і фактичний розмір.
Конфлікт оптимізатора
Плагіни оптимізації зображень, кешування, WebP-конвертації, захисту та медіаменеджменту можуть змінювати процес завантаження або створення мініатюр. Після оновлення одного з таких компонентів медіабібліотека іноді перестає працювати, хоча сам WordPress і файли сайту залишаються доступними.
Ознаками конфлікту можуть бути:
- помилка з’явилася одразу після оновлення плагіна або теми;
- звичайні файли завантажуються, а WebP, SVG чи великі зображення — ні;
- помилка виникає лише в одному браузері або під час роботи через певний CDN;
- у журналі помилок згадуються конкретний плагін, AJAX-запит або нестача пам’яті;
- після вимкнення оптимізації проблема тимчасово зникає.
Для перевірки спочатку створіть резервну копію, а потім тимчасово вимкніть плагіни, які працюють із медіафайлами, кешем або безпекою. Перевірку краще проводити в режимі обслуговування або на тестовій копії, щоб відвідувачі не побачили незавершені зміни. Якщо конфлікт підтвердився, потрібно оновити компоненти, змінити їхні налаштування або знайти сумісну альтернативу, а не залишати захисні плагіни вимкненими без контролю.
Для технічної перевірки та безпечного усунення подібних проблем можна звернутися по Підтримка сайтів на WordPress.
Шлях до медіафайлів
WordPress може не знаходити зображення, якщо в налаштуваннях, базі даних або конфігурації сервера залишився старий шлях до файлів. Це часто трапляється після зміни домену, перенесення сайту на інший хостинг, зміни структури каталогів або відновлення неповної резервної копії.
Перевірте, чи збігаються:
- адреса сайту та адреса WordPress у загальних налаштуваннях;
- фізичний шлях до каталогу
wp-content/uploadsна сервері; - URL, які використовуються в записах медіабібліотеки;
- налаштування CDN або проксі-сервера;
- правила перенаправлення в
.htaccessчи конфігурації Nginx.
Якщо домен або протокол змінювалися, у базі даних можуть залишитися посилання на старий домен. Масова заміна адрес без підготовки небезпечна: некоректно виконана операція здатна пошкодити серіалізовані дані або змінити посилання в непотрібних полях. Перед такими діями обов’язково зробіть копію бази даних і використовуйте інструмент, який коректно обробляє дані WordPress.
Окремо перевірте, чи не блокує сервер запити до файлів через правила доступу, hotlink-захист, CDN або плагін безпеки. Якщо файл фізично є на сервері, але відкривається з кодом 403 або 404, проблема може бути не в медіабібліотеці, а в маршрутизації чи дозволах вебсервера.
Відновлення відсутніх зображень
Якщо записи в медіабібліотеці залишилися, але самих файлів у uploads немає, WordPress не зможе відновити їх простим оновленням сторінки. Спочатку визначте масштаб проблеми: перевірте кілька URL зображень, структуру папок за роками й місяцями та наявність оригіналів і мініатюр.
Безпечна послідовність дій:
- Зробіть резервну копію поточного стану файлів і бази даних, навіть якщо частина зображень уже відсутня.
- Перевірте резервні копії хостингу, архіви сайту та окремі копії каталогу
wp-content/uploads. - З’ясуйте, чи не були файли переміщені в інший каталог або на CDN.
- Якщо копія доступна, відновлюйте спочатку окремі файли або каталог на тестовому середовищі.
- Після повернення оригіналів перевірте посилання та за потреби відновіть мініатюри.
Відновлення лише записів у базі даних не повертає фізичні файли. Так само повторне генерування мініатюр не допоможе, якщо відсутні оригінальні зображення. Не видаляйте записи медіабібліотеки або весь каталог uploads, щоб «почати з нуля»: це може ускладнити відновлення й призвести до остаточної втрати доступних даних.
Спеціаліст потрібен, якщо одночасно зникли файли та записи, резервна копія неповна, сайт було заражено, після перенесення змінилися шляхи або помилка супроводжується проблемами з базою даних. У таких випадках спочатку проводять діагностику, зберігають поточний стан сайту й лише потім визначають реалістичний спосіб відновлення.