Убрать миниатюру из записи wordpress

Как удалить в WordPress миниатюры изображений

В WordPress создается очень много миниатюр одного изображения. Помимо самого движка, дополнительные миниатюры создаются активной темой (шаблоном). Если вы периодически изменяете размер миниатюр, то данный плагин вам жизненно необходим, так как свободное место на хостинге не резиновое. При изменении миниатюр, старые не удаляются. Чтобы пересоздать новые и удалить ненужные более старые, я рекомендую вам воспользоваться плагином «Force Regenerate Thumbnails».

Я тестировал несколько плагинов. В основном они пересоздают, но не удаляют старые миниатюры, а некоторые очень сильно грузят процессор на хостинге, ограничения которого не могут позволить вам пересоздать то огромное количество миниатюр за один раз. Данный плагин исключает вышеперечисленные недостатки. Если вы знаете лучшее решение для удаления старых и пересоздания необходимых миниатюр изображений — отпишитесь в комментариях. Для этого в админке вордпресса переходим на страницу плагинов, переходим по кнопке «добавить новый», ищем «Force Regenerate Thumbnails», устанавливаем и активируем его.

Далее заходим в «настройки» -> «медиафайлы».

Вордпресс позволяет указать три вида миниатюр: маленький, средний и крупный размер. Если определенным размером миниатюры вы пользоваться не будете, то укажите в соответствующей строки ширину и высоту в ноль. Если у в папке upload у вас создаются миниатюры других размеров — значит их создает ваш текущий шаблон WordPress, либо какой-то из плагинов.

В первую очередь смотрим файл «functions.php» текущей темы и ищем там строки «add_image_size» и комментируем их с помощью двух слешей.

Также миниатюры еще могут создавать какие-нибудь плагины. В первую очередь проверяйте те, которые работают с изображениями, к примеру, плагины досок объявлений, плагины, позволяющих размещать фотографию в комментариях и т.д. Закомментируйте все функции создания миниатюр и далее запускайте работу плагина «Force Regenerate Thumbnails». Он расположен на вкладке «Инструменты».

Нажимаем на кнопку «Пересоздать все миниатюры» и ждем, пока все миниатюры удалятся и создадутся заново.

Ждем окончания процесса пересоздания всех миниатюр. Во время работы видим следующую картину.

Вы также можете удалить и создать новые миниатюры у определенного изображения. Нажав на одноименную ссылку рядом с медиафайлом.

Как удалить лишние картинки c сайта на WordPress

Я прошу прощения у моих постоянных читателей за этот не тематический пост. Все ниже следующее сможет заинтересовать только владельцев сайтов на WordPress. Обещаю не злоупотреблять этой темой впредь. Это первый мой пост на тему блогинга за 3 года.

Как водится через 3 года после начала ведения блога я получила печальное известие со своего хостинга:

На Вашем аккаунте осталось менее десяти процентов свободного дискового пространства. Нехватка места может привести к сбоям в работе Ваших сайтов и почты.

За три года я исчерпала лимит в 2Гб. Вообще конечно не стоило дожидаться таких предупреждений, но что сделано, то сделано. Я решила удалить лишние миниатюры картинок при помощи плагинов. Изучив интернет на эту тему, я поняла, что топ выдачи полон крайне низкокачественными постами. Ни один из этих постов не разбирает проблему полностью, а некоторые дают откровенно вредные советы, говорящие о том что авторы советов сами не разбираются в этом вопросе.

Во-первых стоит заглянуть в свою папку uploads и посмотреть, а сколько вообще делается превьюшек для каждого закачанного изображения. В моем запущенном случае оказалось, что на каждое изображение у меня генерируется целых 6 миниатюр разного размера, а сейчас на моем сайте более 3000 фотографий, так что эти превью явно занимают колосальный объем. Все миниатюры создаются в WordPress в момент закачки.

Alt/Prt/Scr Backupа на моем хостинге, поскольку файлы я уже снесла

Конечно мне совершенно не нужно было такое количество миниатюр. Реально я использовала только миниатюры размером 150Х150 на страницах рубрик и меток, для «Библиотеки медиафайлов» размера 150Х150 тоже вполне достаточно.

Далее я изложу что со всем этим делать. Для начала нужно отключить генерацию ненужных миниатюр.

Как отключить генерацию ненужных миниатюр

Источников генерации миниатюр всего 3, чаще всего из них упоминают только первый.

  1. Размеры миниатюр задаются в меню Настройки → Медиафайлы
  2. Генерация миниатюр может быть задана в файле functions.php
  3. Генерация миниатюр может быть задана в плагинах, которые используют картинки, у меня это был плагин Manual Related Posts и Top 10, у вас могут быть другие плагины.

С первым пунктом разобраться легче всего. Заходите в соответствующий пункт меню и зануляете не нужные вам размеры.

Если в вашей папке uploads есть размеры не заданные в настройках медиафайлов, то следует открыть файл functions.php и поискать там строки, содержащие: «post-thumbnails», у меня я нашла следующее:

add_theme_support( ‘post-thumbnails‘ );

Нужно сначала подумать, а нужны ли вам эти размеры. Если вы считаете, что не нужны то, аккуратно закомментируйте, все подобные упоминания. Если комментировать не аккуратно, то можно получить Fatal error.

Если после этого шага все еще остались не нужные размеры миниатюр то стоит заняться анализом плагинов, которые используют картинки или могут использовать превьюшки. Возможно стоит удалить такие плагины.

Особенно коварны различные слайдшоу, как правило в слайдшоу используется 5-10 слайдов, а превьюшки большого размера генерируется для всех закачиваемых изображений. На мой взгляд это слишком большая роскошь хранить на сервере 3000 миниатюр, ради того чтобы использовать всего 10 из них. Эти 10 необходимых лучше сделать вручную. Но тут говориться, дело вкуса.

Мой плагин Top10 генерировал миниатюру на каждую закачанную картинку, хотя реально использовал от силы 10 штук, т.е. плагины коварны и пожирают место на сервере огромными кусками. Возможно все это от того что миниатюры в WP создаются во время закачки картинки, если бы они создавались только в момент первого обращения за картинкой, то не было бы такой проблемы. Это так из размышлений о недостатках вордпресса.

В плагинах следует так же искать автопоиском по словам «post-thumbnails», если вы все таки хотите использовать плагин, но не хотите использовать картинки в его функционале. При обновлении плагина эту операцию придется повторить.

Далее я рекомендую проверить ваши достижения, закачав любую картинку. После закачки заходите в папку upload и смотрите, сколько превьюшек сгенерировалось.

Если результат удовлетворяет, то можно переходить к следующему этапу.

Как удалить не нужные миниатюры

Важно понимать, что миниатюры генерируются не только в папках на вашем сервере, для каждой миниатюры делается запись в базе данных сайта, поэтому просто удалить файлы миниатюры в папке uploads на вашем сервере не очень хорошая идея. Миниатюры еще используются в «Библиотеке медиафайлов» и в «Миниатюре записи», при неправильном удалении можно получить следующую печальную картину.

При удалении файлов превью пропали

Сами оригиналы фотографий целы, я удалила только миниатюры размером 300х199 и в библиотеке медиафайлов перестали показываться превьюшки. На самом деле для этой цели вполне подойдут миниатюры размером 150х150, но по умолчанию в библиотеке медиафайлов показываются картинки среднего размера.

Поэтому лучше использовать плагин Thumbnail cleaner, он удалит все миниатюры, а после этого вы сгенерируете новый облегченный набор миниатюр при помощи плагина Regenerate Thumbnails.

Я видела в интернете советы типа : «Вставьте этот код в файл functions.php и выполните его разок». А в коде сносятся только записи из базы данных, этот вредный совет не приведет к расчистке существенного места на вашем сервере. Важно удалить и записи в базе данных, и файлы на сервере. А потом сгенерировать это все заново в уменьшенном количестве.

Так же важно понимать, что если у вас много картинок этот процесс создаст значительную нагрузку на сервер, лучше его производить ночью или в дни когда посещаемость вашего сайта меньше всего, например в субботу. Ну и нужно вообще понимать, какую нагрузку вам в состоянии простить хостер без выключения вашего сайта.

Естественно нужно сделать Backup папки uploads и базы данных, на всякий пожарный случай, но лучше без помощи плагина Thumbnail cleaner, чтобы не нагружать сервер, которому предстоит поработать и без этой операции.

Итого у меня было порядка 3000 фотографий и плагин Thumbnail cleaner, насчитал порядка 14000 миниатюр, со сносом плагин справился за 2 минуты.

Генерация же новых миниатюр при помощи плагина Regenerate Thumbnails заняла целых 30 минут. И на следующее утро я получила ругательное письмо от Sweb о том что я нарушила условия нашего договора и превысила разрешенную мне нагрузку на сервер. Но к счастью Sweb ограничился только этим письмом. Ниже можете оценить насколько повысилась нагрузка на сервер в результате моих операций.

Что еще может пожирать место на диске

Некоторые плагины могут писать логи и никогда не удалять их.

