Здравствуйте, уважаемые читатели блога www.сайт. Если тексты статей на сайте, работающем на CMS WordPress, то очень скоро объем базы данных сайта увеличится многократно.

Дело в том, что начиная с версии 2.6 в WordPress был добавлен очень полезный и нужный механизм ревизий (редакций) записей.

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

Ревизии в WordPress позволяют избежать потери данных за счет того, что все предыдущие версии записей не удаляются из базе данных, а лишь получают другой статус — «revision »

В слове “все” предыдущего абзаца как раз и кроется причина неограниченного роста размера базы данных. Каждая редакция (ревизия) записи содержит ее полное содержание. А это значит, что если в процессе подготовки какой-либо статьи вы исправили и перезаписали ее, скажем, 10 раз, то в базе данных будет сохранено 10 копий. Если вы исправите всего один знак, в базу еще раз добавится текст целиком.

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

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

Управление количеством ревизий записей в WordPress

Для управления механизмом сохранения редакций записей в WordPress в файл конфигурации “wp-config.php ” после:
/** The Database Collate type. Don"t change this if in doubt. */
define("DB_COLLATE", ""); необходимо добавить всего лишь одну запись.
Для ограничения количества редакций тремя экземплярами:
define("WP_POST_REVISIONS", 3); Вместо “3” может быть любое нужное вам значение. “0” отключит сохранение ревизий. Такой же результат будет достигнут, если вместо цифры написать “false”:
define("WP_POST_REVISIONS", false);
Если по какой-либо причине нужно вновь разрешить сохранение всех редакций без удаления данной строки из “wp-config.php ”, то можно написать:
define("WP_POST_REVISIONS", true);

Тип ревизий записей в WordPress

В свою очередь редакции делятся на две категории:

1. редакторские ревизии — предыдущие версии текстов, появившиеся после публикации или сохранения редактором (автором) обновленной записи;
2. автосохраненные ревизии — автоматически создаются через определенные временные интервалы.

Как интересно. Пока писал этот пост заметил интересную особенность. Если запись находится в статусе «Черновик», то автосохраненные редакции у нее отсутствуют. Выходит, что на черновик автосохранение не распространяется. Стало быть, забывать нажимать на «Сохранить» при работе с черновиком в редакторе WordPress не стоит.

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

Автосохранение позволяет не потерять недавно набранные данные в том случае, если автор забыл сохранить их принудительно (получается, что на черновик это не распространяется).

Изменить интервал автосохранения можно добавив в файле конфигурации WordPress “wp-config.php ” строку:
define("AUTOSAVE_INTERVAL", 60); где 60 – интервал в секундах, соответствующий установленному по умолчанию. Его можно скорректировать в любую нужную сторону.

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

Если надо удалить все релизы, то сделать это можно без установки плагинов непосредственно в базе MySQL через phpMyAdmin.

Заходим в phpMyAdmin и выбираем нужную базу в левом столбце интерфейса. Начинаем, естественно, с .

Бекап базы данных

Переходим на вкладку “Экспорт”:

В открывшемся окне оставляем настройки без изменений. Нажимаем “ОК” в правой нижней части экрана и ждем завершения операции сохранения бекапа базы данных.

Запросы к базе данных на удаление ревизий и оптимизацию таблицы wp_posts

Переходим на вкладку “SQL”. В поле запросов к базе данных пишем:
DELETE FROM wp_posts WHERE post_type = "revision";
OPTIMIZE TABLE wp_posts;

Нажимаем “OK”, подтверждаем желание выполнить запросы к базе.

После успешного завершения запросов должно появиться сообщение такого вида:

При желании можно писать и выполнять запросы последовательно.

Если после сделанных операций вновь посмотреть на размер базы данных (для простейшего сравнения можно не выходя из phpMyAdmin повторить бекап базы в новый файл), то можно с радостью убедиться, что он уменьшился в несколько раз.

Лично я на этом бы уже и остановился – максимальное число сохраняемых релизов настроено, база данных очищена и оптимизирована. При желании, по прошествии некоторого периода времени, определяемого объемом сделанных на сайте изменений текстов, очистку базы описанным способом можно повторить.

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

По мере использования WordPress, ваша база данных накапливает множество дополнительных данных, таких как редакции записей, спам-комментарии, данные плагинов, которые вы уже не используете и многое другое. Удаление этих ненужных данных может существенно уменьшить размер вашей БД, что ускорит процесс бекапа и добавит немного производительности сайту. Как минимум, просто не имеет смысла хранить в базе данные, которые впоследствии никогда не будут использоваться.

Давайте же рассмотрим способы «очистки» вашей базы данных WordPress.

Перед началом сделайте бекап!

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

Вычищаем свою БД WordPress с помощью WP-Sweep

Первым делом вам необходимо будет установить и активировать плагин WP-Sweep plugin . После активации просто переходим в раздел Инструменты » Sweep для очистки своей БД.

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

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

Очистка может занять некоторое время в зависимости от того, насколько велика ваша БД. WP-Sweep отобразит прогресс путем обновления статистики на странице.

Преимущества WP-Sweep перед WP-Optimize?

Возможно вы удивились, почему мы пишем о WP-Sweep, когда есть другой очень популярный плагин WP-Optimize, выполняющий по сути те же самые функции.

Также основной отличительной характеристикой является то, что WP-Sweep использует корректные функции удаления WordPress настолько, насколько это возможно вместо прямого выполнения MySQL запросов.

Что очищает WP-Sweep?

WP-Sweep использует корректные функции удаления WordPress для очистки БД. На момент написания этой статьи, он справляется со следующим:

• Редакции записей
• Автоматически сохраненные черновики
• Удаленные комментарии
• Неподтвержденные комментарии
• Комментарии, являющиеся спамом
• Неиспользуемые метаданные записей
• Неиспользуемые метаданные комментариев
• Неиспользуемые метаданные пользователей
• Неиспользуемые отношения терминов
• Неиспользуемые термины
• Дублирующиеся метаданные записей
• Дублирующиеся метаданные комментариев
• Дублирующиеся метаданные пользователей
• Промежуточные вариации
• Оптимизация таблиц базы данных
• Кеш oEmbed в метаданных записей

Вот и все, мы надеемся, что эта статья помогла вам вычистить мусор из вашего сайта на WordPress с помощью WP-Sweep.

По всем вопросам и отзывам просьба писать в комментарии ниже.

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

Задался я вопросом,

как почистить базу данных wordpress блога?

поискал в интернете, и нашел интересные статьи, которые и привожу тут (без изменений)

—
WordPress безусловно самый лучший движок для создания своего электронного дневника в интернете. Но как не прискорбно, и у него есть свои минусы. Самая главная проблема – это использование базы данных.

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

Шаг 1. Удаляем резервные копии постов (т.н. ревизии)

Наша проблема. WordPress устроен таким образом, что при написании новых постов (или редактировании старых) он периодически (примерно один раз в минуту) создает их резервные копии, что можно четко увидеть в самом низу страницы, при работе с новым или корректировкой старого поста. Но что самое интересное, так это то, что после публикации конечной версии поста, движок WordPress`а автоматически не удаляет эти резервные копии (post revisions). Получается, что при длительной работе с одним постом в базе данных может остаться от пары копий этого поста до бесконечности.

Решение данной проблемы . В панели PhpMyAdmin своей базы данных переходим на вкладку SQL. Появится окно для создания запроса к БД. Вставляем нижеследующий запрос в окно и выполняем ее нажав кнопку OK:

DELETE FROM wp_posts WHERE post_type = "revision";

Разъяснение запроса. Таблица wp_posts имеет поле post_type . Оно может иметь одно из следующих значений: «post», «page» или «revision». Т.к. мы хотим избавиться от всех резервных постов, то наше значение – «revision». Просто запускаем команду, чтобы удалить все элементы в таблице wp_posts , в которой поле post_type равно «revision».

Шаг 2. Удаляем СПАМные комментарии

Наша проблема. Все комментарии, которые хотя бы однажды попадали на блог навсегда остаются в базе данных. Это касается одобренных, удаленных и спамных комментариев.

Решение данной проблемы . В панели PhpMyAdmin своей базы данных переходим на вкладку SQL. Появится окно для создания запроса к БД. Вставляем нижеследующий запрос в окно и выполняем ее нажав кнопку OK :

DELETE FROM wp_comments WHERE comment_approved = "spam";

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

DELETE FROM wp_comments WHERE comment_approved = "0";

Разъяснение запроса. Таблица wp_comments содержит поле с именем comment_approved . Именно здесь делается отметка для каждого комментария: одобрен – 1, удален или еще не одобрен – 0, спам – spam. Запустив поочередно эти команды (в одиночных ковычках меняем значения по очереди, т.е. сначала выполняем со значение ’0? , затем – ’1? и напоследок – ‘spam’ , таким образом мы удаляем все комментарии, которые отвечают нашим критериям.

Строки базы данных WordPress по-умолчанию, т.е. создаются они при инсталяции движка. Многие плагины создают свои строки (таблицы) в базе данных WordPress и не удаляют их после своей деактивации. Проблема решается простым удалением таких строк вручную. А чтобы было легче найти лишние строки, вот вам список строк, которые должны быть в базе данных по-умолчанию:

wp_comments
wp_links
wp_options
wp_postmeta
wp_posts
wp_terms
wp_term_relationships
wp_term_taxonomy
wp_usermeta
wp_users

Внимание! Прежде чем удалять лишние строки убедитесь, что:

1. Ваша база данных сохранена, – это на всякий случай, если у вас уже есть какой то контент наблоге.

2. Убедитесь, что плагин, таблицы которого вы хотите удалить, действительно уже не используется (деактивирован).
Метки: WordPress, база данных, оптимизация базы данных, чистка базы данных , плагины

http://m-media.su/chistka-bazy-dannyx-wordpress.html

Чем хорош wordpress ? Тем, что он как пластилин при некоторых усилиях принимает нужную форму.

Чем хорош wordpress ? К нему есть большое количество плагинов, которые позволяют прикрутить к блогу любую функциональность.

Все вроде замечательно и прекрасно.

Но в плагинах есть одно неприятное свойство. Обычно они оставляют много записей в базе данных в частности в таблице wp_options . И если вы удалили плагин – то эти записи превращаются в мусор.

wp_options – очень важная таблица базы данных wordpress. В которой хранятся настройки блога.

Чем плох мусор в базе данных? Он раздувает базу данных и увеличивает ее размер.

Больше база данных – медленнее работа блога.

Медленнее работа блога – уже тянет за собой другие неприятные последствия.

Сегодня я покажу вам плагин, который позволит вам держать вашу таблицу wp_options в порядке.

Clean Options – поможет вам очистить таблицу wp_options от мусора

• Скачиваем его по ссылке ;
• Заливаем в папку с плагинами;
• Активируем плагин;

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

Заходим в Инструменты и выбираем пункт Clean Options

Плагин имеет русский перевод – так, что это облегчает работу с ним.

Первым делом плагин показывает, сколько опций содержит таблица wp_options .

В случае этого блога плагин нашел 368 записей.

Потом нам дают возможность настроить фильтры для поиска.

Их всего два:

• Не показывать известные базовые опции ядра WordPress для данного «Найти» (стоит ставить эту галочку, тогда плагин отсеет системные опции)
• Не показывать предупреждения альтернативного синтаксиса для данного «Найти» (здесь по выбору, до конца смысл этой опции я не понял)

Нажимаем: найти осиротелые записи

Ждем, пока плагин проведет анализ и выдаст нам результат.

После анализа плагин выдаст: Возможные осиротелые опции

Список имеет следующий вид:

Опция и готовый запрос для поиска в Google.

Здесь можно не бояться, и отмечать галочками опции это еще не финальная стадия. Удаление сразу не произойдет.

Выбрав опции, нажимаем: Посмотреть информацию в выбранных опциях

На выходе получим таблицу:

1. колонка – название опции;
2. колонка – значение опции;

Теперь вам нужно подтвердить намерение удалить данные опции.

Если согласны:

Отмечаем - Да, удалить ВСЕ эти опции из таблицы wp_options .

Жмем – отправить

Вот собственно и все. Мусорные опции удаленны из таблицы wp_options . Наш блог стал более быстр.

http://webmasterprof.ru/stati/wordpress-stati/operaciya-chistim-wp_options-v-wordpress.html

И ещё одна статья (очень похожая на первую, но чуток побольше)

На днях мне пришло письмо от хостера о том, что мой лимит жесткого диска потихоньку подошёл к концу (неожиданно).

Как обычно немного потупив, зашел в свой билдинг и действительно свободного места не осталось.
Порывшись малёха, нашел злополучного пожирателя и даже с облегчением выдохнул — Очередной мой сателлит на WordPress .
Ну а куда денешься. Кругом кричат ВордПресс — ууу яя зер гуд. Но мне данная КМС нравится только простотой создания всякого интернет-хлама (хотя и для сателлитов есть более удобные и рациональные CMS решения). В остальном-же WordPress только напрягает. Ну да шут с ней, вернёмся к проблеме..

Очистка WordPress блога

Мой разжиревший сателлит стал занимать более 50mb в одну калитку. (Для сравнения. Данный блог на DLE 8.5, на момент публикации, занимал всего 10 метров). И естественно что я стал глубоко возмущён данным обстоятельством. Ну не то, чтобы я за пятихатку зайца в поле лопатой отмудохал, но всёже… 50 мб в пустоту тратить.
Оказалось, что данный блог я совсем не оптимизировал, соскользнул он как-то. Но вот в силу обстоятельств добрался и до него, и вспомнил, что именно данный момент я упустил в своей прошлой статье посвящённой оптимизации сайтов на WordPress .
Вот и решил исправиться и описать то, что лучше делать при установке блога, или как я — когда совсем прижмёт.
Причиной данной проблемы (превышение места на жестком диске) была непомерно раздувшаяся база MySQL.

Почему WordPress занимает так много места?

ВордПресс создавался как Content Management System (Система управления содержимым) для блондинок (несерьёзная она), которые постоянно что-то путают, меняют и забывают, поэтому данная CMS при каждом изменении материала создаёт резервную копию (одну вторую и тд, пока лимит не исчерпает).
Естественно, что нам после того как мы опубликовали материал и довольны результатом, его резервные копии становятся не нужны.
И если Мы в душе не розовые блондинки, то данная функция нам ваааще незачем.
Но как сделать, чтобы WordPress не создавал резервные копии?
Для этого нам понадобиться:
1) по ФТП (лучше пользоваться FTP клиентом — FileZilla) из корневой папки сайта скачать файл wp-config.php
2) Открываем его в Notepad++ или WordPad и находим следующие строки:

/** The Database Collate type. Don’t change this if in doubt. */
define(‘DB_COLLATE’, »);

После них, просто вставляем следующее:

define(‘WP_POST_REVISIONS’, false);

3) Сохраняем и закачиваем обратно на сервер в корень домена как и было.
Данная манипуляция отключит функцию сохранения копий , но если Вы все-же хотите её оставить, но в меньшем объёме, то поменяйте значение «false» на цифру, которая будет обозначать максимальное количество сохранённых копий каждого материала (например — две):

define(‘WP_POST_REVISIONS’, 2);

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

Как удалить резервные копии материалов?

Есть хороший плагин delete revision, он позволит удалить все ненужные копии.
Но мне проще всё это сделать через панель phpMyAdmin (не люблю я эти плаги-лаги). И Вам рекомендую. Так как, если Вы серьёзно решили заняться сайтостроением или оптимизацией, без знания функций phpMyAdmin просто не обойтись, поэтому осваиваем и привыкаем потихоньку. Итак…

Чистка WordPress блога без установки плагинов — через панель phpMyAdmin.

Для подстраховки создадим резервную копию нашей имеющейся базы данных MySQL.
1) Из панели управления хостингом DAdmin, ISPmenager, DirectAdmin (или что-то наподобие) заходим в панель phpMyAdmin.

3) Нажимаем на опцию «Экспорт» (обычно в самой верхней части),
4) Выбираем метод сжатия zip или Gzip — это почти фиолетово (обычно в самом низу).
5) Нажимаем в самом низу кнопку «OK», «Выполнить» или «YES» у кого как.
6) И сохраняем себе на компьютер. Не забудьте куда.
Всё. Перестраховались. Можно мутить…
Опят подключаемся к нужной нам базе MySQL в панели phpMyAdmin и переходим к очистке от резервных копий.
Для прикола и информации о проделанной работе запомните цифру напротив строчки «wp_posts» — занимаемое место.
1) Открываем окно запроса к данной базе (обычно это кнопка «SQL» с подсказкой «окно запроса» или тп)
2) И вводим следующую команду:

Нажимаем «OK»

Данная команда удалит все резервные копии Ваших материалов.
После того как Вы закончите данные манипуляции:
— Оптимизируйте базу данных MySQL запросом:

OPTIMIZE TABLE wp_posts;

Вот и усё. Смотрим результат очистки в строчке «wp_posts».
Вот так путём нехитрых манипуляций мы очистили базу данных ВордПресс блога.
Но, моя проблема заключалась в другом.
Поскольку я не заходил в админку того блога очень давно, соответственно не менял материалов и соответственно, резервные копии не создавались…
На моём блоге было слишком много СПАМ комментариев. Ну забыл защитить.
Удалять их руками муторно, да и раз Мы заговорили про phpMyAdmin то:

Чистка комментариев WordPress блога через панель phpMyAdmin.
По аналогии с предыдущим маневром:
1) Открываем окно запроса к нужной нам базе MySQL
2) Вводим следующую команду:

и нажимаем «OK»
И получаем результат — СПАМ удалён
Можно удалить и комментарии, которые находятся в очереди на модерацию следующей командой:

А командой:

Вы удалите все имеющиеся комменты.
И чтобы в дальнейшем облегчить борьбу со СПАМом активируйте плагин Akismet
Вот так я и снизил пространство почти в два раза. Шутка. Кроме оптимизации того блога, я забыл удалить левые темы и плагины, которые и пожирали основную массу места.

Кстати о плагинах.
Многие плагины при установке, а точнее при активации создают себе поле записи в базе данных MySQL.
А после удаления плагина запись часто остаётся. Проверить это можно там-же в панели phpMyAdmin
Вот как выглядит шаблонная база данных нулёвого ВордПресс блога:

wp_comments
wp_links
wp_options
wp_postmeta
wp_posts
wp_terms
wp_term_relationships
wp_term_taxonomy
wp_usermeta
wp_users

Всё остальные записи желательно рассмотреть пристальней на предмет схожести с названиями плагинов.
И если обнаружите левую запись — удаляйте, но не забудьте сохранить резервную копию, как описано выше.
Вот вроди и всё. Если что-то не получилось и после манипуляций в phpMyAdmin панели, сайт перестал фурычить — восстановите сохранённую базу.

Восстановление ранее сохранённой копии базы данных MySQL.

1) Из панели управления хостингом DAdmin (или что-то навроде) заходим в панель phpMyAdmin.
2) Выбираем интересующую нас базу MySQL (обычно они в меню слева).
3) Нажимаем на опцию «Импорт» (обычно в самой верхней части),
4) Нажимаем «Browse»
5) Выбираем сохранённую базу данных с компа.
5) Нажимаем в самом низу кнопку «OK», «Execute», «Выполнить» или «YES» у кого как.
6) И смотрим на результат, если не восстановится — пробуем ещё раз (бывает глюкает у некачественных хостеров).

http://expertinternet.ru/2010/09/02/wordpress.html
Ну вот теперь Всё. Удачи всем.

Здравствуйте, друзья! Как известно не все что хранится в папках нашего сайта на хостинге действительно необходимо. За время существования сайта в его “закромах” скапливаются горы мусора, то есть множество ненужных для нормальной работы веб-ресурса файлов. Это может быть все что угодно - временные или неиспользуемые файлы, копии документов или забытые архивы.

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

Где прятались забытые архивы

Без лишних слов сразу покажу, что и где я нашел. Надо сказать, что этот мой блог на движке WordPress я редко посещаю, и за прошлый год опубликовал на нем всего лишь три статьи. Думаю, не стоит говорить, что его файлы на хостинге я проверяю еще реже. Тем не менее, в папке Uploads , рядом с папками, загруженных и отсортированных по месяцам, картинок, я обнаружил 19 zip архивов шаблонов и плагинов. Их я устанавливал когда-то в процессе всевозможных экспериментов по развитию этого блога. Причем большинство из этих плагинов и тем давно не используются и удалены. Полный путь к ним выглядел так: /public_html/wp-content/uploads .

Проверьте, может и у вас есть подобные лишние файлы. Кстати, интересно это узнать, так как на других своих сайтах я ничего лишнего не нашел. Хотя я примерно догадываюсь почему, но об этом позже. А пока соединяемся с хостингом по FTP с помощью и идем по указанному выше пути.

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

Теперь все выглядит аккуратненько, как и должно быть.

Освобождаем место в папке Uploads - удаляем лишние картинки

Кстати, как вы знаете, в той же папке Uploads на совершенно законных основаниях хранятся файлы изображений. Так вот, там тоже много мусора. Дело в том, что Вордпресс автоматически добавляет к вставляемым в посты картинкам 2-3 копии разных размеров. Поэтому неиспользуемые файлы можно удалить и, тем самым, значительно освободить дисковое пространство хостинга. Речь идет уже не о 9 МБ, а о сотнях и даже больше. Поверьте, лишние изображения занимают очень много места, особенно, если картинок большое количество. Вот, как это выглядит у меня на примере одного изображения.

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

Можно для удаления лишних картинок использовать специальный плагин DNUI Delete not used image .

Откуда взялись ненужные файлы?

Честно говоря, меня не особо волнует этот вопрос, но некоторые мысли есть. Скорее всего, эти архивы попадают в папку Uploads при установке тем и плагинов Вордпресс напрямую из админпанели. Раньше я пользовался именно этим способом. Архив загружается на хостинг, его файлы распаковывается в нужную папку, а он сам так и остается в папке загрузки.

Хотя сейчас попробовал для интереса установить пару плагинов через админку WordPress - ничего нового не появилось. К слову, мусорных файлов было не так много, так как за все время я устанавливал намного больше плагинов. Может не все из них оставляют после себя копии архивов? В любом случае, сейчас я загружаю файлы на хостинг через FTP соединение и ничего подобного не замечаю.

Какие у кого мысли на этот счет? Интересно, нашел еще кто-то в этой папке что-то не нужное? Поделитесь результатами своей проверки в комментариях.

Сергей Арсентьев

Как я провел чистку базы данных WordPress и оптимизировал ее в 7 раз

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

Буквально несколько дней назад я почистил свой блог и сайты клиентов по SEO , а сегодня уже добрался и до базы данных.

На самом деле, мне понравилось чистить свой блог

Итак, к делу.

База данных - это специальная область на сервере, где хранятся все материалы сайта, настройки, теги и прочая информация, к которой обращается программный скрипт для ее отображения на сайте.

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

Но почему она вообще засоряется?

Тут много моментов, но один из основных критериев, как я понял на своем опыте, из за того, что WordPress сохраняет:

• ревизии (редакции) всех страниц и записей,
• старые метатеги,
• черновики,
• спам,
• корзину и т.п.

То есть всевозможные материалы, даже те, которые уже никому не нужны и никогда больше не пригодятся.

То есть движок перестраховывается и на всякий случай стремится сохранить любую информацию пользователя доступными ему средствами - пока хватает ресурсов.

Это приводит к неэффективному использованию этих самых ресурсов, снижению производительности и повышению нагрузки на хостинг.

Кстати, нужно ли ее чистить всем подряд? Не уверен.
Если сайту пару месяцев, на нем десяток статей, то там особенно и оптимизировать нечего.

Другое дело - старый сайт или живущий активной жизнью блог.

Я приведу несколько критериев, каждый из которых сам по себе является весомым поводом, чтобы задуматься об очистке базы данных:

В этом случае прежде чем лезть в какие-то скрипты, почистите базу данных - возможно там уже скопилось много мусора.

Реально ли оптимизировать базу в WordPress в два клика

Как вы уже наверное поняли, я не сторонник сложных решений. У меня что ни статья, то все я стараюсь делать «в два клика» или «за пару минут».

Да, и еще.

Я ненавижу статьи типа «20 плагинов для WordPress по чистке базы данных». Их практическая польза равна нулю.

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

Но чтобы это сделать, нужно ведь сначала поставить эти 20 плагинов, определить, что 10 из них - полное херня, 5 - куда ни шло, но неудобные в использовании, еще 3 - тупо не заработали, и в конце концов 2 - то, что нужно, из них 1 - вообще огонь.

Конечно, проще выпустить банальный дайджест, пробежаться по верхам - типа этот плагин платный, этот бесплатный, этот русский, этот умеет то, этот сё. Типа, я тут «идеи накидал, а ты уже сам додумай».

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

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

С этим плагином реально почистить базу данных от мусора за пару минут.

Почему лично мне понадобилась чистка базы данных

Очищаем базу данных WordPress плагином

Из всего разнообразия плагинов мне сразу понравился Optimize Database after Deleting Revisions . Отличный плагин, на русском языке, плюс имеет встроенную возможность отключения ревизий.

Сохраняете, кликаете «Начать оптимизацию» и когда все будет готово (процесс обычно занимает от 10 до 60 секунд), вы увидите подробный отчет.

У меня изначально база данных в блоге занимала 112Мб:

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

А Optimize Database after Deleting Revisions ее очистил еще больше - до 21 Мб:

А вот посмотрите на сайте клиента, вообще не оптимизированном до этого - какая экономия:

И еще один клиент без оптимизации: