13 полезных SQL запросов для WordPress


Содержание

Полезные SQL запросы для WordPress

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

Для тех, кто хочет «повникать» в структуру БД WordPress и понять, что с чем связано, привожу схему.

Более детально об этом написано здесь: http://habrahabr.ru/post/233479/
Что бы вы понимал большинство плагинов цель которых справиться с рутинными действиями в один клик (например: удалить все теги, ревизии, комментарии и т.д) обычно могут обходиться всего одним запросом к БД.

Перед началом работы с базой данных следует сделать её дамп — на случай что что-то пойдет не так или нужно будет все вернуть обратно. Все действия я рекомендую делать в phpMyAdmin ну или в любом другом удобном Вам менеджере для работы с БД. Окно для вставки SQL-запросов в phpMyAdmin выглядит так:

По умолчанию WordPress использует префикс в БД «wp_» если вы назначили другой, то просто подкорректируйте нужный запрос к БД.

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

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

Распространенные SQL-запросы к базе данных WordPress

В статье идет речь о наиболее распространенных SQL-запросах к базе данных WordPress.

SQL-запросы, необходимые для переноса сайта WordPress на другой домен

  • https://site.ru — Старый домен.
  • https://newsite — Новый домен.

Если переносим с localhost то в файл wp-config добавляем:

SQL-запросы к базе данных WordPress для замены в полях таблицы

Шаблон для любых полей в отдельной таблице:

  • TABLE_NAME — Название таблицы.
  • FIELD_NAME — Название поля.

Замена текста в контенте:

Замена заголовков статей:

SQL-запросы к базе данных WordPress для переноса с HTTP на HTTPS протокол

Повторяем первый запрос, в котором переносили WordPress сайт со старого домена на новый? немного изменив его.

  • https://site.ru — Старый домен.
  • //site — Новый домен с HTTPS.

Помимо этого если вы переносите сайт с локального сервера — меняем все значения guid:

Если же сайт уже находился в интернете, а вы просто решили поменять домен — меняем guid только для вложений:

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

Один из плагинов для поиска и замены чего-либо в базе данных WordPress

Можно заменять вхождения в базе данных прямо из админпанели WordPress. Для этого существует несколько плагинов.

  • Better Search Replace.
  • Search & Replace.

Вполне подойдут для перехода сайта с HTTP на HTTPS.

SQL запросы для WordPress

WordPress хранит всю свою информацию в базе данных — в 99% случаев это MySQL, хотя этой СУБД дело не ограничивается. Сегодня я хочу рассказать, как можно делать некоторые рутинные операции, используя запросы SQL. Когда записей в блоге становится больше 50 — без этих запросов выполнить массовые операции становится очень долго и муторно.


Давайте определимся с терминами, чтобы всем было все понятно:

  • СУБД — система управления базами данных. В данном случае это MySQL
  • SQL — это я использую для краткости, подразумевая MySQL
  • SQL запрос — код, написанный на специальном языке запросов MySQL, который позволяет менять таблицы в базе данных.
  • phpMyAdmin — программа, позволяющая работать с базами данных MySQL

Если у вас несколько сотен записей в блоге и вы решили добавить настраиваемые поля (custom field) или свою таксономию — представляете, сколько записей вам нужно перелопатить, чтобы назначить каждой записи некоторое значение? А сколько времени на это уйдет?

В этом случае единственное решение — SQL запросы, которые напрямую меняют вашу базу данных.

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

Я не буду рассматривать синтаксис языка запросов MySQL — это обширная тема, которую не стоит изучать поверхностно. Если будет интересно — дайте знать в комментариях, я напишу подробную статью на эту тему. Вернемся к запросам и начнем с самого начала…

Как выполнить запрос SQL?

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

На иллюстрации показано, где нужно вводить код для исполнения.

Примеры SQL запросов, что я даю ниже, выполняются очень просто — копипастим в это окно и жмем «ОК». Система переспросит, уверены ли вы и при положительном ответе выполнит запрос, внеся изменения в БД. Собственно, на этом c phpMyAdmin закончим. Еще раз напоминаю о необходимости резервной копии вашей БД.

Примеры SQL запросов

Удаляем комментарии, помеченные как спам

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

Удаляем неодобренные комментарии

Этот код используется очень редко, но мало ли, пусть будет

Отключаем комментарии для записей, старше определенной даты

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

Параметр comment_status может принимать значение open, closed или registered_only. Ну и дата, посты старше которой необходимо обработать.

Включить или отключить трэкбэки и пингбэки для записей

Тут можно ping_status установить либо open, либо closed
Добавим небольшое уточнение запроса и отключим эту функциональность для записей старше определенной даты:

Дату устанавливаем такую, какая нужна.

Удаляем комментарии автора, содержащие определенный URL

Обратите внимание — между %% может быть часть URL и все комментарии автора, адрес которого содержит эту часть — будут улдалены. Допустим, вы укажете там выражение com, в этом случае запрос удалит не только site.com, но и comsite.ru. Будьте внимательны

Удаляем записи, старше Х дней

Не забывайте заменить Х на необходимую цифру дней.

Меняем тип записей со страницы на пост и наоборот

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

Для того, чтобы сделать наоборот, посты в страницы — просто меняем местами параметры

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

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

Записываем эту информацию и теперь, собственно, меняем автора:

Удаляем ревизии записей

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

Кстати, отключаются они добавлением в wp-config.php следующего кода


Отключаем все плагины

Иногда этот код может здорово выручить. После активации нового плагина, написанного нетрезвым разработчиком — вы видите белый экран и ничего не работает, войти в админку тоже нельзя. В этом случае два варианта — либо удалить виновника физически, через FTP, но это в том случае, если виновник известен. Либо использовать этот sql запрос.

Заменяем имя администратора

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

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

Меняем текст в записях

Бывает такое, что нужно массово заменить текст. Например, в том случае, если ваша компания поменяла название с «ЧП Зося» на «ООО Зося»

Меняем адреса картинок

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

Удаляем шорткоды

И еще один запрос по замене контента. Этот код я использовал всего пару раз, но его полезность сложно переоценить.
Он удаляет из текстов записей ненужные больше шорткоды. Самый распространенный вариант применения — у вас была тема, вы использовали ее шорткоды, вроде разделителей, кнопок и прочего. Заменили тему — на месте старых шорткодов будет обычный текст, вроде [twitter_button].

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

Заменяйте [twitter_button] на ваш шорткод и все.

Похожие записи

Drom, Kolya — подскажите название плагина. Я не встречал такого

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

Видел какой то плагин, который умеет выполнять sql-запросы прямо в админке WordPress, очень удобно, по крайней мере удобней отдельного окна phpmyadmin

Цукерберг рекомендует:  Node js - Node.js WebSocket основы

ZOng, нет, физически картинки таким образом не удалить. Можно почистить их пути в БД. Но удалять придется все таки руками

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

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

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

WordPress умеет работать как с Mysql так и с PostrgeSQL, соответственно и клиенты будут разные phpmyadmin и phppgmyadmin соответственно.
За подборку запросов спасибо, не разбираюсь в структуре таблиц wordpress, но будет что почитать )))

Очень классные советы даны в посте.

Как важно и как нужно! Сохраню закладочку и буду изучать потихоньку. Спасибо!

ДА, спасибо. Полезнейший пост. Сохраню себе, в будущем выручит наверно не раз.

Привет =)
Спасибо, давно искал информацию на эту тему!

Привет, Игорь
Отлично. Я давно собирался этот пост написать — вот наконец созрел ))

SQL запросы для WordPress

Приведу несколько примеров SQL запросов для базы данных WordPress, там где ‘TEXT’ укажите свои данные.

Изменение пароля пользователя:

Изменение логина пользователя:

Построение списка emailов комментаторов:

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

Включение комментариев для всех записей:

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


Удаление всех спам комментариев:

Удаление всех не одобренных комментариев:

Очистка значений поля URL у всех комментариев:

Закрытие комментариев в старых постах:

Закрытие комментариев в определенной рубрике:

Удаление комментариев в url которых встречается указанные символы:

Массовое изменение url комментатора:

Еще вариант массового изменения url комментаторов:

Массовое изменение имени комментатора:

Массовое изменение email комментатора:

Удаление всех комментариев от пингов:

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

Массовое изменение автора записей:

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

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

Пример поиска опубликованных статей в которых встречается указанный текст или символы:

полезные sql запросы wordpress

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

Для ввода SQL запросов необходимо зайти в панель phpMyAdmin. Заходим в панель управления хостингом и там находим пункт phpMyAdmin

phpMyAdmin в cPanel

Вот так выбираем phpMyAdmin в ISPmanager

Стрелкой указано поле для ввода SQL запросов. Потом нажимаем кнопку OK и смотрим изменения на сайте

sql запросы примеры

Как сменить пароль админа сайта

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

UPDATE wp_users SET user_pass = MD5(‘123456789’) WHERE >

Как несложно догадаться, паролем станет комбинация цифр «123456789».

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

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

Массово удаляем комментарии, помеченных как спам

Все достаточно просто. Данный SQL запрос удаляет из базы данных все комментарии, отмеченные как спам.

DELETE FROM wp_comments WHERE comment_approved = 0