За три года на моем сайте Total Cache записал более 1 Мб логов!!! Отключить их генерацию невозможно из админки, снести их можно только по FTP. Если вы используете Total Cache посмотрите сколько весит у вас содержимое этой папки /wp-content/cache/log/000000, возможно, что после ее зачистки вам не придется возиться с перегенерацией превью.

iThemes Security пишет логи 404 ошибки не забывайте периодически их очищать. Особенно логи разрастаются в момент атаки на сайт.

Популярный плагин Yoast SEO пишет логи 404 ошибки, не вредно будет туда заглядывать, анализировать содержимое и очистить логи. Посмотрите что у вас в «Консоли поиска» Yoast SEO.

Многие плагины в момент установки закачивают все возможные языковые пакеты, все не нужные вам языки стоит снести. Проверьте что у вас находится в папках:

Вполне возможно, что там остались языковые пакеты от неиспользуемых вами тем и плагинов.

Просмотрите ваши плагины на предмет не нужных вам языковых пакетов по адресам.

/wp-content/plugins/название плагина/lang(languages).

Популярный плагин Yoast SEO пишет логи 404 ошибки, не вредно будет туда заглядывать, анализировать содержимое и очистить логи.

Нагрузка на сервер

Моей насущной проблемой является превышение нагрузки на сервер, по моему тарифу процессы на моем сайте должны занимать в день не более 60 минут процессорного времени. Пока Sweb меня терпит, но хотелось бы найти решение этой проблемы. Я давно уже поставила себе Total Cache и он даже работает, но при его подключении я не заметила скачкообразного уменьшения нагрузки, а я его ожидала. В чем прикол этого плагина мне не понятно.

Моя нагрузка точно не связана с атакой на сервер. Во время атаки нагрузка увеличивается скачкообразно, это не мой случай, она у меня пару лет высокая и коррелирована с посещаемостью. К тому же я поставила плагин безопасности, изменила страницу входа в админку, все переборщики паролей банятся после первой попытки.

Конечно выделенный сервер решит эту проблему, но он стоит намного дороже, чем виртуальный хостинг. У меня пока не та посещаемость и не те заработки, чтобы так раскошелится. Ведь у многих блогеров бывает посещаемость и в 2000 и 3000 уников, как ваши сервера выдерживают такую нагрузку, каким хостингом вы пользуетесь? Буду благодарна за советы.

Мой опыт использования CDN (Content Delivery Network)

Внимание все ниже перечисленное происходило двумя месяцами позже расчистки места на диске от лишних миниатюр.

Я дождалась очередного злостного письма от своего хостера Sweb. В связи с наступлением активного туристического сезона посещаемость моего сайта скачкообразно возросла и нагрузка на сервер, создаваемая процессами на моем сайте достигла критической величины 120 минут в сутки, напомню что согласно договору моему сайту положено потреблять всего 60 минут процессорного времени в сутки.

Sweb предложил мне перейти на другой тариф стоимостью всего 800 руб. в месяц!!! Эта не гуманная сумма меня никак не устраивала, сейчас я плачу всего 120 руб. в месяц, повысить цену почти в 6 раз, это грабеж. В результате жаба меня задушила и я решила попробовать CDN от CloudFlare, в конце концов другого выхода у меня не было.

У CloudFlare есть бесплатный тариф, именно на него я и подключилась. Больше всего беспокойства вызывало требование переписать на CloudFlare мои DNS записи, но я сделала это, и в результате вы видите на графике нагрузка на сервер существенно снизилась до порога который Sweb склонен прощать. Момент подключения CDN я отметила зеленой меткой на картинке.

Я конечно ожидала большего, мне мечталось увидеть цифру 30 минут в сутки, но этого не произошло. CDN это система серверов по всему миру на которые копируется ваш сайт и при запросе, например идущем из США, отвечает сервер расположенный в США, а не в Санкт-Петербурге, что должно сократить время загрузки сайта и попутно этот метод сокращает нагрузку на мой сервер.

Кроме системы доставки контента CloudFlare предлагает еще защиту от DOS-атак, аналитику и минимизацию html, css, и js. Я отключила минимизатор от Total Cache, поскольку что-то он генерирует ошибку, некоторые мои тексты очень длинные и ему не хватает 64Мб оперативной памяти для минимизации html.

Бесплатный аккаунт CloudFlare имеет ряд ограничений, что вполне естественно. За один запрос посетитель может загрузить с CloudFlare не более 100Мб и сервера обновляются в течении 24 часов. Т.е. если продать ссылку покупатель увидит ее не сразу, а в течении 24 часов.

