Архив рубрики ‘ Программирование

20 самых необходимых SQL-запросов

Автор : Александр Самсонов {ник Flector}

Я недавно описывал плагин WordPress SQL Executioner, который позволяет выполнять SQL-запросы прямо из админки блога. Теперь же я приведу вам примеры самых нужных SQL-запросов для WordPress, которые могут очень сильно облегчить вам жизнь в случае каких-либо проблем.

1. Смена пароля

Забыли свой пароль администратора в блоге? Не беда, его легко можно сменить следующим запросом:

UPDATE wp_users SET user_pass = MD5('12345') WHERE ID=1;

Паролем тут будет «12345». Можно сменить пароль и для любого другого юзера в блоге, достаточно поменять в запросе ID, который у админа всегда равен 1. Можно также использовать запрос и с указанием конкретного логина:

UPDATE wp_users SET user_pass = MD5('12345') WHERE user_login = 'admin';

2. Смена логина администратора

По умолчанию в WordPress нельзя изменить логин администратора, который всегда будет «admin«. Это не слишком правильно с точки зрения безопасности, так как дает возможность злоумышленникам перебирать пароли для известного им имени администратора. Изменить логин админа можно запросом:

UPDATE wp_users SET user_login = 'test' WHERE user_login = 'admin';

Где «test» это новый логин администратора блога.

3. Смена урлов для WordPress и сайта

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

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

Где ‘http://www.testwp.ru/‘ это актуальный урл вашего сайта.

4. Удаление спам-комментариев

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

DELETE FROM wp_comments WHERE comment_approved = 0

5. Изменение GUID

При смене домена у сайта необходимо поменять значение GUID (globally unique identifier) в таблице wp_posts. Простой смены адреса сайта и WordPress в настройках блога недостаточно! GUID необходимо менять даже при переезде с localhost к хостеру.

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

Формально у вас все будет работать и без этого запроса, но смена GUID необходима, чтобы WordPress мог правильно перенаправлять с неправильных урлов записей на правильные.

6. Изменение URL в записях

Таким запросом можно поменять все ссылки в ваших записях на корректные.

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

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

7. Изменение автора записей

Чтобы изменить авторство записей с одного пользователя на другого используйте запрос:

UPDATE wp_posts SET post_author=New_Author_ID WHERE post_author=Old_Author_ID;

Где New_Author_ID это ID нового автора, а Old_Author_ID это ID старого автора.

8. Удаление ревизий записей

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

DELETE a,b,c 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)
WHERE a.post_type = 'revision'

Данный запрос не только удалит ненужные ревизии, но и всю meta-информацию, которая к ним привязана.

9. Удаление лишних Meta

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

DELETE FROM wp_postmeta WHERE meta_key = 'your-meta-key';

Где your-meta-key это и есть удаляемый meta-ключ. Например, плагин Another WordPress Meta Plugin хранит свою информацию в meta-ключе под названием «description«. При удалении этого плагина вся введенная информация остается в базе данных и удалить ее можно запросом:

DELETE FROM wp_postmeta WHERE meta_key = 'description';

10. Вывод неиспользуемых Meta

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

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

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

11. Собираем Email’ы комментаторов

Можно собрать базу имейлов из комментаторов вашего блога:

SELECT DISTINCT comment_author_email FROM wp_comments;

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

12. Удаление всех пингбеков

Иногда количество пингбеков слишком велико, их можно удалить все сразу:

DELETE FROM wp_comments WHERE comment_type = 'pingback';

13. Вывод неиспользуемых тегов

При удалении записи в блоге удаляется только сама запись. Теги же переходят в разряд неиспользуемых (если они были присвоены только этой одной удаляемой записи). Вывести список неиспользуемых тегов можно запросом:

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;

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

14. Деактивация всех плагинов сразу

Иногда при установке какого-либо плагина может возникнуть ситуация, при которой вы уже не можете войти в админку блога. Удалить некорректный плагин можно по ftp, а можно просто деактивировать все плагины, войти в админку и уже там удалить нужный плагин:

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

15. Удаление всех тегов

