20 самых необходимых SQL-запросов
Я недавно описывал плагин 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'; |
Добавляем ссылкам тегов rel="nofollow"
В продолжении темы о nofollow - теперь добавим rel="nofollow" для ссылок тегов. И тоже на этот раз не с помощью использования хака, а с помощью хука на вывод соответствующих функций. Зачем вообще запрещать индексацию тегов поисковиками я уже немного писал тут, но повторюсь. Теги плохи тем, что они дублируют контент в блоге. У вас может быть всего 50 записей в блоге, но благодаря тегам эти 50 записей запросто могут превратиться в 1000 страниц для поисковика, причем по его мнению ваш сайт будет набит дублированным контентом. Санкции за дублированный контент могут быть самыми разными - от фильтра до бана сайта в целом. Примеры и того и другого неоднократно проскакивали на форуме . С моей точки зрения, теги должны служить для удобства использования сайта посетителями, а не для решения SEO-задач. Поэтому я всегда первым делом при создании сайта запрещаю индексацию тегов в файле robots.txt, а через rel="nofollow" не даю растечься "весу" страницы на ссылки, запрещенные к индексации.
Добавляем ссылкам в блогролле rel="nofollow"
Два года назад я уже описывал хак, с помощью которого можно добавить rel="nofollow" в ссылки в блогролле блога. К сожалению, WordPress обрастает различной и зачастую избыточной функциональностью, а возможности указать свое собственное значение rel при добавлении или правке ссылок до сих пор не появилось. Хак, конечно, решает эту проблему, однако хакать WordPress становится утомительным занятием из-за постоянных апдейтов движка. Именно поэтому я ищу способы заменить описанные в этом блоге хаки на хуки, которые хранятся в файле functions.php вашего шаблона и сохраняются при апдейте WordPress на новую версию. В данной статье я приведу вам код, который добавит rel="nofollow" ссылкам в блогролле блога без правки файлов движка.
Вставка кода в комментариях
C самого начала работы этого блога я предусмотрел возможность вставлять в записи и комментарии код с помощью плагина WP-Syntax. Даже специально перед формой добавления комментария написал подсказку, как правильно использовать синтаксис вставки кода. Именно поэтому меня страшно раздражало, когда посетители вставляли код так, что половина его съедалась и я не мог понять о чем идет речь и как помочь комментирующему. Продолжалось это ровно до того момента, пока я не попытался сам ответить с кодом в комментарии, будучи не авторизован в блоге. К моему большому удивлению часть моего кода в комментарии оказалась испорченной. Как пример: вот из такого простого кода в комментарии: 
Я получил почему-то обрезок в виде: 
Все div'ы оказались вырезанными из комментария, даже несмотря на то, что их защищали теги pre (с тегами code тоже самое, кстати).
Вывод информации о нагрузке блога на WordPress
В последнее время меня стали спрашивать о том, как я вывожу в футере информацию о нагрузке блога при генерации страницы. Я имею ввиду число запросов к MySQL базе, время генерации страницы и число затраченной на это памяти. В основном, конечно, спрашивают о памяти, так как код показа числа запросов и времени генерации встроен в дефолтный шаблон WordPress, хоть по умолчанию и закомментирован. Сразу скажу, что память считается функцией memory_get_usage и я понятия не имею, как именно она работает. Скажем, не секрет, что последние версии WordPress даже при выделенных 32Мб памяти частенько не хотят работать, а поэтому число, выводимое функцией memory_get_usage ставит меня в тупик: во-первых, на локальном сервере функция выводит число потребляемой памяти раза в 4 большее, чем на хостинге и, во-вторых, в любом случае это число меньше 32Мб, без которых WordPress по сути работать не хочет. Вероятно, использование функции зависит от каких-то настроек сервера, но все мои поиски информации об этом не принесли никакого результата. Но, тем не менее, выводимое число потребляемой памяти можно использовать, как абстрактную величину: скажем, можно оценить насколько вырастает потребление памяти при включении какого-то плагина или генерация каких страниц блога у вас затрачивает наибольшее количество памяти.