Из недостатков CloudFlare я заметила следующие:

  1. Функция Always Online совершенно не гарантирует показ вашего сайта, если ваш собственный сервер перестанет работать. Многие русские блогеры обещали такую фишку, но на самом деле это не так. На официальном сайте CloudFlare написано, что он не сохраняет абсолютно все страницы вашего сайта, он сохраняет первые 10 html- страниц сайта и лишь некоторые ссылки с них, сами понимаете, что это ничтожно мало для блога состоящего из 400 страниц. Поэтому, когда мой сервер падает, я вижу вместо своего сайта сообщение об ошибке от CloudFlare.
  2. Мой сайт, подключенный к CloudFlare блокируется для интернет соединений, использующих TOR. Я это заметила сидючи в facebook, там я советовала свой сайт людям и некоторые мне отписывались, что страница не открывается. Что характерно, когда они заходили на мой сайт через мобильный интернет у них все открывалось, у меня тоже все открывалось, сайт в этот момент работал. Дело было именно в интернет-соединении.

Сообщение об ошибке, которое я вижу если мой сервер слёгАналитика на октябрь 2017

Нагрузка на сервер существенно возрастает в момент, когда я пишу статью, поскольку в этом случает работает мой сервер. Я отключила создание ревизий совсем и даже отключила возможности HeartBeat API, выполняющее автосохранение записи при написании статьи и прочие функции, необходимые, если редакторов на сайте несколько человек. Буду наблюдать.

В октябре 2017 меня постигло очередное горе. После обновления wordpress и плагинов, нагрузка на сервер опять значительно возросла, это при том, что сейчас посещаемость по сравнению с июлем меньше. В логах ошибок на сервере чисто. Вообще эта картина довольно типична, когда после обновления плагинов возрастает нагрузка на сервер.

Нагрузка за июль, я превышаю. Моя зона синяя.

Я перевела сайт на php7. Это было не просто. Сначала при переключении вместо своего сайта я видела белую страницу с надписью:»Ошибка соединения с базой данных». Хостер мне не смог помочь советами, пришлось разбираться самостоятельно. Оказалось я использовала устаревшее соединение с базой данных. Для его обновления нужно просто перегенерировать пароль соединения с базой данных и всё, но на поиски этого решения я потратила 2 дня.

После переключения нагрузка на сайт начала зашкаливать за разумные пределы, вопреки многочисленным предсказаниям о том, что она просто обязана упасть. Еще несколько дней раздумий и экспериментов и я решила и эту проблему. Оказалось в function.php моей темы я добавила (по советам от опытных вебмастеров из интернета) функцию, которая содержала в себе лишний цикл, давно уже. При работе на php5.3 перегрузки не возникало, а после переключения на php7 просто начало зашкаливать. Когда я устранила эту проблему, я увидела свою нагрузку наконец в синей зоне.

Сейчас я поставила пару новых плагинов (WP-PostRating и SNAP|AutoPoster) и опять её покинула.

Нагрузка за октябрь. Пики были вызваны ошибками в function.php, они проявлялись только в о время работы в админке, поэтому мне было трудно найти в чем дело

Из мыслей по поводу снижения нагрузки для меня актуально следующее:

  1. Попробовать заменить плагин кеширования Total Cache, на плагин сохраняющий голые html-страницы. Total Cache не эффективен на виртуальных хостингах. Кеширование базы данных не работает, ему не хватает оперативной памяти, по той же причине не работает minifier. Реально из всего богатого набора Total Cache работает только кеширование страниц и браузерное кеширование. По поводу кеширования голого html меня терзают мысли, а что будет с добавлением комментариев и как будет показываться google adsense, как будет работать рейтинг.
  2. Попробовать создать AMP- версию сайта, если медленные соединения будут загружаться с гугла, а не с моего сервера, нагрузка просто обязана уменьшиться. Тут конечно всё будет зависеть от количественных характеристик: весь вопрос в том, сколько пользователей в день будут загружать сайт с гугла? И быстрее всего настройка этого плагина тоже обещает быть томной.
  3. И сейчас меня гложут сомнения в правильности моего решения по сносу лишних миниатюр. Дело в том, что wordpress на мобильные устройства будет грузить картинки шириной в 300 пикселей или же 700 пикселей, если разрешение экрана маленькое, а если миниатюр нет то будет грузить полноразмерные картинки в 1000 пикселей по ширине. Подумайте хорошенько прежде чем сносить. Я собираюсь попробовать плагин

    «SrcSet Responsive Images for WordPress»,чтобы откатиться назад.

На будущий сезон наверное нужно переходить на выделенный сервер на DigitalOcean. Я сама никогда не конфигурировала серверов, поэтому процесс вызывает вопросы, но надеюсь у меня получится. Обещаю написать как оно при случае.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *