Проблеми мініатюр у WordPress: як відновити ескізи без простою сайту

Що насправді зламано (а що ні)

«Мініатюри зламані» — це симптом, а не діагноз. Рендеринг зображень в WordPress — це конвеєр: завантажити оригінал → згенерувати проміжні розміри → зберегти метадані в базі → віддати потрібний файл через тему й srcset → опційно переписати через CDN/плагін offload → опційно кешувати на кількох рівнях.

Поширені режими відмов мініатюр

• Відсутні проміжні файли: змінені файли не були згенеровані, були видалені або тепер знаходяться в іншому сховищі.
• Неправильні шляхи/URL: база даних вказує на один шаблон URL, файлове сховище має інший, або переписування CDN сконфігуровано неправильно.
• Невідповідність метаданих: проміжні файли існують, але wp_postmeta містить застарілі розміри або старі виміри.
• Права/власність: WordPress може читати оригінали, але не може записати нові розміри в wp-content/uploads.
• Збої обробки зображень: помилки ImageMagick/GD, обмеження пам’яті, політики безпеки або таймаути під навантаженням.
• Кеш бреше: мініатюри виправлено, але користувачі все ще бачать старі 404 або застарілий HTML із старим srcset.

Перегенерація ескізів усуває лише одну категорію: відсутні/проміжні розміри + невідповідність метаданих. Вона не вирішує поламаний CDN-rewrite, неправильний блок Nginx або політику S3-бакета, що забороняє читання.

Одна перефразована ідея, яку часто приписують спеціалістам з надійності систем на кшталт Werner Vogels, підходить сюди: Перефразована ідея: Все ламається; спроектуйте так, щоб відновлення було рутинним, а не героїчним актом. Це саме та позиція, якої ви прагнете: рутинна, обмежена, спостережувана перегенерація.

Швидкий план діагностики

Якщо у вас є тільки 10 хвилин до початку «штабу», зробіть це в такому порядку. Ви шукаєте вузьке місце: сховище, CPU, PHP-воркери або кеш/CDN.

1) Підтвердіть, що саме ламається: 404, неправильний розмір або помилка обробки

• Якщо браузер показує 404 для файлів з resized-іменами (наприклад, image-300x200.jpg), ймовірно потрібна перегенерація або вирівнювання файлової системи/offload.
• Якщо ви бачите 200 OK, але зображення спотворене/неправильно обрізане, зазвичай це застарілі метадані або тема запитує розмір, який не існує.
• Якщо завантаження в адмінці не вдається або перегенерація кидає помилки, зазвичай це ImageMagick/GD, обмеження пам’яті PHP або права.

2) Перевірте форму навантаження сервера: CPU vs I/O vs насичення PHP-FPM

• Високий CPU: обробка зображень — це справжня робота; виправляйте пакетування й вибір інструменту (ImageMagick vs GD) та ліміти.
• Високий disk I/O wait: сховище — вузьке місце; сильніше обмежуйте, перемістіть тимчасові теки або перегенеруйте поза хостом.
• PHP-FPM вичерпано: ваша перегенерація відбирає воркери у живого трафіку; ізолюйте її (CLI-користувач, окремий пул або вікно cron).

3) Перевірте бекенд сховища та переписування URL

• Якщо ви виносите в S3-сумісне сховище, підтвердіть, що проміжні розміри там зберігаються й віддаються, а не лише оригінали.
• Якщо ви використовуєте CDN, підтвердіть, що він не кешує 404 відповіді для змінених файлів.

Потім оберіть найменш ризикове виправлення: перегенеруйте контрольованими пакетами, прогрійте кеші та очищуйте лише те, що потрібно. Простой призначений для міграцій баз даних і екзистенційного страху, а не для ескізів.

Цікаві факти та історичний контекст

Короткі, конкретні факти, які пояснюють, чому мініатюри WordPress іноді нагадують зіпсований копіювальний апарат:

1. WordPress зберігає метадані розмірів зображень для кожного вкладення в wp_postmeta (бінарний блок _wp_attachment_metadata), тож «пофіксувати файли» без оновлення метаданих може означати, що srcset все ще неправильний.
2. Проміжні розміри називаються за конвенцією (наприклад, -300x200), що полегшує діагностику 404 — але також робить пропуски кешу CDN дуже «липкими».
3. Історично багато хостів компілювали PHP лише з GD, тож відтворення зображень на деяких сайтах може змінитися, коли з’явиться ImageMagick (різкість, кольорові профілі, обробка альфа).
4. Відповідні зображення WordPress (srcset) з’явилися в ядрі пізніше, ніж теми навчилися «захардкоджених розмірів», тож застарілі теми часто запитують розміри, які не відповідають зареєстрованим.
5. Орієнтація EXIF часто створює біль: телефони зберігають поворот у метаданих; деякі процесори застосовують його по-різному, тож перегенеровані зображення можуть «перевернутися» порівняно зі старими.
6. Плагіни для виносу в об’єктне сховище змінили поняття «файл існує», бо правда тепер розділена між локальним диском, віддалим бакетом і правилами переписування в базі.
7. Деякі CDN за замовчуванням кешують 404и; після перегенерації користувачі продовжуватимуть бачити відсутні зображення, поки ви не очистите негативні кеш-записи.
8. ImageMagick має історію питань безпеки (конфігурації policy.xml — поширена річ), тож хости часто поставляють його з консервативними лімітами, що ламають великі зображення при перегенерації.
9. WordPress може створювати кілька розмірів при завантаженні, тож одна «проста» перегенерація може примножити записи на диску, особливо з ретина-версіями та додатковими розмірами з плагінів.

Виберіть підхід до перегенерації (і радіус ураження)

Варіант A: перегенерація через WP-CLI (рекомендується для продакшну)

WP-CLI нудний у найкращому значенні: його легко скриптувати, пакетувати й запускати під користувачем з низьким пріоритетом і суворими лімітами. Також його легше спостерігати і зупиняти.

Використовуйте, коли: у вас є доступ до shell, ви можете планувати поза піковими годинами і хочете відтворюваний робочий процес.

Варіант B: плагіни в адмінці WordPress (припустимо для невеликих сайтів)

Плагіни для перегенерації ескізів з адмінки підходять, поки не починають підводити. Вони працюють в тих самих PHP-FPM воркерах, що й користувачі, і більш чутливі до таймаутів. Їх важче точно обмежити.

Використовуйте, коли: медіа-бібліотека невелика, трафік низький і немає доступу до shell.

Варіант C: фонова черга завдань (найкраще для високого масштабу, мульти-хост)

Якщо ви експлуатуєте WordPress як реальний додаток — з воркерами, чергами та окремими пулами — генерація ескізів має належати туди. Ви можете лімітувати, повторювати і зберігати латентність веб-відповідей чистою.

Використовуйте, коли: у вас кілька ап-серверів, високий трафік і ви вже маєте воркерів у продакшні.

Чого слід уникати

• Перегенерації всього відразу на одному хості посеред дня.
• Бездумного очищення всього кешу CDN «на всяк випадок». Це — самонанесений DDoS по вашому оригіну.
• Зміни розмірів зображень і перегенерації до перевірки використання в темі. Ви створите гігабайти розмірів, яких ніхто не запитує.

Жарт №1: Перегенерація ескізів схожа на похід у спортзал — надто інтенсивне перше тренування лише доведе, що ви ще можете відчувати біль.

Практичні завдання з командами: що виконати, що означає вивід, що робити далі

Це безпечні для продакшну дії, які можна виконувати без простою сайту. Мета — виміряти, вирішити і рухатися далі контрольованими кроками. Припущення: типовий Linux-хост з WordPress у /var/www/html. Підлаштуйте шляхи під свій випадок.

Завдання 1: Підтвердіть, що WordPress бачить папку uploads правильно

cr0x@server:~$ cd /var/www/html && wp option get upload_path
...output...

Що означає вивід: Порожній вивід зазвичай означає значення за замовчуванням (wp-content/uploads). Непорожній — означає, що WordPress використовує кастомний шлях.

Рішення: Якщо шлях кастомний, перевірте, чи існує він і чи доступний для запису; перегенерація використовуватиме саме його.

Завдання 2: Перевірте активний редактор зображень (ImageMagick vs GD)

cr0x@server:~$ cd /var/www/html && wp eval 'print_r(wp_get_image_editor("wp-content/uploads/".date("Y")."/".date("m")."/test.jpg"));'
...output...

Що означає вивід: Ви побачите об’єкт редактора (наприклад, Imagick) або помилку, якщо тестовий файл відсутній або обробка не вдається.

Рішення: Якщо Imagick дає помилки policy/resource, тимчасово перемкніться на GD або виправте ліміти ImageMagick перед масштабною перегенерацією.

Завдання 3: Перевірте вільне місце на диску перед тисячами файлів

cr0x@server:~$ df -h /var/www/html/wp-content/uploads
...output...

Що означає вивід: Важлива вільна область і тип файлової системи. Мало місця — перегенерація частково вдасться, а потім зламається й залишить безлад.

Рішення: Якщо місця мало — збільште диск, перегенеруйте на більшому томі або зменшіть генеровані розміри.

Завдання 4: Оцініть розмір uploads і кількість файлів (вплив на I/O)

cr0x@server:~$ du -sh /var/www/html/wp-content/uploads && find /var/www/html/wp-content/uploads -type f | wc -l
...output...

Що означає вивід: Загальний розмір + кількість файлів підкажуть, скільки часу займе скан/перегенерація і наскільки сильно ви вдарите по inode/cached-шарам.

Рішення: Величезна кількість файлів змушує вас пакетувати, працювати поза піком і продумувати кеш-стратегію.

Завдання 5: Визначте конкретний відсутній варіант ескізу з логів

cr0x@server:~$ sudo tail -n 50 /var/log/nginx/access.log
...output...

Що означає вивід: Шукайте GET /wp-content/uploads/...-300x200.jpg зі статусом 404 (або 403).

Рішення: Якщо 404и послідовно для певних розмірів — перевірте, чи ці розміри зареєстровані в WordPress і чи є вони в метаданих.

Завдання 6: Підтвердіть, що файл дійсно не існує на диску

cr0x@server:~$ ls -lah /var/www/html/wp-content/uploads/2025/11 | head
...output...

Що означає вивід: Якщо бачите оригінали, але не очікувані -WxH варіанти — ймовірно проблема генерації/метаданих.

Рішення: Перейдіть до перевірки метаданих і контрольованої перегенерації.

Завдання 7: Перегляньте метадані вкладення для відомого зламаного зображення

cr0x@server:~$ cd /var/www/html && wp post list --post_type=attachment --posts_per_page=5 --orderby=date --order=DESC
...output...

Що означає вивід: Отримаєте ID вкладень. Візьміть той, який показує зламані мініатюри.

Рішення: Використайте ID, щоб вивести метадані наступною командою.

cr0x@server:~$ cd /var/www/html && wp post meta get 12345 _wp_attachment_metadata
...output...

Що означає вивід: Ви побачите серіалізовані або JSON-подібні дані; всередині — записи sizes з іменами файлів і розмірами.

Рішення: Якщо метадані вказують на розміри, яких немає на диску — перегенерація виправдана. Якщо в метаданих немає розмірів — генерація, можливо, не вдалася спочатку.

Завдання 8: Подивіться, які розміри WordPress вважає необхідним генерувати

cr0x@server:~$ cd /var/www/html && wp eval 'global $_wp_additional_image_sizes; print_r(array_merge(get_intermediate_image_sizes(), array_keys((array)$_wp_additional_image_sizes)));'
...output...

Що означає вивід: Список імен розмірів: thumbnail, medium, large, плюс ті, що додали тема/плагіни.

Рішення: Якщо бачите довгий список кастомних розмірів, які ніхто не використовує, подумайте про їх вимкнення перед перегенерацією, щоб уникнути даремної роботи і росту сховища.

Завдання 9: Сухий прогін перегенерації для одного вкладення

cr0x@server:~$ cd /var/www/html && wp media regenerate 12345 --yes
...output...

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

Рішення: Якщо одне зображення падає — не запускайте масову перегенерацію. Виправте причину помилки спочатку; інакше ви лише створите довше інцидент.

Завдання 10: Запустіть масову перегенерацію обмеженими пакетами (захист продакшну)

Спочатку згенеруйте список ID вкладень і подайте їх частинами. Це дає кнопку «стоп» і робить прогрес вимірним.

cr0x@server:~$ cd /var/www/html && wp post list --post_type=attachment --field=ID --posts_per_page=1000 --orderby=ID --order=ASC > /tmp/attachment-ids.txt
...output...

Що означає вивід: Файл з ID. Відсутність виводу нормальна; перевірте розмір файлу, якщо сумніваєтесь.

