SQL запросы для улучшения WordPress — ч.2

Работа с Метками (tags)

Несмотря на то что WordPress предоставляет достаточно гибкий интерфейс управления метками, вам могут пригодится следующие SQL запросы.

Получаем пустые метки

Спустя несколько лет ведения блога, могут появится пустые метки — метки в которых нет записей. В поздних версиях WP такие метки можно удалить, на странице настроек меток, отсортировав их по количеству записей, а в ранних версиях так отсортировать не получится и для такой операции вам в помощь такой SQL запрос, который получит все метки в которых нет ни одной записи:

SELECT * FROM wp_terms wt
INNER JOIN wp_term_taxonomy wtt ON wt.term_id=wtt.term_id
WHERE wtt.taxonomy='post_tag' AND
wtt.COUNT=0

Вместо post_tag можно написать любую другую таксономию, например категории.

Удаляем пустые метки

В предыдущем примере мы получали пустые метки, а теперь просто удалим их:

DELETE a,b,c FROM wp_terms a
LEFT JOIN wp_term_taxonomy c ON a.term_id = c.term_id
LEFT JOIN wp_term_relationships b ON b.term_taxonomy_id = c.term_taxonomy_id
WHERE (
c.taxonomy = 'post_tag' AND
c.count = 0
)

Ну вы же понимаете, если изменить c.count = 0 на c.count < 2, то будут удалены все метки с 0 и 1 записями в них. Впрочем, про это у меня есть отдельная статья. Смена домена

Исправляем домен в опциях

При переезде на другой домен, помимо того, что нужно заменить домен везде где он встречается в шаблоне, также нужно изменить записи в Базе Данных в двух местах, в таблице опций (wp_options):

UPDATE wp_options SET option_value = 'http://site.ru/'
WHERE option_name = 'home' OR option_name = 'siteurl'

Запрос меняет значение полей siteurl и home. Не забудьте поменять site.ru на ваш новый домен!

Исправляем домен в записях

При смене домена, надо позаботится и о том, чтобы в постах были правильные внутренние ссылки, т.е. ссылки из статей на другие статьи блога, после смены домена станут битыми. Обычно конечно настраивается перенаправление со старого домена на новый в .htaccess или PHP с 301 редиректом, но помимо этого эстетически правильно, если в статьях не будет ссылок на старый домен. Этим запросом мы заменим все виды ссылок, включая ссылки на картинки:

UPDATE wp_posts
SET post_content = REPLACE (post_content, 'http://old-site.ru', 'http://new-site.ru')

old-site.ru и new-site.ru старый и новые домены, соответственно. Не забудьте изменить.

Аналогично можно поменять любую строку, например, слово Вордпресс на WordPress. См. пример ниже.

Меняем домен в произвольных полях

В произвольных полях также могут быть записи хранящие какие-либо УРЛы на старый домен, поэтому при смене домена возможно нужно заменить домен и в произвольных полях:

UPDATE wp_postmeta
SET meta_value = REPLACE (meta_value, 'http://old-site.ru','http://new-site.ru')

Редактируем GUID

При смене домена сайта желательно позаботиться о том, чтобы у всех записей поле guid в таблице wp_posts было корректное. Это поле используется как уникальный ID для идентификации записи в RSS ленте. Также, поговаривают, что оно нужно для корректного перенаправления с некорректных УРЛов, но это не так — я проверял, хе-хе.

UPDATE wp_posts
SET guid = REPLACE (guid, 'http://www.oldblog.ru', 'http://www.newblog.ru')

Для некоторых проектов я использую поле guid для других целей. Например, один товарищ додумался хранить в guid постоянную ссылку (permalink) на материал. Обычно Вордпресс делает этот пермалинк «на лету» из адреса сайта и всяких установок, включая название записи, по шаблону. Это загружает процессор и базу данных. Логично сгенерить пермалинк один раз и хранить его в базе готовый.

Чтобы в БД правильно записывались постоянные ссылки в поле guid, я сделал такой хак, для файла темы functions.php:

add_action( 'save_post', 'guid_write', 100 );
function guid_write( $id ){
if( defined('DOING_AUTOSAVE') && DOING_AUTOSAVE ) return false;

if( $id = intval($id) ){
global $wpdb;
$wpdb->update( $wpdb->posts, ['guid'=>/*wp_make_link_relative*/( get_permalink($id) ) ], ['ID'=>$id] );
}
}

Этот хак работает когда пост/страница публикуется, обновляется. Хак также срабатывает при удаленной публикации через xml-rpc. Таким образом, на вновь создаваемый сайт нужно вставить этот хак в файл темы functions.php и затем в шаблоне, в циклах вывода постов использовать не

а

guid ?>

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

echo get_permalinks();
echo get_permalinks($post->ID);
the_permalink();
the_permalink($post->ID);

на

echo $post->guid

Важно понимать, что, например, конструкции вида the_permalink(25); или the_permalink($post_id); , где $post_id устанавливается заранее, как ID какого-то поста, менять на echo $post->guid нельзя, потому что такие конструкции получают ссылки на определенный пост, а echo $post->guid выводит ссылку на пост, который в текущий момент находится в глобальной переменной $post.

Но это встречается редко. Впрочем, вернемся к нашему SQL.

Замена текста в записях (постах)

Можно заменить текст в постах и сделать это прямо в Базе Данных. Например можно добавить атрибут target=»blank» ко всем ссылкам с атрибутом rel=»nofollow»:

UPDATE wp_posts SET post_content = REPLACE (post_content, 'rel="nofollow"', 'target="blank" rel="nofollow"')

Еще можно проставить внутренние ссылки с определенным анкором, например, из слова «WordPress» сделать ссылку на какую-нибудь релевантную страницу, чтобы поднять её значимость. В прочем, для этого существуют специальные плагины, которые не трогают текст в БД, а создают ссылки на лету:

UPDATE wp_posts SET post_content = REPLACE (post_content, ' WordPress ', ' WordPress ')

Произвольные поля (postmeta)

Удаляем ненужные произвольные поля

Стоял плагин и создавал себе произвольные поля, как вдруг — он стал не нужен и вы его удалили, а осиротелые, никому не нужные произвольные поля остались в Базе Данных. В такой или подобной ситуации, все произвольные поля с названием, например «meta_name» можно удалить таким простым SQL запросом:

DELETE pm FROM wp_postmeta pm WHERE pm.meta_key = 'meta_name'

Если название произвольного поля (meta_name) в кириллице, то убедитесь, чтобы кодировка файла из которого будет производиться SQL запрос соответствовала кодировке блога (обычно UTF-8 без BOM).

Получим все произвольные поля с пустым значением

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

SELECT *
FROM wp_postmeta pm
LEFT JOIN wp_posts wp ON wp.ID = pm.post_id
WHERE wp.ID IS NULL

Меняем авторов постов

Вообще, приписывать свое имя под чужой статьей — не хорошо, поэтому в данном примере подразумевается, что вы сменили ник или купили весь контент с авторским правом и вам во что бы то не стало, нужно изменить авторство у статей. Чтобы поменять одного автора статьи на другого (оба пользователя должны быть зарегистрированы разумеется), можно использовать такой SQL запрос:

UPDATE wp_posts SET post_author=1 WHERE post_author=2
где, 1 — новый пользователь, 2 — старый. ID пользователей ищите в админке.

Удаляем ревизии (редакции) записей

По умолчанию в WordPress включены ревизии записей. Они засоряют базу данных и редко по-настоящему нужны. Если ревизии у вас включены, то я рекомендую очищать их хотя бы раз в год. Сделать это можно таким запросов в phpMyAdmin:

— зависимость с таксономиями
DELETE FROM wp_term_relationships WHERE object_id IN (SELECT ID FROM wp_posts WHERE post_type = 'revision');

— метаполя
DELETE FROM wp_postmeta WHERE post_id IN (SELECT ID FROM wp_posts WHERE post_type = 'revision');

— сами ревизии
DELETE FROM wp_posts WHERE post_type = 'revision';

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

Вариант 2 В качестве альтернативного запроса, можете воспользоваться таким. Это пример удаления с JOIN:

DELETE a,b,c,d
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
LEFT JOIN wp_comments d ON (a.ID = d.comment_post_ID)
WHERE a.post_type = 'revision'

Тут я также добавил удаление строк из таблицы wp_comments, мало ли вдруг в комментариях есть комменты которые относятся к ревизиям. Вообще их быть там не должно.

Деактивация всех плагинов

Бывают ситуации, когда невозможно зайти на страницу плагинов из-за одного некорректно работающего плагина. Такой плагин можно удалить через FTP, а можно просто деактивировать все плагины SQL запросом, что даст возможность войти на страницу настроек плагина:

UPDATE wp_options SET option_value = '' WHERE option_name = 'active_plugins'

Очистка кэша фида

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

DELETE FROM `wp_options` WHERE `option_name` LIKE ('_transient%_feed_%')

Ну и напоследок:

Получение названия всех колонок (полей) таблицы

SHOW COLUMNS FROM my_posts;

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

Настоящий материал самостоятельно опубликован в нашем сообществе пользователем proper на основании действующей редакции Пользовательского Соглашения. Если вы считаете, что такая публикация нарушает ваши авторские и/или смежные права, вам необходимо сообщить об этом администрации сайта на EMAIL abuse@newru.org с указанием адреса (URL) страницы, содержащей спорный материал. Нарушение будет в кратчайшие сроки устранено, виновные наказаны.

You may also like...


Комментарии