Уж не знаю зачем, но возможно вам понадобится удалить все теги сразу. Для этого используйте запрос:

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

16. Закрытие комментирования старых записей

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

UPDATE wp_posts SET comment_status = 'closed' WHERE post_date < '2011-01-01' AND post_status = 'publish';

Комментирование будет закрыто для всех записей, опубликованных раньше даты «2011-01-01«. Повторюсь опять, проще не закрывать комментирование, а закрыть саму возможность автоматического спама.

17. Изменение урла сайта комментатора

Данным кодом можно изменить ссылку на домашний сайт комментатора:

UPDATE wp_comments SET comment_author_url = REPLACE( comment_author_url, 'http://www.oldblog.ru', 'http://www.newblog.ru' );

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

18. Удаление комментариев по маске

Можно удалить комментарии со ссылками, содержащими определенное стоп-слово:

DELETE FROM wp_comments WHERE comment_author_url LIKE "%porno%" ;

При этом будут удалены все комментарии, у которых в качестве ссылки на домашний сайт комментатора указаны урлы со словом «porno».

19. Частные случаи замены текста

Замену текста в базе можно использовать совершенно для разных вещей. Например, если вы оформляли внешние ссылки в вашем блоге через rel=»nofollow», то можно автозаменой сделать все эти ссылки, открываемыми в новом окне браузера:

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

А можно наоборот, сделать все открываемые в новом окне браузера ссылки закрытыми через rel=»nofollow»:

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

20. Управление комментированием

Открыть все записи для комментирования:

UPDATE wp_posts SET comment_status = 'open';

Закрыть все записи для комментирования:

UPDATE wp_posts SET comment_status = 'closed';

Открыть комментирование только для зарегистрированных пользователей:

UPDATE wp_posts SET comment_status = 'registered_only';

На этом пока все. Надеюсь, что эти SQL-запросы вам помогут.

Рекомендую также:

Для чего служит .htaccess?

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

(пересылать) осуществляет веб-сервер. Наиболее популярных серверов два: IIS и Apache.