Рішення: Якщо список гігантський — розбивайте на пакети протягом годин/днів з контролем пропускної здатності.

cr0x@server:~$ split -l 200 /tmp/attachment-ids.txt /tmp/ids-batch-
...output...

Що означає вивід: Створює файли на зразок /tmp/ids-batch-aa, кожен з 200 ID.

Рішення: Розмір пакета — це ручка регулювання. Менші пакети означають менший сплеск навантаження і легший відкат.

cr0x@server:~$ cd /var/www/html && time xargs -a /tmp/ids-batch-aa -n 1 wp media regenerate --yes
...output...

Що означає вивід: Ви побачите прогрес по кожному ID і реальний час виконання. Якщо це повільно, ваш вузький горлій, ймовірно, CPU або сховище.

Рішення: Якщо латентність стрибає або навантаження росте — робіть паузи між пакетами, зменшуйте розмір пакета або працюйте лише поза піками. Не будьте сміливими — будьте послідовними.

Завдання 11: Задайте пріоритет CPU і I/O для перегенерації

cr0x@server:~$ cd /var/www/html && sudo nice -n 15 sudo ionice -c2 -n7 xargs -a /tmp/ids-batch-ab -n 1 wp media regenerate --yes
...output...

Що означає вивід: Той самий вивід WP-CLI, але ОС знижує пріоритет процесу відносно веб-трафіку.

Рішення: Якщо ви ділили коробку з живим трафіком, використовуйте це за замовчуванням. Якщо маєте виділених воркерів — можна послабити обмеження.

Завдання 12: Слідкуйте за насиченням PHP-FPM під час перегенерації

cr0x@server:~$ sudo ss -s
...output...

Що означає вивід: Велика кількість встановлених з’єднань або стрибок у TCP-станах може вказувати на перевантаження. Паралельно стежте за FPM status, якщо ввімкнено.

Рішення: Якщо кількість з’єднань росте і час сторінок погіршується — жорсткіше лімітуйте перегенерацію або ізолюйте її на окремий хост/пул.

Завдання 13: Підтвердіть, що згенеровані файли існують і метадані оновлені

cr0x@server:~$ ls -lah /var/www/html/wp-content/uploads/2025/11 | grep -- '-300x' | head
...output...

Що означає вивід: Наявність нових змінених варіантів вказує, що генерація файлів пройшла успішно.

Рішення: Якщо файли є, але фронтенд все ще віддає старі URL — це питання кешу/HTML: очищуйте вибірково і переконайтеся, що srcset перебудовано.

cr0x@server:~$ cd /var/www/html && wp post meta get 12345 _wp_attachment_metadata | head
...output...

Що означає вивід: Ви маєте побачити оновлені записи розмірів. Якщо ні — перегенерація могла записати файли, але не змогла зберегти метадані.

Рішення: Перевірте права запису в базу, дивні об’єктні кеші або помилки у виводі WP-CLI.

Завдання 14: Підтвердіть, що HTTP-слой віддає згенерований файл (не кешований 404)

cr0x@server:~$ curl -I https://example.com/wp-content/uploads/2025/11/image-300x200.jpg
...output...

Що означає вивід: Важливі статус HTTP, заголовки кешу і, можливо, заголовок CDN із HIT/MISS.

Рішення: Якщо все ще 404, але файл існує на оригіні — ваш CDN або правила перепису обманюють. Очистьте конкретний шлях і перевірте оригін напряму.

Завдання 15: Швидко виявляйте помилки політики або пам’яті ImageMagick

cr0x@server:~$ cd /var/www/html && wp media regenerate 12345 --yes --debug
...output...

Що означає вивід: Дебаг-вивід часто показує базові помилки на кшталт «not authorized» (policy.xml) або вичерпання пам’яті.

Рішення: Якщо ImageMagick блокується політикою — виправте policy/ліміти або переключіться на GD; не продовжуйте бездумні повтори.

Завдання 16: Якщо використовується offload в об’єктне сховище, перевірте наявність мініатюр віддалено

cr0x@server:~$ aws s3 ls s3://my-media-bucket/wp-content/uploads/2025/11/ | head
...output...

Що означає вивід: Ви маєте бачити змінені варіанти поруч з оригіналами. Якщо видно лише оригінали — ваш плагін offload може не завантажувати проміжні розміри.

Рішення: Виправте конфігурацію offload і перезапустіть перегенерацію (або синхронізацію), щоб нові розміри теж були завантажені.