Меняем значения GUID

Иногда вместе со сменой домена сайта возникает необходимость изменить и значение GUID (Globally Unique Identifier) в таблице wp_posts. Кроме того, его нужно сменить при переезде с локального сервера на хостинг.

Вообще-то, всё будет работать и так, но без этого WordPress не будет осуществлять перенаправление посетителей с неправильных URL на правильные.


«http://www.oldblog.kz» и «http://www.newblog.kz» необходимо сменить, соответственно, на старый и новый URL сайта.

Массовая смена URL в текстах статей

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

UPDATE wp_posts SET post_content = REPLACE (post_content, ‘http://www.oldblog.kz’, ‘http://www.newblog.kz’);

«http://www.oldblog.kz» и «http://www.newblog.kz» необходимо сменить, соответственно, на старую и новую ссылки.

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

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

Удаляем ревизий записей

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

DELETE a,b,c FROM wp_posts aLEFT JOIN wp_term_relationships b ON (a. >

Кроме того, этот запрос удалит и всю привязанную к ним META-информацию.

Удаляем META-данных, которые остаются после удаления плагинов

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

Для того чтобы удалить избыточную информацию из базы, воспользуемся вот таким SQL-запросом:

DELETE FROM wp_postmeta WHERE meta_key = ‘your-meta-key’;

Вместо your-meta-key подставьте нуждающийся в удалении META-ключ.

Смотрим пример использования запроса: плагин Another WordPress Meta Plugin хранит всю нужную ему в работе информацию в META-ключе «description». Для того чтобы удалить этот МЕТА-ключ, необходимо выполнить следующий SQL-запрос к базе данных:

DELETE FROM wp_postmeta WHERE meta_key = ‘description’;

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

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

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

UPDATE wp_options SET option_value = » WHERE option_name = ‘active_plugins’;

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

Отключаем функцию комментирования у старых записей

Если по какой-либо причине возникнет необходимость отключить возможность оставлять комментарии к старым записям, выполните этот SQL-запрос:

UPDATE wp_posts SET comment_status = ‘closed’ WHERE post_date

13 полезных SQL запросов для WordPress

IT, SEO, NET, C#, Design Pattern, Internet, Web 2.0, Юмор и о ж….

Страницы

Поиск

Рубрики

  • .NET (84)
  • 1С (3)
  • Blogging (103)

  • CSharp (54)
  • Design Patterns (8)
  • Интерфейс (9)
  • Истории (1)
  • Кино (64)
  • Книги (8)
  • Корпорация (91)
  • Мнения (78)
  • Новости (12)
  • Оффтоп (10)
  • Полезное (8)
  • Презентации (9)
  • Программы (62)
  • Статистика (1)
  • Экономика (1)
  • Юмор (87)
  • Я читаю (2)
  • Google (14)
  • IT (11)
  • Life (703)
  • Operating Systems (73)
  • Programming (108)
  • ROI (1)
  • SAP (12)
  • SEO (82)
  • SOA (23)
  • SOA and SaaS (2)
  • Sports (50)
  • Web 2.0 (65)
  • Web Design (49)
  • Архивы

    Посещений


    • 736 693 раз
  • Полезные MySQL запросы для WordPress

    Нередко бывает что необходимо выполнить какие-либо команды не прибегая к помощи админки WordPress. Все операции с БД можно выполнить непосредственно в админке базы phpMyAdmin. Вот например о том как посчитать количество записей MySQL.

    Приведу несколько полезных запросов для движка WP:

    • Если нужно массово запретить комментирование во всех постах:
      UPDATE wp_posts SET comment_status=’close’;
    • Если нужно массово разрешить комментирование во всех постах:
      UPDATE wp_posts SET comment_status=’open’;
    • Если необходимо разрешить комментирование во всех постах только зарегистрированным посетителям блога:
      UPDATE wp_posts SET comment_status=’registered_only’;
    • Если нужно массово запретить трэкбеки и пинги для всех постов:
      UPDATE wp_posts SET ping_status = ‘close’;
    • Удалить все посты:
    • DELETE FROM wp_posts WHERE post_type = “post”;
    • Если необходимо удалить не одобренные комментарии во всех записях:
      DELETE from wp_comments WHERE comment_approved = ’0′;
    • Удалить все драфты или ревизии постов
    • DELETE FROM wp_posts WHERE post_type = «revision»; или “draft”
    • Сброс пароля для пользователя:
    • UPDATE `wp_users`
      SET `user_pass` = MD5(‘PASSWORD’)
      WHERE `wp_users`.`user_login` =`admin` LIMIT 1;
    • Выводим колич-во запрос к БД:
    • queries in
      seconds.
    • Отрубаем все плагины:
    • UPDATE wp_options SET option_value = » WHERE option_name = ‘active_plugins’;
    • Запрещаем комментирование в старых постах:
    • UPDATE wp_posts SET comment_status = ‘closed’ WHERE post_date

    13 полезных SQL запросов для WordPress

    За последние 10 лет, база данных MySQL стала невероятно популярной в сети Интернет. Каждый WordPress-блог управляется MySQL базой данных, которая содержит посты блога, настройки, комментарии и многое другое.

    Хотя и имется достаточное плагинов с помощью которых можно решить некоторые проблемы, но иногда у вас нет другого выбора, кроме как выполнить SQL-команды в PhpMyAdmin или непосредственно в базе данных через SSH. Давайте взглянем на 8 полезных SQL-хаков для WordPress. Каждый раздел этого поста представляет собой проблему, предлагает решения и дает пояснения, которые помогут вам понять решение.

    1. Создаем резервную копию Вашей базы данных.

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

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

    1. Войти в PhpMyAdmin и выберите вашу базу данных WordPress.
    2. После этого нажмите кнопку «Экспорт», расположенных в горизонтальном меню.
    3. Выберите метод сжатия (лично я использую GZIP), и нажмите кнопку «Выполнить».
    4. Ваш браузер спросит вас, хотите ли вы скачать архив. Конечно, выберите «Да», а затем сохранить его на жестком диске.

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

    2. Удаляем ревизии постов (post revisions).

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

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

    1. Войти в PhpMyAdmin и выберите вашу базу данных WordPress.
    2. Нажмите кнопку «SQL». Вставьте следующий код в окно SQL команды:

    Разъяснение кода. Wp_posts таблица имеет поле post_type. Это поле может иметь одно из значений, таких, как «post», «page» или «revision». Если мы хотим избавиться от поста «revision», мы просто запускаем команду, чтобы удалить все элементы в таблице wp_posts, в которой поле post_type равно «revision».

    3. Удаляем 5000 спам-комментариев за секунду.

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

    Решение. К счастью, мой друг рассказал мне о своей проблеме со спамом. Он уже провел 45 минут вручную удаляя спам, когда я показал ему как это можно решить с помощью SQL.

    1. Войдите в PhpMyAdmin и выберите вашу базу данных WordPress.
    2. Нажмите кнопку «SQL». Вставьте следующий код в окно SQL команды:

    Пояснение. Wp_comments таблица содержит поле с именем comment_approved, которое содержит булево значение (1 или 0). Утвержденные комментарии имеют значение 1, а комментарии, ожидающие подтверждение модератора, имеют значение 0. Запустив этот скрипт, мы просто удаляем любые комментарии, которые не были еще утверждены.

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

    4. Изменяем атрибуты поста.

    Проблема. Когда вы устанавливаете WordPress, создается аккаунт «Администратор». Некоторые блоггеры делают ошибку, используя эту учетную запись, чтобы написать свои посты, а затем понимают, что лучше писать под своим именем, а не под именем безликого Администратора, существующего на каждом блоге.

    Решение. Изменять атрибут «автор» для каждого поста занимает много времени. К счастью, SQL может помочь вам добиться своей цели:

    1. Войдите в свой PhpMyAdmin и выберите вашу базу данных WordPress.
    2. Во-первых, мы должны получить ID всех пользователей. Чтобы сделать это, откройте командную строку SQL и выполните следующую команду:

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

    5. Вручную «сбрасываем» Ваш пароль.

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


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

    1. Войдите в свой PhpMyAdmin, выберите WordPress базы данных и откройте вкладку SQL.
    2. Вставьте следующую команду (предполагается, что ваше имя пользователя «Администратор»):

    Пояснение. Пароли пользователей хранятся в таблице wp_users. Для безопасность пароль закодирован. Мы должны создать «UPDATE» SQL-запрос и использовать встроенную MySQL функцию MD5() для преобразования вашего пароля в закодированный, а затем обновить его. «WHERE» условие гарантирует, что мы обновляем только пароль администратора, в противном случае обновяться все пароли!!

    6. Изменяем домен для WordPress.

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

    Решение.

    1. Как вы уже могли догадаться, первое, что необходимо сделать это войти в свой PhpMyAdmin и выбрать вашу базу данных WordPress.
    2. Нажмите кнопку «SQL». Для того чтобы изменить свой WordPress URL выполните эту команду:

    Пояснение. Чтобы быстро изменить наше доменное имя, я воспользовался супер-полезной MySQL-функцией «replace», которая позволяет заменить одно выражение на другое.

    7. Выводим на экран количество sql-запросов в Вашем блоге.

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

    Решение.

      На этот раз, не нужно заходить в PhpMyAdmin. Просто откройте файл footer.php в вашей теме и добавьте следующие строки кода:

    Пояснение. Похоже, что многим пользователям WordPress не известно об этой полезной функции. Функция get_num_queries() возвращает количество выполненных запросов во время загрузки страницы. Заметьте, что код будет отображать количество запросов только залогиненным пользователям, но если вы хотите сделать его видимым всем, просто удалите это условие — if(is_user_logged_in()).

    8. Восстанавливаем Вашу базу данных WordPress.

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

    Решение.

    1. Войдите в PhpMyAdmin и выберите вашу базу данных WordPress.
    2. Нажмите кнопку «Import» в горизонтальном меню.
    3. Нажмите кнопку «Browse» и выберите последнюю резервную копию базы данных на Вашем жестком диске.
    4. Нажмите кнопку «Execute». Если все прошло хорошо, ваша база данных полностью готова к работе.

    Если у Вас возникли вопросы, то для скорейшего получения ответа рекомендуем воспользоваться нашим форумом

    Полезные SQL-запросы к базе данных wordpress — что это и зачем?

    То, что Вам необходимо для начала:
    ЗАКАЖИТЕ КОНСУЛЬТАЦИЮ!

    Про популярные SQL-запросы к базе данных wordpress в поиске Яндекса и Гугла можно найти несколько статей. Большинство из них — рерайт одного англоязычного текста, которому уже много лет и который писался под старые версии вордпресса. Многие запросы из этих статей не работают. Я предлагаю выборку SQL-запросов, актуальных на 12 декабря 2013 года, протестированных для версии wordpress 3.7.1

    Если у вас есть сайт на WordPress, то иногда вы встречаетесь с задачами, которые неудобно, а то и невозможно, решать через панель управления. Но, даже если Ваш сайт взломан и Вы не можете попасть в админку (ситуация не самая типичная, но мне неоднократно встречалась), для многих проблем есть другой путь решения: SQL-запросы для wordpress. Для начала давайте разберемся, что это.

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

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

    ID — это номер записи, а post_author — ID автора и т.д.

    Структура базы данных и префиксы таблиц WordPress

    Теперь рассмотрим, что же именно хранится в наших таблицах.

    1) wp_posts — основная таблица, в которой хранится контент — записи, их название, авторство, дата создания, статус записи, разрешено ли комментирование и многое другое.

    2) wp_postmeta — дополнительные данные о записях, таки как прикрепленные файлы и произвольные поля, появляющиеся, например, при установке плагинов.

    3) wp_users — данные о всех пользователях сайта: их логины, пароли, электронная почта etc.

    4) wp_usermeta — профили пользователей и их настройки.

    5) wp_comments — комментарии для статей

    6) wp_commentmeta — дополнительная информация о комментариях, например, помечен ли комментарий как спам.

    7) wp_terms — категории и тэги, к которым может относиться статья.


    8) wp_term_taxonomy — в этой таблице хранится иерархия категорий, то есть она служит для построения дерева вложенности.

    9) wp_term_relationships — в этой таблице задается вхождение статьи в какую-либо категорию.

    10) wp_links — все ссылки (блогролл) и информацию о них.

    11) wp_options — все настройки вордпресса: и стандартные, и настройки плагинов.

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

    Нас будут интересовать три типа запросов:

    1) SELECT — выборка данных. Обращаясь к каким-либо таблицам и задавая условия, мы можем получить от базы данных любую выборку. Например, все е-мэйлы комментаторов. Синтаксис такого запроса выглядит так:

    SELECT что_выбрать FROM откуда_выбрать WHERE условия;

    2) UPDATE — изменение данных. Точно также, как и для SELECT, изменить какую-то выборку данных, ограниченных условиями, то есть в общем случае изменяется множество строк таблицы за один раз. Синтаксис:

    UPDATE изменяемая_таблица SET что_меняем = на_что_меняем WHERE условия;

    3) DELETE — удаление данных. Будьте осторожнее с этим оператором, так как данные удаляются из таблиц насовсем. Единственное, что можно сделать, если вы нечаянно удалили лишнее — восстановить базу из резервной копии.

    DELETE откуда_удалить WHERE условия;

    Полезные запросы к БД вордпресс

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

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

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

    Смена пароля wordpress

    Если по какой-то причине вы потеряли доступ к админке сайта (например, он взломан) и восстановление на почту не работает, то вы можете поменять пароль с помощью запроса

    WP Magazine

    Про WordPress на русском языке

    Отладка SQL запросов в WordPress с помощью Query Monitor

    При работе с такими API как WP_Query, Options, Metadata или с базой данных напрямую через объект $wpdb , важно помнить, что каждый SQL запрос влияет на время загрузки сайта. Плагин Query Monitor покажет вам все запросы в базу данных на текущей странице, их источник, время выполнения и многое другое.

    » data-medium-file=»https://wpmag.ru/wp-content/uploads/sites/13/2014/01/query-monitor-wordpress-300×99.png» data-large-file=»https://wpmag.ru/wp-content/uploads/sites/13/2014/01/query-monitor-wordpress-1024×339.png» src=»https://wpmag-22.cdn.pjtsu.com/wp-content/uploads/sites/13/2014/01/query-monitor-wordpress.png?w=780″ alt=»Плагин Query Monitor» w />

    Плагин Query Monitor

    После установки плагина Query Monitor в верхней панели WordPress появится новое меню, которое сразу отображает время генерации страницы, пиковое потребление памяти, время потраченное на все SQL запросы и количество запросов в базу данных MySQL на текущей странице.

    Подобная информация поможет сразу понять насколько тяжелой является текущая страница для сервера. Для сравнения, свежая установка WordPress потребляет порядка 18 мб памяти, около 20 SQL запросов за 3 миллисекунды и в среднем 250 миллисекунд для генерации главной страницы.

    При переходе в раздел Queries можно увидеть список всех SQL запросов в базу данных, их источник, компонент, количество найденых строк и время исполнения каждого запроса. Список легко отфильтровать по значениям Caller и Component.

    » data-medium-file=»https://wpmag.ru/wp-content/uploads/sites/13/2014/01/wordpress-query-monitor-sql-300×102.png» data-large-file=»https://wpmag.ru/wp-content/uploads/sites/13/2014/01/wordpress-query-monitor-sql-1024×350.png» src=»https://wpmag-22.cdn.pjtsu.com/wp-content/uploads/sites/13/2014/01/wordpress-query-monitor-sql.png?w=780″ alt=»Список SQL-запросов» w />

    Если вы заметили что какой-то из запросов в вашем коде занимает слишком много времени, или вызывается слишком часто, то возможно стоит оптимизировать функцию, которая его вызывает или же сам запрос. Начинать оптимизацию SQL запросов мы советуем с функции EXPLAIN в вашей консоли MySQL или phpMyAdmin.

    Кроме SQL-запросов в плагине Query Monitor есть разделы с условными тегами, с параметрами запроса WP_Query , со списком всех событий и фильтров на текущей странице и многое другое. Одной из самых интересных функций данного плагина является возможность установить специальный Cookie, который позволит просматривать информацию от имени любого пользователя или анонимно.

    Плагин Query Monitor является бесплатным, распространяется под лицензией GPL и доступен в официальной директории плагинов на сайте WordPress.org. Если вы ищите альтернативы или другие инструменты для отладки в WordPress, не забудьте попробовать плагин Debug Bar.

    Константин Ковшенин 13.01.2014 13.01.2014

    Сооснователь журнала WP Magazine и первой конференции WordCamp в России. Разработчик в компании Automattic, принимает активное участие в развитии ядра WordPress. Любимый язык программирования: Python.

    Подписаться на рассылку

    Подписаться → Подпишитесь на бесплатную рассылку журнала WP Magazine и получайте новости, события, подборки тем и плагинов, уроки, советы и многое другое в мире WordPress!


    Читайте также

    Mistape: бесплатный плагин для уведомления редакции об ошибках в тексте

    7 плагинов для сжатия изображений в WordPress

    Pageviews: простой счетчик просмотров для WordPress

    Кнопки поделиться в Telegram и WhatsApp для WordPress

    Спасибо за статью, попробую.

    Есть опечатка: «Начинать оптимизацию SQL запросы мы советуем с функции»
    Правильно: «Начинать оптимизацию SQL запросов мы советуем с функции»

    Шикарно, пойду тестировать!
    Логгирование запросов и ответов понятное дело само порождает некоторую нагрузку. Отсюда вопрос: плагин собирает информацию только по запросам порождённым определёнными посетителями?

    P.S. возможно кому-то будет интересна утилита mysql-proxy. Эта утилита прогоняет через себя обмен данными между mysql клиентом и сервером и может его обрабатывать, при-чём обработка задаётся скриптом на языке Lua (похож на JS) так-что видимо делать с запросами/ответами можно что угодно.

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

    О сколько нам открытий чудных… Оказывается БД вносила довольно незначительный вклад во время генерации страницы (только два плагина «отличились», да и то немного, «GD Star Rating» (его вообще странные люди писали) и AVH Extended Categories Widgets). Основной проблемой оказалась реализация gravatar из плагина WP User Avatar (не знаю подвержена-ли этому стандартная реализация WP (не уверен даже что она есть)), он при каждом запросе страницы с аватарами делал get запрос на сервера граватара для каждого не определённого аватара на странице. Мрак. Отключил ерись, время генерации снизилось на три четверти (программистам на заметку: сеть это очень медленно и ненадёжно, любая, всегда).

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

    Да, при работе с парой крупных проектов сталкивался с WP User Avatar и с GD Star Rating, оба плагина многие вещи делают не совсем правильно. Реализация Gravatar в ядре WordPress таких проблем не имеет.

    Может посоветуете что-то для профилирования phpшной части WP?

    Знаете, у нас пост в черновиках как раз на эту тему, постараемся опубликовать его на этой неделе :)

    о, если можно оставлять заявки на тематику будущих постов, то было бы интересно почитать про оптимизацию запросов к wp_postmeta
    для выборок вот такого типа:
    [code]
    $args = array(

    ‘relation’ => ‘AND’,
    ‘meta_query’ => array(
    array(
    ‘key’ => ‘rating’,
    ‘value’ => array(3, 4),
    ‘type’ => ‘numeric’,
    ‘compare’ => ‘BETWEEN’,
    ),
    array(
    ‘key’ => ‘votes’,
    ‘value’ => 50,
    ‘type’ => ‘numeric’,
    ‘compare’ => ‘>=’,
    )
    )
    );
    $query = new WP_Query($args);
    [/code]

    @dimasmagadan про meta_query мы уже писали, причем достаточно подробно, и тему производительности затронули. В комментариях есть так же интересная информация для размышления. Если будут вопросы — пишите!

    Эту статью видел. Показалось, что там только перепечаткаперевод документации
    По производительности советуется в основном так «настало время подключать внешнюю систему индексирования и поиска, например Sphinx или Elasticsearh». что не подходит (сайт на хостинге с старым ПО, обновитьсменить хостинг нельзя).

    в интернетах рекомендуют добавить индексы еще и вот так
    ALTER TABLE `wp_postmeta` ADD INDEX USING BTREE (meta_value(255));
    пишут, удалось ускорить в 3.5 раза, но тут же добавляют, что решение не идеальное.

    База больше гигабайта, вордпресс-часть примерно на 200мб, хочу делать выборки по 3-4 параметрам через meta_query. Использовать вместо произвольных полей таксономии не подходит.
    Сейчас делаю выборку только по одному полю. По нескольким тормозит.
    Ищу возможные способы ускорения запроса, без изменения структуры таблиц, установки дополнительного софта на сервер. Как-то так)

    Сайт на хостинге с старым ПО, обновитьсменить хостинг нельзя

    Боюсь у вас куда более важная проблема, чем запросы с мета-данными без изменения структуры таблиц :)

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

    Поэтому, как и на погоду за окном, на эту проблему решено не обращать внимание — придет весна (широкополосный интернет), снег растает (сменим хостинг, обновим ПО).

    А есть-ли способ без мороки заменить WP User Avatar на что-то более вменяемое с сохранением уже выбранных пользователями аватаров?

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

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

    И что посоветуете вместо WP User Avatar? Нужна установка аватаров пользователями, identicon и никаких запросов к внешним серверам (ну или какая-то волшебная реализация таких запросов которая не вносит ощутимого замедления).

    Я пока альтернативы не встречал, ну и особо не искал. Сервисы типа Gravatar и Identicon не делают запросов на внешние ресурсы с вашего сервера. Эти запросы выполняет клиент, поэтому на скорость работы вашего сервера и сайта это не влияет, но есть и ограничения, например Gravatar нельзя использовать во внутренней сети без выхода в Интернет.

    WP User Avatar плох тем, что он неправильно работает с сервисом Gravatar и делает к нему HTTP запросы с самого сервера, тем самым если у вас на странице 300 комментариев, то ваш сервер сделает 300 HTTP запросов :)

    Если найдете хорошую альтернативу — дайте знать!

    Крутая вещь, спасибо!

    Спасибо за плагин, уже оптимизировал несколько функций и пофиксил пару ошибок. GD Star Rating и Old Post Promoter «отличились», но без них пока нельзя.

    Интересный плагин :) как я уже упомянул, более простое это Sphinx/Elasticsearch.

    сфинкс и прочее не подходит :(

    сайт расположен на хостинге в Магадане. интернет в городеобласти дорогой, только через спутник, до сих пор процветают локальные сети. Поэтому основная масса пользователей — с местных локальных сеток.
    Конкурентовальтернативы хостеру нет. ВОЛС в область обещают уже который год как «вот в следующем году точно». Как-то мотивировать хостера обновить софт на сервере так же проблематично. Отсюда только старая версия php и всего остального.
    Подбирать версию сфинкса, которая запустится с хостингом у меня знаний не хватит.

    Проще видится переписать на использование дополнительных таблиц.
    В общем, печаль, уныние и безысходность :)

    Но за статью все равно спасибо, статья помогла найти плагин. Под свои проекты писать много кода лениво, часть кода скопипастю с плагина)

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

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

    основная масса аудитории — вот эти самые пользователи с «интранета»

    Ясно. К сожалению я не могу вам больше ничего посоветовать :) очевидно содержать свой маленький сервер тоже не вариант…

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

    Ух, не думал что такое в России ещё осталось. Во последние годы оптоволоконные сети расползаются быстро. На самом деле из такой изолированности тоже можно извлечь профит — не нужно конкурировать во всем миром. Такой локальный сервис может очень даже неплохо развиться. Главное помнить что рано или поздно оптика к вам придёт, и тогда выживут только те кто успеет развиться достаточно что-бы конкурировать со всем миром.

    та большая часть Дальнего Востока так живет — Магаданская область, Чукотка, местами Камчатка.

    Планов на захват мира через текущий сайт нет. Трезво смотрю на ситуацию. Как появится ВОЛС у проекта останется едва ли 10я часть пользователей. Вкладывать в развитие спорно — больше пользователей, чем сейчас на сайте не будет. В виду ограниченного количества этих самых пользователей) Они и так сейчас все на сайте есть)

    А конкуренции да, в нише нет: крупные конкуренты «не конкуренты» в силу отсутствия доступа к их сайтам у пользователей, с ново-появившимися «локальными» сайтами конкурировать просто — хороших специалистов там нет, сайты делаются на уровне скачать движок, поставить шаблон, функционал у таких сайтов от стандартного практически не отличается.
    Местным пользователям, в общем, деваться особо некуда, кому интересна тематика пользуются тем, что есть.

    У меня там сайт авто-тематики на WordPress с объявлениями. Так фильтр по цене на сайте я включил только этим летом. Висела реклама с оплатой за к-во просмотров, поэтому пользователям приходилось просматривать все страницы. Как рекламодатель сменил тип оплаты, устроил праздник пользователям — добавил фильтры).

    И такой подход, к сожалению, вполне привычен для пользователей. Такая же ситуация и в сфере обслуживания, и в магазинах. Дорого, низкого качества, за покупателем особо никто не гонится — ибо «куда он с подводной лодки денется».

    Совесть вот временами мучает, собираюсь как-нить взять и переписать) Но пока руки доходят только до мелких периодических правок. Те же правки какие-то внести тоже не просто. В прошлый раз 6 кб файл минут 40 заливался (подключаюсь по SCP, с компресией, клиент докачку поддерживает, но все равно не лезет). На днях вот провайдер внезапно перенастроил фаервол, мой ip оказался в блэк листе. Сейчас у них там уже суббота, что-то поменять получится не раньше понедельника-вторника)

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

    такой вот небольшой комментарий в виде экскурса на Колыму получился
    больше офтопить не буду)

    Распространенные SQL-запросы к базе данных WordPress

    В статье идет речь о наиболее распространенных SQL-запросах к базе данных WordPress.

    SQL-запросы, необходимые для переноса сайта WordPress на другой домен

    • https://site.ru — Старый домен.
    • https://newsite — Новый домен.

    Если переносим с localhost то в файл wp-config добавляем:

    SQL-запросы к базе данных WordPress для замены в полях таблицы

    Шаблон для любых полей в отдельной таблице:

    • TABLE_NAME — Название таблицы.
    • FIELD_NAME — Название поля.

    Замена текста в контенте:

    Замена заголовков статей:

    SQL-запросы к базе данных WordPress для переноса с HTTP на HTTPS протокол

    Повторяем первый запрос, в котором переносили WordPress сайт со старого домена на новый? немного изменив его.

    • https://site.ru — Старый домен.
    • //site — Новый домен с HTTPS.

    Помимо этого если вы переносите сайт с локального сервера — меняем все значения guid:

    Если же сайт уже находился в интернете, а вы просто решили поменять домен — меняем guid только для вложений:

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

    Один из плагинов для поиска и замены чего-либо в базе данных WordPress

    Можно заменять вхождения в базе данных прямо из админпанели WordPress. Для этого существует несколько плагинов.

    • Better Search Replace.
    • Search & Replace.

    Вполне подойдут для перехода сайта с HTTP на HTTPS.

    Цукерберг рекомендует:  Программирование - Нахождение всех сумм числа n.
  • Понравилась статья? Поделиться с друзьями:
    Все языки программирования для начинающих