Как и любая программа, веб-сервер имеет определенные настройки. Но, у вас, как пользователя Апача может (и скорее всего не будет, если говорить о виртуальном

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

менять некоторые конфигурационные файлы, который распространяют свое действие только на ваш сайт. Один из таких файлов — .htaccess

Это файл гибкой настройки веб-сервера Апач. «Гибкий» обозначает, что как только вы поменяли что-то в этом файле, изменения тут же вступают в силу. С помощью

него можно переопределить многие директивы из файла httpd.conf (этот файл является главным конфигурационным файлом сервера Апач и его действия

распространяются полностью на всех пользователей данной копии Апача). В случаях, когда у вас нет доступа в файлу настройки Апача (тот же виртуальный

хостинг), вам поможет именно этот файл.

Этот файл не доступен веб-пользователю из браузера. Если файл .htaccess расположен в корневой директории сервера, то его действия распространяется на весь

сервер, кроме тех папок, где находится другой файл .htaccess (и кроме всех папок «ниже» этой папки со вторым .htaccess).

Пример:

Структура ваших директорий на сервере такая:

|-user

|
|—user1
|
|—user2
|-data

|
|—data1
|
|—data2

Директории user1 и user2 будут вложенными по отношению к директории user. Если мы поместим в директорию www файл .htaccess, то его действие будет

автоматически распространяться и на директории user1 и user2.

В директорию data помещаем другой файл .htaccess, по-сравнению, с тем, что находится в директории user. И для директорий data1 и data2 будет действовать файл

.htacсess, находящийся в data.

Теперь, в директорию user2 мы помещаем еще один файл .htaccess, который отличен от того, что находится в директории 2мя уровнями выше (это директория user). В

итоге, настройки для директории user2 будут определяться только тем файлом .htaccess, который находится в этой директории.

Так как чаще всего Апач настроен так, что всегда ищет этот файл в директории, то .htaccess поможет вам быстро и без останова сервера произвести его

перенастройку.

Синтаксис .htaccess

Вот обязательной синтаксис, несоблюдение которого приводит к ошибкам сервера:

— пути к файлам (директориям) указываются от корня сервера. Пример: /opt/home/www.astanafoto.com/htdocs/config/.htpasswords

— домены с указанием протокола

Пример: Redirect / http://www.site.ru

Файл имеет название именно «точка» htaccess

Должен быть записан в UNIX-формате. Для оболочки FAR, достигается F4 (редактирование файла), Shift+F2 (выбрать «сохранить как UNIX-текст»).

Как запретить веб-посетителям читать файлы в директории?

Запрет на все файлы:

deny from all

Где all обозначает «все».

Разрешить доступ с определенного ip:

order allow deny

deny from all

allow from «ваш ip»

В данном случае, «ваш ip» обозначает конкретный адрес. Например:

order allow deny

deny from all

allow from 192.126.12.199

Запретить доступ с определенного ip:

order allow deny

deny from all

deny from «ваш ip»

Использование «ваш ip» аналогично для примера выше.

Запрет на группу файлов по маске:

<files «\.(inc|sql|…другие расширения…)$»>

order allow,deny

deny from all

Определяет доступ к файлу по его расширению.

Например запрет на доступ к файлам с расширениям «inc» для веб-посетителей:

<files «\.(inc)$»>

order allow,deny

deny from all

В данном примере сам веб-сервер Апач может обращаться к файлам с таким расширениям.

Запрет на конкретный файл:

Можно поставить запрет на конкретный файл по его названию и расширению.

order allow,deny

deny from all

В данном примере стоит запрет на обращения к файлу config.inc.php.

Пароль на директорию:

AuthName «Private zone»

AuthType Basic

AuthUserFile /pub/home/твой_логин/.htpasswd

require valid-user

Значение AuthName будет выводиться для посетителя и может использоваться для пояснения запроса авторизации. Значение AuthUserFile указывает на место, где

хранится файл с паролями для доступа к данной директории. Этот файл создается специальной утилитой htpasswd.exe.

Например в директории, которую защищаем паролем создаем такой .htaccess:

AuthName «For Registered Users Only»

AuthType Basic

AuthUserFile /pub/site.ru/.htpasswd

require valid-user

В этом примере, посетитель при запросе директории, будет читать фразу «For Registered Users Only», файл с паролями для доступа должен лежать в директории

/pub/site.ru/ и называться .htapasswd . Директория указывается от корня сервера, если вы неправильно зададите директорию, то Апач не сможет прочитать файл

.htpasswd и никто не получит доступа к данной директории.

Пароль только на 1 файл:

Аналогично паролированию директории полностью, можно ставить пароль только на 1 файл.

Пример установки пароля на файл private.zip:

AuthName «Users zone»

AuthType Basic

AuthUserFile /pub/home/твой_логин/.htpasswd

Пароль на группу файлов:

Аналогично, используя , можно ставить пароли по маске файлов.

Пример установки пароля на доступ ко всем файла с расширением «sql»:

<files «\.(sql)$»>

AuthName «Users zone»

AuthType Basic

AuthUserFile /pub/home/твой_логин/.htpasswd

Проверка прав доступа

Задача: есть каталог a1 и в нем два вложенных каталога a2, a3, введено 2 уровня пользователей. 1 группа имеет доступ только к a1 и a2, 2-я ко всем трем каталогам.

Необходимо проводить аутентификацию только 1 раз — при доступе к a1, но при этом соблюдать права на доступ к а2 и а3.

Ник и пароль запрашиваются только при входе на а1 — если у юзвера есть доступ на а2 пароль уже не запрашивается. Если на а3 доступа нет, вылетит табличка

«введите пароль».

www.site.ru/a1

www.site.ru/a1/а2

www.site.ru/a1/a3

a1 — общий и вместе с тем закрытый. а2 и а3 только для отдельных личностей.

файл .htaccess для каталога а1:

AuthName «Input password»

AuthType Basic

AuthUserFile «/pub/home/login/htdocs/clousearea/.htpasswd»

require valid-user

файл .htaccess для каталога а2:

AuthName «Input password»

AuthType Basic

AuthUserFile «/pub/home/login/htdocs/clousearea/.htpasswd»

require user юзвер1 юзвер2 юзвер3

файл .htaccess для каталога а3:

AuthName «Input password»

AuthType Basic

AuthUserFile «/pub/home/абв/htdocs/clousearea/.htpasswd»

require user юзвер1 юзвер4 юзвер5

Как сделать перенаправление (редирект) посетителя?

Редирект на другой url:

Что бы сделать перенаправления посетителя на сайт http://site.ru в .htaccess Redirect / http://www.site.ru

Показ разных страниц, в зависимости от IP адреса посетителя:

SetEnvIf REMOTE_ADDR < нужный ip адрес> REDIR=»redir»

RewriteCond %{REDIR} redir

RewriteRule ^/$ /another_page.html

Например, перенаправление посетителей с ip адресом 192.12.131.1 на страницу about_my_sity.html:

SetEnvIf REMOTE_ADDR 192.12.131.1 REDIR=»redir»

RewriteCond %{REDIR} redir

RewriteRule ^/$ /about_my_sity.html

Перенаправление посетителя при запросе определенных страниц:

Это уже для всех сетевых вирусов и сканеров. Теперь любой запрос с адресом /_vti_bin будет автоматически перенаправляться на Microsoft:

redirect /_vti_bin http://www.microsoft.com

redirect /scripts http://www.microsoft.com

redirect /MSADC http://www.microsoft.com

redirect /c http://www.microsoft.com

redirect /d http://www.microsoft.com

redirect /_mem_bin http://www.microsoft.com

redirect /msadc http://www.microsoft.com

RedirectMatch (.*)\cmd.exe$ http://www.microsoft.com$1

Как сделать стартовой другую страницу?

Что бы поменять страницу, которая будет показываться при обращении к директории, пишем:

DirectoryIndex «нужная страница»

Можно указывать несколько страниц.

DirectoryIndex index.shtml index.php index.php3 index.html index.htm

Как заставить Апач выполнять в html документах php код?

Иногда бывает полезно «обмануть» посетителя, выдавая ему свои php-скрипты или иные файлы, как html файлы. Реально используется для индексации поисковой

системой Rambler php-скриптов. Некоторые делаю мелкие фишки, вроде того, что дают фалам расширения совпадающие с какими-либо «знаковыми» именами.

Например, на сайте www.osg.ru используются файлы с расширением osg: index.osg, script.osg и т.п.

RemoveHandler .html .htm

AddType application/x-httpd-php .php .htm .html .phtml

При большой посещаемости сервера может вызвать тормоза. Спрашивайте у админа.

Как самому обрабатывать ошибки Апача?

Наиболее интересные и полезные ошибки Апача это: 403-404, 500.

403 — пользователь не прошел аутентификацию, запрет на доступ (Forbided).

404 — запрашиваемый документ (файл, директория) не найден.

500 — внутренняя ошибка сервера (к примеру, ошибка в синтаксисе файла .htaccess).

Для того, что бы пользователю при этих ошибках были показаны ваши собственные сообщения об ошибках, в .htaccess пишем:

ErrorDocument 403 /errors/403.html

ErrorDocument 404 /errors/404.html

ErrorDocument 500 /errors/500.html

При этом при возникновении 404 ошибки пользователю загрузится файл errors/403.html.

Как поставить запрет на отображение содержимого директории при отсутствии индексного файла?

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

увидеть список всех ваших графических файлов. Конечно, это не нанесет вам урона, но можно и не дать такого просмотра посетителю. В .htaccess пишем:

Options -Indexes

Можно ли указать кодировку на все файлы, в которой по умолчанию получает документы браузер?

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

браузер выдавалась какая-то каша. Для избежания этого указываем, что все отдаваемые страницы будут иметь кодировку windows-1251:

AddDefaultCharset windows-1251

Можно ли указать кодировку на загружаемые файлы?

При загрузке посетителем файла на сервер, возможна перекодировка его — указываем, что все получаемые файлы будут иметь кодировку windows-1251:

CharsetSourceEnc windows-1251

Автор: нет данных