Жарт №2: Якщо ви запускаєте перегенерацію ескізів у п’ятницю ввечері — ви не ризикований, ви просто ентузіаст вихідних.

Три корпоративні міні-історії з полів мініатюр

1) Інцидент через хибне припущення

Сайт був маркетинговим WordPress з невеликим каталогом і багатьма лендінгами. Хтось змінив розміри зображень у темі «щоб прискорити». Команда припустила, що WordPress ліниво згенерує нові розміри при першому запиті. Так не працює: WordPress генерує проміжні розміри під час завантаження, а перегенерація — це цілеспрямована дія.

За кілька годин нова тема почала запитувати ім’я розміру, якого не було для старих медіа. HTML віддавав srcset, що вказував на -768x512 варіанти, яких ніколи не створили. CDN, як завжди добре виконуючи роботу, закешував купу 404 відповідей. Користувачі бачили не просто відсутні зображення — вони бачили їх постійно.

Першою реакцією була «очистити все». Це викликало натовповий прихід до оригіну, який уже був зайнятий спробою перегенерації через плагін в адмінці. PHP-FPM воркери тепер були розділені між реальними користувачами та обробкою зображень. Генерація сторінок сповільнилася, таймаути зросли, і проблема перетворилася з «медіа питання» в «аутейдж».

Виправлення було болісно непрезентабельним: зупинити плагінну перегенерацію, ідентифікувати відсутні розміри, перегенерувати пакетно через CLI з низьким пріоритетом, вибірково очистити негативні кеши, дочекатися природного прогрівання кешів. Висновок: помилкове припущення породило ланцюгову реакцію через CDN, оригін і пули PHP-воркерів.

2) Оптимізація, що відбилася бумерангом

Інша команда вирішила бути хитрою. Вони перенесли uploads на мережеве сховище, щоб усі ап-сервери читали ті самі файли. Обіцянка була «жодних rsync, жодного дрейфу». Це працювало для віддачі оригіналів. Перегенерація ескізів — інша історія.

Перегенерація — це інтенсивні записи й операції з метаданими. Кожне вкладення створює множинні записи, статистику й сканування директорій. NAS відчував себе добре при стабільних читаннях, але був завалений великою кількістю дрібних записів і операцій з метаданими. iowait різко підскочив, PHP-процеси накопичилися, і веб-шар почав поводитися так, наче перевантажений CPU, хоча винувате сховище.

Вони «оптимізували», збільшивши паралельність: запускали кілька процесів перегенерації паралельно. Це зробило NAS єдиним спільним вузьким місцем і перетворило повільну задачу на повільний інцидент. У той же час бекапи почали пропускати вікно через зайняте сховище.

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

3) Нудна, але правильна практика, що врятувала день

Ця історія не потрапила в резюме нікого, і саме тому вона спрацювала. Команда мала стійку практику: перед будь-якою зміною теми або плагіна, що обробляє медіа, вони запускали невеликий канарний прогін перегенерації на підмножині вкладень і фіксували час на зображення та пікове навантаження.

Коли вони мігрували з GD на ImageMagick (з метою якості), канар одразу виявив помилки на великих PNG через консервативні лиміти ImageMagick. Жодного впливу на клієнтів ще не було, бо зміни не зачепили продакшн-поведінку. Вони відрегулювали ліміти й пам’ять PHP у контрольованому вікні, повторили канар і лише потім рухалися далі.

Пізніше, коли був потрібен повний прогін після додавання нових розмірів для адаптивного дизайну, у них вже був відомий безпечний розмір пакета, відомий throttle і runbook з умовами зупинки. Запускали дві ночі з простим логом прогресу і без драм.

«Нудна» практика — виміряти спочатку й міняти по одному параметру — не вражає в демо, але запобігає каскадним відмовам, які перетворюють медіа-задачу на виклик до керівництва.

Чек-листи / покроковий план (без простою)

Крок 0: Визначте, що означає «виправлено»

• Чи відсутні мініатюри (404), неправильні (спотворені) чи застарілі (старе обрізання)?
• Проблема глобальна чи обмежена певними роками/місяцями в uploads?
• Чи задіяне об’єктне сховище/CDN?

Крок 1: Стабілізуйте продакшн перед початком перегенерації

• Заморозьте зміни теми і плагінів до завершення перегенерації.
• Якщо сайт вже деградував, спочатку зупиніть будь-які плагінні перегенерації в адмінці.
• Підтвердіть наявність запасу дискового простору і робочі бекапи бази + манифест uploads.

Крок 2: Канарна перегенерація

1. Виберіть 10 вкладень: змішайте JPEG/PNG, старі/нові, великі/малі.
2. Перегенеруйте ці ID через WP-CLI.
3. Перевірте, чи файли існують і чи фронтенд віддає правильні розміри.
4. Виміряйте час на зображення і слідкуйте за CPU/iowait.

Крок 3: Виберіть модель виконання

• Один хост + низький трафік: запускайте пакети з nice/ionice, робіть паузи між пакетами.
• Мульти-хост або високий трафік: запускайте на виділених воркерах або тимчасово масштабуйтесь і ізолюйте обробку.
• Offload в S3: підтвердіть, що проміжні розміри завантажуються й віддаються; сама перегенерація може виправити лише локальне.

Крок 4: Запускайте пакети з явними умовами зупинки

Умови зупинки потрібно записати до початку:

• Час відповіді сторінки перевищує прийнятний поріг.
• CPU або iowait переходить поріг, який ви знаєте як болісний для користувачів.
• Рівень помилок при перегенерації WP-CLI перевищує невеликий відсоток (помилки обробки зазвичай повторюються).
• Вільний простір на диску падає нижче безпечної межі.

Крок 5: Стратегія кешу: очищуйте вузько, прогрівайте навмисно

• Очищуйте лише ті шляхи ескізів, які повертали 404 або застарілий контент.
• Надавайте перевагу природному заповненню кешів; уникайте повного очищення сайту.
• Якщо CDN кешує 404, явно очистьте ці об’єкти після перегенерації.

Крок 6: Перевірка після запуску

• Зразково перевірте різні типи контенту: пости, сторінки продуктів, сітки категорій, результати пошуку.
• Перевірте коректність srcset (розміри існують і доступні).
• Підтвердіть, що об’єктне сховище містить згенеровані розміри, якщо ви віддаєте звідти.
• Переконайтеся, що бекапи і пороги моніторингу повернулися до норми.

Типові помилки: симптом → корінь → виправлення

1) Симптом: мініатюри 404, але оригінали завантажуються

Корінь: відсутні проміжні розміри або метадані вказують на неіснуючі розміри (часто після змін розмірів теми або невдалих попередніх генерацій).

Виправлення: перегенеруйте ескізи пакетно через WP-CLI; перевірте права диска; очистьте CDN-кеш 404 для уражених шляхів.

2) Симптом: мініатюри існують на диску, але через HTTP все одно 404

Корінь: конфігурація веб-сервера блокує доступ, неправильний document root або offload/CDN переписує шляхи.

Виправлення: перевірте правила Nginx/Apache для /wp-content/uploads; перевірте симлінки; перевірте відображення origin-путей у CDN.

3) Симптом: після перегенерації зображення виглядають розтягнутими або неправильно обрізаними

Корінь: тема запитує ім’я розміру, яке зараз зареєстровано інакше; або ж захардкоджені розміри конфліктують з згенерованими.

Виправлення: перевірте зареєстровані розміри і використання в темі; перегенеруйте після остаточного затвердження розмірів; оновіть шаблони, щоб використовувати правильні функції й імена розмірів.

4) Симптом: перегенерація падає з помилками пам’яті

Корінь: memory_limit PHP занадто мале для великих зображень; ресурси ImageMagick занадто консервативні.

Виправлення: підвищте ліміти пам’яті, зменшіть розмір пакетів і повторіть канарні тести; розгляньте тимчасове використання GD для проблемних форматів.

5) Симптом: сайт гальмує під час перегенерації навіть при пакетуванні

Корінь: спільне вузьке місце: диск I/O, мережеве сховище та операції з метаданими або конкуренція воркерів PHP-FPM.

Виправлення: застосуйте nice/ionice; перенесіть перегенерацію на виділений воркер-хост; працюйте поза піком; зменшіть паралельність до одного процесу.

6) Симптом: тільки деякі роки/місяці зламані

Корінь: часткова міграція, rsync пропустив старі папки або інші права в старих каталогах.

Виправлення: перевірте власність директорій рекурсивно; підтвердіть наявність усіх шляхів uploads; спочатку перегенеруйте цільові діапазони.

7) Симптом: srcset включає розміри, які не існують

Корінь: застарілі метадані вкладення або плагін додав розміри, а потім видалив їх, лишивши старі записи.

Виправлення: перегенеруйте вкладення, щоб оновити метадані; стабілізуйте список розмірів; очистьте кеш сторінок, щоб HTML оновився.

8) Симптом: мініатюри існують, але CDN віддає старе пошкоджене зображення

Корінь: CDN закешував зламану відповідь, іноді включаючи кешування 404 або застарілу версію об’єкта.

Виправлення: очищуйте конкретні об’єкти (не все); якщо доступна версіонізація, змініть ключ кешу через query-string або версіоновані імена файлів.

Питання й відповіді

1) Чи потрібно відключати WordPress, щоб перегенерувати ескізи?

Ні. Але перегенерацію слід трактувати як фонову пакетну роботу. Використовуйте WP-CLI, обмежуйте її і стежте за навантаженням. Просто не обов’язкове; хаос — необов’язковий.

2) Чому WordPress не згенерував нові розміри автоматично?

WordPress генерує проміжні розміри під час завантаження зображень. Коли ви змінюєте зареєстровані розміри пізніше (зміна теми, налаштувань), старі вкладення не отримають нові розміри автоматично — потрібно перегенерувати.

3) Що безпечніше: ImageMagick чи GD?

ImageMagick часто дає кращу якість і більше можливостей, але частіше стикається з політиками й ресурсними обмеженнями в хостингу. GD простіший і іноді передбачуваніший у жорстких умовах. У продакшні «безпечніше» означає «працює для ваших найбільших реальних зображень під навантаженням». Виконайте канарні тести перед вибором.

4) Чи можна перегенерувати лише відсутні розміри замість усього?

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

5) Чому мініатюри в адмінці правильні, а на фронтенді ні?

wp-admin часто показує один розмір або використовує іншу розмітку, ніж ваша тема. Фронтенд використовує srcset, кастомні розміри і кешуючі шари. Якщо HTML закешовано, він може продовжувати посилатися на старі імена файлів навіть після перегенерації.

6) Що робити, якщо uploads винесено в S3-сумісне сховище?

Перегенерація на ап-хості може створити лише локальні проміжні розміри. Переконайтеся, що ваш плагін offload завантажує нові варіанти і що URL-адреси переписуються на бакет/CDN правильно. Перевіряйте віддалену наявність, а не лише локальну.

7) Як уникнути насичення PHP-FPM воркерів?

Не запускайте перегенерацію через адмінку на завантаженому сайті. Використовуйте WP-CLI з nice/ionice, тримайте низьку паралельність і працюйте поза піком. Якщо можливо, використовуйте виділений воркер-хост, щоб веб-воркери залишалися для запитів користувачів.

8) Чи варто очищати весь CDN-кеш після перегенерації?

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

9) Чому перегенерація іноді змінює вигляд зображень?

Різні бібліотеки обробляють різкість, кольорові профілі і орієнтацію EXIF по-різному. Також могли змінитися налаштування обрізки теми. Очікуйте деяких відмінностей — перевірте найбільш помітні типи контенту перед повним прогоном.

10) Чи можна запускати кілька процесів перегенерації паралельно, щоб завершити швидше?

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

Висновок: наступні кроки, які можна виконати сьогодні

Зламані мініатюри рідко бувають «тільки мініатюрами». Це ваша система, що підказує про слабкі місця: припущення щодо сховища, дрейф метаданих, поведінка CDN і фонові роботи, що конкурують з живим трафіком.

Зробіть наступне:

1. Запустіть швидкий план діагностики і визначте, чи маєте справу з відсутніми файлами, застарілими метаданими або помилковим роутингом кешу/offload.
2. Канарно перегенеруйте 10 вкладень через WP-CLI і підтвердіть як файлову, так і HTTP-поведінку.
3. Згенеруйте список ID вкладень і запускайте обмеженими пакетами з nice/ionice, маючи явні умови зупинки.
4. Очищуйте вибірково (особливо кешовані 404) і дозволяйте кешам прогріватися замість тотального очищення CDN.
5. Запишіть, що ви дізналися: безпечний розмір пакета, середній час на зображення і виявлені режими помилок. Майбутнє «ви» буде вдячне.

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