Работа с данными в WordPress. Часть 8: работа с таблицей опций в WordPress. Wordpress структура таблиц
База данных WordPress сайта | IT-блог о веб-технологиях, серверах, протоколах, базах данных, СУБД, SQL, компьютерных сетях, языках программирования и создание сайтов.
Здравствуйте, уважаемые посетители моего скромного блога для начинающих вебразработчиков и web мастеров ZametkiNaPolyah.ru. Продолжаем разговор о создании блога на WordPress. И сегодня мы поговорим о базе данных WordPress. Разберемся с сервером баз данных, который используется движком WordPress, какой тип движка использует база данных WordPress. Поговорим немного о таблицах базы данных WordPress, и на конец, мы рассмотрим структуру каждой таблицы.
База данных WordPress сайта
Для чего необходимо знать архитектуру базы данных этой системы управления сайтами? Как минимум, для общего развития. Большинству пользователей WordPress эта информация может показаться излишней и не нужной: простые посетители сайтов вряд ли заинтересуются этим вопросам, многие вебмастера, которые используют WordPress, не представляют себе то, как он работает изнутри, поэтому ставят кучу ненужных плагинов и расширений. Начинающим веб-разработчикам, использующим WordPress, как платформу для создания сайтов и блогов, информация из этого поста может показаться очень полезной и нужной.
data-ad-client="ca-pub-7858226296650173"data-ad-slot="1462109342">
Особенности работы базы данных WordPress
Содержание статьи:
И так, для начала следует сказать, что оригинал статьи на английском языке вы сможете найти на сайте кодекса WordPress. Ссылку была дана в статье, в которой писал про создание WordPress шаблона. Сразу скажу, что перевод статьи о базе данных WordPress не дословный, а вольный. Приступим.
Любому начинающему разработчику WordPress необходимо ознакомиться с двумя вещами: с технической документацией WordPress и с особенностями архитектуры базы данных, как минимум, для того чтобы уметь создавать сложные WordPress шаблоны и простенькие плагины, сегодня мы познакомимся с архитектурой базы данных сайта на WordPress.
Первое, что следует сказать: в качестве системы управления базами данных WordPress использует MySQL сервер версии 5.0.15 и выше (внимание: эта информация актуальна на момент написания публикации). Как я уже говорил: конечному пользователю информация о БД WordPress навряд ли когда-то пригодится, многим разработчикам для создания тем и плагинов WordPress будет достаточно набора функций WordPress для работы с базами данных, но иногда бывают ситуации, когда API WordPress недостаточно.
То есть, иногда возникает потребность обращаться к базам данных напрямую. Поэтому требуется информация о том, как WordPress хранит свои данные и какие есть зависимости и ограничения между таблицами базы данных WordPress. Чтобы обратиться к базам данных WordPress напрямую, следует использовать WPDB класс, но об этом не здесь. Перейдем к рассмотрению схемы и структуры базы данных WordPress.
Структура базы данных WordPress сайта
Ниже вы можете увидеть структуру базы данных WordPress, а также отношения и зависимости между таблицами базы данных. Обратите внимание: такую архитектуру база данных WordPress имеет при начальной установки без плагинов и расширений. База данных WordPress насчитывает 11 таблиц и 9 связей между таблицами: шесть не идентифицирующих и три идентифицирующих.
Архитектура базы данных WordPress
Обратите внимание: при стандартной установки WordPress целостность данных в базе данных обеспечивается не полностью, например, между записями вашего блога и комментариями. Если вы создаете сложный шаблон, плагин или расширение WordPress, то нужно самостоятельно заботиться о поддержании целостности данных в базе данных. Также не забывайте делать резервные копии базы данных WordPress, перед тем, как попытаетесь вносить изменение вручную.
Таблицы WordPress, откуда брать данные
Далее мы кратко рассмотрим все таблицы базы данных WordPress, обратите внимание: эта информация актуальна только для WordPress без расширений и плагинов, так как некоторые модули WordPress способных изменять, как архитектуру базы данных, так и содержимое некоторых таблиц.
| wp_commentmeta | Характеристики каждого комментария хранятся в таблице wp_commentmeta | Админка WP -> Комментарии |
| wp_comments | WordPress комментарии хранятся в таблице wp_comments | Админка WP ->Комментарии |
| wp_links | В таблице wp_links хранятся данные о ссылках WordPress | Админка WP -> Ссылки -> Добавить новую Админка WP -> Ссылки -> Ссылки |
| wp_options | Настройки WordPress хранятся в таблице wp_options | Админка WP -> Настройки -> Общие Админка WP -> Настройки -> Написание Админка WP -> Настройки -> Чтение Админка WP -> Настройки -> Обсуждение Админка WP -> Настройки -> Приватность Админка WP -> Настройки -> Постоянные ссылки Админка WP -> Настройки -> Виджеты |
| wp_postmeta | Характеристики каждой WordPress статьи находятся в таблице wp_postmeta. Некоторые плагины могут добавлять сюда собственную информацию | Админка WP -> Сообщения -> Добавить новое Админка WP -> Страницы -> Добавить новую |
| wp_posts | В таблице wp_posts хранится вся основная информация сайта: навигационное меню, тексты статей и страниц, и пр. | Админка WP -> Сообщения Админка WP -> Страницы Админка WP -> Сообщения -> Добавить новое Админка WP -> Страницы -> Добавить новую Админка WP -> Медиа -> Добавить новую Админка WP -> Медиа -> Библиотека Админка WP -> Оформление -> Меню |
| wp_terms | Категории для постов, тэгов и ссылок хранятся в этой таблице | Админка WP -> Сообщениия -> Тэги Админка WP -> Сообщениия -> Категории Админка WP -> Ссылки -> Ссылки категорий |
| wp_term_relationships | Данная таблица предназначена для хранения ассоциаций в WordPress | Админка WP -> Сообщениия Админка WP -> Страницы -> Добавить новую Админка WP -> Страницы |
| wp_term_taxonomy | В этой таблице хранится информация о таксономии WordPress. Меню категорий, ссылок и тэгов. Данные используются для записи в таблицу wp_terms. | |
| wp_usermeta | Мета-данные о пользователях WordPress хранятся в таблице wp_usermeta | Админка WP -> Пользователи |
| wp_users | Список бользователей WordPress хранится в таблице wp_users | Админка WP -> Пользователи |
Поля WordPress таблиц, идексы, ограничения и связи базы данных WordPress
Приведем подробное описание WordPress таблиц и связей между таблицами WordPress.
Описание таблицы wp_commentmeta базы данных WordPress
//
//
Индексы таблицы wp_commentmeta базы данных WordPress
Описание таблицы wp_comments базы данных WordPress
Индексы таблицы wp_comments базы данных WordPress
Описание таблицы wp_links базы данных WordPress
Индексы таблицы wp_links базы данных WordPress
Описание таблицы wp_options базы данных WordPress
Индексы таблицы wp_options базы данных WordPress
Описание таблицы wp_postmeta базы данных WordPress
Индексы таблицы wp_postmeta базы данных WordPress
Описание таблицы wp_posts базы данных WordPress
Индексы таблицы wp_posts базы данных WordPress
Описание таблицы wp_terms базы данных WordPress
Индексы таблицы wp_terms базы данных WordPress
Описание таблицы wp_terms_relationships базы данных WordPress
Индексы таблицы wp_terms_relationships базы данных WordPress
Описание таблицы wp_term_taxanomy базы данных WordPress
Индексы таблицы wp_term_taxanomy базы данных WordPress
Описание таблицы wp_usermeta базы данных WordPress
Индексы таблицы wp_usermeta базы данных WordPress
Описание таблицы wp_users базы данных WordPress
Индексы таблицы wp_users базы данных WordPress
Что же, на этом можно будет закончить описание архитектуры базы данных WordPress.
zametkinapolyah.ru
Работа с данными в WordPress. Часть 8: работа с таблицей опций в WordPress
В прошлых статьях серии мы рассмотрели таблицы в базе данных WordPress и отношения между ними.
В этой части мы рассмотрим таблицу, которая несколько отличается от всех остальных — wp_options. Как вы можете видеть на диаграмме ниже, это единственная таблица, которая расположена отдельно.
Таблица опций хранит в себе совершенно другой тип данных, отличающийся от остальных таблиц: вместо хранения данных о контенте вашего сайта она хранит в себе данные о самом сайте. Данные записываются в таблицу опций с помощью Options API или Settings API, которые состоят из набора функций, используемых для добавления, обновления или удаления данных из данной таблицы.
Вы можете добавлять значения к существующим опциям, вы можете добавлять новые записи в таблицу, если вы хотите создать новые опции.
В данном руководстве я рассмотрю разные аспекты таблицы опций, а также посмотрю на то, как взаимодействовать с ней:
- Доступ к таблице wp_options
- Структура таблицы wp_options
- Заполнение таблицы wp_options
- Options API
- Settings API
Я приведу краткий обзор этих API и покажу, как взаимодействовать с таблицей опций.
Доступ к таблице wp_options
Поскольку таблица wp_options хранит в себе данные, связанные с установкой сайта и его управлением в целом, доступ к ней ограничен. Чтобы менять настройки и опции, пользователи должны иметь возможность manage_options. Единственная стандартная пользовательская роль с данной возможностью – роль администратора (в мультисайтах: роль администратора сети).
Это означает следующее: если вам нужно добавить опции, к которым должен иметься доступ у других пользовательских ролей, вам нужно будет присвоить к ним возможность manage_options. Это достаточно рискованный шаг, поэтому обязательно обдумайте все его последствия!
Структура таблицы wp_options
Таблица опций имеет структуру, схожую с тремя таблицами метаданных. Она включает в себя четыре поля:
- option_ID
- option_name
- option_value
- autoload – определяет, загружены ли опции автоматически при каждом обновлении страницы; по умолчанию yes для отдельного сайта и no для мультисайтов.
Каждая запись в поле option_name будет представлять собой уникальное значение: если вы добавите более одного значения к опции, WordPress сохранит их в виде массива в поле option_value. Прекрасный пример этого: опция active_plugins, которая хранит массив плагинов, активированных на сайте.
При добавлении, редактировании или удалении данных в таблице wp_options вы должны всегда указывать option_name, что я покажу дальше в руководстве.
Заполнение таблицы wp_options
Таблица wp_options заполняется из следующих источников:
- Стандартная страница параметров
- Экран опций темы
- Экраны опций и параметров, добавленные с помощью плагинов
Есть много опций, встроенных в WordPress – вы можете видеть их в описании опций. Однако вы всегда можете создать свои собственные опции.
Чтобы создать новые опции в теме или плагине, вам нужно будет использовать Options API или Settings API. Я раскрою их более подробно чуть ниже.
Использование Options API
Options API состоит из восьми функций, которые позволяют вам добавлять, получать, обновлять или удалять опции:
| add_option() | $option, $value, $deprecated, $autoload | Обязателен только $option. Если уже есть запись с вашим параметром $option в качестве значения поля option_name, WordPress добавит ваше значение $value к массиву в поле option_value для этой записи, иначе будет создана новая запись. |
| delete_option() | $option | Удаляет все поля для данной опции |
| get_option() | $option, $default | $default (необязательный) – стандартное возвращаемое значение, если вместе с опцией нет сохраненных значений в базе данных. |
| update_option() | $option, $new_value | $new_value — значение, которое заполнит поле option_value |
| add_site_option() | $option, $value | Похоже на add_option(), но добавляет опции для всей сети в мультисайтах (т.е. опция хранится в таблице wp_options, а не в wp_XX_options, где XX — это ID сайта). $autoload не входит в опции сайта, не работает в мультисайтах и не может быть перезаписана. |
| delete_site_option() | $option | Аналогична delete_option(), но работает во всей сети в мультисайтах. |
| get_site_option() | $option, $default , $use_cache | Аналогична get_option(), но возвращает опции для всей сети в мультисайтах. |
| update_site_option() | $option, $value | Аналогична update_option(), но работает для всей сети в мультисайтах. |
Обратите внимание, что при создании опций либо через Options API, либо через Settings API, вы можете создавать записи без значений в поле option_value. Это дает возможность администраторам сайтам заполнять это поле позже.
Использование Settings API
Наряду с Options API, вы можете также использовать Settings API для взаимодействия с данными в таблице wp_options. Settings API позволяет вам создавать параметры, которые могут использовать администраторы сайта для добавления или обновления данных в таблице опций – к вашим опциям будет добавлен пользовательский интерфейс.
Settings API более мощный, чем Options API, поэтому я не смогу его в полной мере здесь раскрыть. У него имеется три базовых элемента:
- Параметр (данные из таблицы wp_options)
- Поле (которое используется для добавления или редактирования данных)
- Секция параметров, которая представляет собой группу связанных полей
Две функции в Settings API, которые взаимодействуют напрямую с таблицей wp_options:
| register_setting() | $option_group, $option_name, $sanitize_callback | Параметр $option_name связан с полем option_name в таблице wp_options; остальные параметры взаимодействуют с другими функциями в Settings API |
| unregister_setting() | $option_group, $option_name, $sanitize_callback | Отменяет регистрацию параметра в таблице wp_options — обычно используется с хуками деактивации в темах или плагинах. |
Эти функции не добавляют значений к опциям в таблице wp_options, однако они создают параметры, которые могут потом получать значения, добавленные к ним через другие функции в Settings API.
Заключение
Таблица wp_options выделяется среди остальных таблиц базы данных WordPress тем, что она не имеет отношений с другими таблицами. Это потому, что она хранит данные о сайте или сети, а не о контенте. Чтобы взаимодействовать с таблицей опций, вы можете использовать функции из Options API или Settings API. Также вы можете использовать функции, которые добавляют данные для всей сети в мультисайтовых сборках.
В заключительной части этой серии я рассмотрю мультисайты, поскольку они используют дополнительные таблицы БД, которые не были раскрыты ранее в этой серии.
Источник: code.tutsplus.com
oddstyle.ru
Структура базы данных блога WordPress. Press WordPress
WordPress, как современная система управления контентом, использует базу данных. Вся информация, которая хранится в ней, относится к блогу WordPress. Исходя из этого, можно сделать вывод, что структура БД пригодится Вам во многих случаях. Таких, как усовершенствования блога, создания шаблонов и тд.wp_postsWordPress это блоговая система управления контентом. Поэтому таблица с контентом играет не маловажную роль. Все страницы, аттачменты, записи хранятся в одной таблице WordPress wp_posts. Аттачменты хранятся в файловом виде на диске, но мета информация хранится в wp_posts.Записи, страницы и аттачменты могут быть похожи друг на друга, но все имеют уникальный ID, который создается автоматически.Чтобы понять, как используется каждое поле, надо посмотреть на данные в таблице, используя следующий код:
- SELECT * FROM wp_posts WHERE post_type = ‘post’ LIMIT 1
- SELECT * FROM wp_posts WHERE post_type = ‘page’ LIMIT 1
- SELECT * FROM wp_posts WHERE post_type = ‘attachment’ LIMIT 1
В этой таблице хранится информация о состоянии данных. Обычно это publish для опубликованных постов, draft - черновиков, inherit - аттачментов.
wp_postmeta Много вещей, которые Вы хотите проассоциировать со своим постом: название фильма, местоположение, информацию для поисковиков, и тд, хранятся в таблице wp_postmeta. Структура этой таблицы гибкая и простая и ей принадлежит всего 4-и поля: meta_key, meta_id, post_id и meta_value.
- meta_key – это описание(краткое).
- meta_id – ставится автоматом.
- post_id – берется с таблицы wp_posts.
- meta_value – значение мета информации.
WordPress сохраняет дополнительный данные об аттачментах в wp_postmeta таблицу, которые не могут быть сохранены в wp_posts.
wp_usersWordPress хранит в таблице wp_users информацию о зарегистрированных пользователях. В ней хранятся ID пользователя, имя, пароль, дата регистрации и тд.
wp_usermetaВ этой таблице хранится вся дополнительная информация о пользователях.
wp_commentsВ этой таблице хранятся комментарии к постам вашего блога. Имеет много полей, некоторые из низ приведены ниже:
- comment_ID - ID комментария, который создается автоматически.
- comment_post_ID - уникальный ID поста.
- comment_author – автор комментария.
- comment_author_email - email автора.
- comment_author_url - URL комментатора.
- comment_author_IP - IP-адрес автора.
- comment_date – время добавления комментария.
- comment_content - текст комментария.
- comment_approved – модерация.
- comment_agent - браузер комментатора.
- comment_type – тип комментария.
- user_id - ID автора.
wp_options
Таблица содержит все настройки WordPress блога. Похожа по структуре на wp_usermeta и wp_postmeta, но есть и различия. Поле blog_id используется только для WordPress MU, который использует его для отличия настроек разных блогов. Автоматически подгружаются большинство настроек.
wp_categoriesВ ней хранится информация о всех категориях, созданных Вами, например название и описание. Поле category_counter подсчитывает количество постов, добавленных к данной категории.
wp_post2catТаблица для связывания поста с категорией. Имеет всего 3-и поля: ID, ID поста, ID категории, в которую добавлен пост.
wp_linksХранится блогролл, список линок на другие блоги.
wp_link2catПочти идентична wp_post2cat, отличается тем, что в ней хранятся ID линок а не записей.
www.presswordpress.ru
Полезные SQL-запросы к базе данных wordpress (от 12 декабря 2013)
Про популярные 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
SQL — Structured Query Language — это специальный язык для манипуляций с данными. Мы не будем вдаваться в тонкости программирования, поэтому рассмотрим его в общих чертах, чтобы понимать, что именно делают полезные запросы, о которых ниже.
Нас будут интересовать три типа запросов:
1) SELECT — выборка данных. Обращаясь к каким-либо таблицам и задавая условия, мы можем получить от базы данных любую выборку. Например, все е-мэйлы комментаторов. Синтаксис такого запроса выглядит так:
SELECT что_выбрать FROM откуда_выбрать WHERE условия;
2) UPDATE — изменение данных. Точно также, как и для SELECT, изменить какую-то выборку данных, ограниченных условиями, то есть в общем случае изменяется множество строк таблицы за один раз. Синтаксис:
UPDATE изменяемая_таблица SET что_меняем = на_что_меняем WHERE условия;
3) DELETE — удаление данных. Будьте осторожнее с этим оператором, так как данные удаляются из таблиц насовсем. Единственное, что можно сделать, если вы нечаянно удалили лишнее — восстановить базу из резервной копии.
DELETE откуда_удалить WHERE условия;
Полезные запросы к БД вордпресс
Первое, что нужно сделать, когда вы хотите выполнить какой-то запрос, – это сохранить резервную копию ваших данных. Это можно сделать прямо в PhpMyAdmin, в разделе экспорт. Если ваш сайт достаточно большой, выберите способ компресси, например, zip.
Все запросы, о которых мы будем говорить далее, нужно запускать, пользуясь вкладкой SQL.
После выполнения запроса вы не должны видеть никаких сообщений об ошибке. (Если вы их видите, значит что-то пошло не так, и лучше восстановить резервную копию.) Результат выполнения запроса должен быть похож на:
Смена пароля wordpress
Если по какой-то причине вы потеряли доступ к админке сайта (например, он взломан) и восстановление на почту не работает, то вы можете поменять пароль с помощью запроса
UPDATE wp_users SET user_pass = '$P$BLIwZyiB0J2XvUAsNyKQI1hyEMox0A0', user_activation_key= '' WHERE user_login = 'admin'
UPDATE wp_users SET user_pass = '$P$BLIwZyiB0J2XvUAsNyKQI1hyEMox0A0', user_activation_key= '' WHERE user_login = 'admin' |
После выполнения такого запроса вы сможете зайти в админку с паролем 12345. Не забудьте сразу после входа с этим паролем поменять его на более сложный!
Что именно мы делаем? В поле user_pass таблицы wp_users хранится пароль в зашифрованном виде. Мы меняем его для пользователя с логином admin.
Если вы меняли логин, то вместо ‘admin’ в тексте запроса вы можете смело написать ваш логин.
Если же логин был заменен злоумышленником, то можно попробовать восстановить пароль по ID пользователя, а также вернуть первому пользователю имя admin.
UPDATE wp_users SET user_pass = '$P$BLIwZyiB0J2XvUAsNyKQI1hyEMox0A0', user_activation_key= '',user_login = 'admin' WHERE ID=1;
UPDATE wp_users SET user_pass = '$P$BLIwZyiB0J2XvUAsNyKQI1hyEMox0A0', user_activation_key= '',user_login = 'admin' WHERE ID=1; |
Кстати, в сети можно встретить множество запросов со сменой пароля с помощью функции MD5. Имейте ввиду, что такой метод не работает и уже довольно давно.
Смена логина wordpress
Если вам не нужно менять пароль, а хочется только сменить логин, то вам поможет следующий запрос:
UPDATE wp_users SET user_login='boss' WHERE user_login='admin'
UPDATE wp_users SET user_login='boss' WHERE user_login='admin' |
Здесь мы меняем логин пользователя admin на boss. В дальнейшем в админку можно входить по логину boss с тем же паролем, что был у admin.Закрыть комментарии в категории wordpress
Мы не будем рассматривать, как в принципе закрыть комментирование, потому что сейчаc это легко делается через админку сайта. А закрытие комментариев в какой-либо категории удобно сделать с помощью запроса.
UPDATE wp_posts p LEFT JOIN wp_term_relationships rel ON ( p.ID = rel.object_id ) LEFT JOIN wp_term_taxonomy tax ON ( tax.term_taxonomy_id = rel.term_taxonomy_id ) LEFT JOIN wp_terms tm ON ( tm.term_id = tax.term_id ) SET p.comment_status = 'closed' WHERE tm.slug = 'Uncategorized'
UPDATE wp_posts p LEFT JOIN wp_term_relationships rel ON ( p.ID = rel.object_id )
LEFT JOIN wp_term_taxonomy tax ON ( tax.term_taxonomy_id = rel.term_taxonomy_id )
LEFT JOIN wp_terms tm ON ( tm.term_id = tax.term_id )
SET p.comment_status = 'closed'
WHERE tm.slug = 'Uncategorized' |
Мы закрываем комментарии для категории Uncategorized. Вместо этого имени вы можете подставить любое свое название категрии. А если установить comment_status равным не ‘closed’, а ‘open’, комментарии будут открыты. Установка этого поля в значение ‘registered_only’ позволит комментировать только зарегистрированным пользователям.
Закрыть комментарии в старых постах wordpress
Аналогичным образом можно закрыть комментарии в старых постах.
UPDATE wp_posts SET comment_status = 'closed' WHERE post_date < '2013-01-01' AND post_status = 'publish'
UPDATE wp_posts SET comment_status = 'closed' WHERE post_date < '2013-01-01' AND post_status = 'publish' |
Здесь post_date – дата создания записи, и мы закроем комментарии ко всем опубликованным записям, созданным ранее 2013 года.Изменение сайта комментатора
Если комментаторы на сайте злоупотребили возможностью указать URL и понаписали туда всякого спама, то этот URL можно удалить. Давайте рассмотрим две ситуации:
1) Множество комментаторов с одинаковым URL
В таком случае удобнее всего заменить URL во всех комментариях разом
UPDATE wp_comments SET comment_author_url = REPLACE(comment_author_url, 'wordpress.org', 'sales-text.ru')
UPDATE wp_comments SET comment_author_url = REPLACE(comment_author_url, 'wordpress.org', 'sales-text.ru') |
Используя функцию REPLACE, мы заменяем адрес сайта ‘wordpress.org’ на ‘sales-text.ru’, независимо от того, кто оставил этот комментарий. Естественно, вместо ‘wordpress.org’ и ‘sales-text.ru’ можно подставить любые нужные вам слова.
2) Один комментатор, спамящий разными URL
UPDATE wp_comments SET comment_author_url = 'http://wordpress.org' WHERE comment_author = 'Mr WordPress' AND comment_author_email = '[email protected]'
UPDATE wp_comments SET comment_author_url = 'http://wordpress.org'
WHERE comment_author = 'Mr WordPress'
AND comment_author_email = '[email protected]' |
Таким образом, мы заменим адрес сайта комментатору Mr WordPress с e-mail [email protected] во всех его комментариях. В принципе, можно удалить из этого запроса последнюю строчку и не указывать e-mail, но тогда есть риск затронуть других комментаторов, если они указали то же имя (оно совершенно не обязано быть уникальным). И, естественно, вместо ‘http://wordpress.org’ можно указать любой другой сайт.
Собрать все e-mail комментаторов wordpress
Это можно сделать, используя совсем простой запрос.
SELECT DISTINCT comment_author_email FROM wp_comments
SELECT DISTINCT comment_author_email FROM wp_comments |
После его выполнения в PhpMyAdmin вы увидите выборку уникальных e-mail комментаторов. Отметив их все и воспользовавшись кнопкой Экспорт, вы можете сохранить их в файл и использовать в дальнейшем по собственному усмотрению.
Удаление уведомлений wordpress
Комментарии, которые уведомляют вас о том, что на вас кто-то сослался, часто бывают не нужны – популярные записи могут собирать огромное множество таких уведомлений. Если вы решили их удалить, это можно сделать с помощью такого запроса:
DELETE FROM wp_comments WHERE comment_type = 'pingback';
DELETE FROM wp_comments WHERE comment_type = 'pingback'; |
Pingback здесь обозначает, что комментарий является таким уведомлением.
Смена домена wordpress
Если вы хотите перенести сайт на новый домен, это также можно быстро и эффективно сделать с помощью запросов. (Если вы переносите сайт на новый хостинг, не забудьте предварительно скопировать туда все файлы. А также импортировать старую базу данных с помощью вкладки Импорт в PhpMyAdmin.)
Замена домена производится несколькими запросами. Первым делом нам надо откорректировать имя в настройках вордпресса – в таблице wp_option.
UPDATE wp_options SET option_value = 'http://new-site.ru/' WHERE option_name = 'home' OR option_name = 'siteurl'
UPDATE wp_options SET option_value = 'http://new-site.ru/' WHERE option_name = 'home' OR option_name = 'siteurl' |
Мы меняем значение двух опций – home и siteurl. Не забудьте вписать имя вашего нового домена вместо ‘http://new-site.ru/’.
Теперь нужно поменять имя домена в записях.
UPDATE wp_posts SET post_content = REPLACE (post_content, 'http://old-site.ru', 'http://new-site.ru')
UPDATE wp_posts SET post_content = REPLACE (post_content, 'http://old-site.ru', 'http://new-site.ru') |
Здесь и далее ‘http://old-site.ru’ – старое доменное имя, а ‘http://new-site.ru’ – новое, на которое мы заменяем.
Следующим пунктом надо исправить домен в произвольных полях.
UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, 'http://old-site.ru','http://new-site.ru')
UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, 'http://old-site.ru','http://new-site.ru') |
Осталось поправить только GUID.
UPDATE wp_posts SET guid = REPLACE (guid, 'http:// old-site.ru', 'http://new-site.ru')
UPDATE wp_posts SET guid = REPLACE (guid, 'http:// old-site.ru', 'http://new-site.ru') |
Готово! Замена домена выполнена!
Замена любого текста в записях wordpress
Также в записях можно поменять не только доменное имя, но и абсолютно любой текст. Например, вы захотели сделать во всех записях сайта из какого-то слова ссылку.
UPDATE wp_posts SET post_content = REPLACE (post_content, 'мой сайт', ' <a href="http://my-site.ru">мой сайт</a> ')
UPDATE wp_posts SET post_content = REPLACE (post_content, 'мой сайт', ' <a href="http://my-site.ru">мой сайт</a> ') |
Здесь мы делаем из слов ‘мой сайт’ ссылку на my-site.ru в поле post_content, которое содержит текст записи.
Аналогично можно заменить и что угодно другое. Синтаксис функции REPLACE такой:
REPLACE(имя_поля, что_меняем, на_что_меняем)
Удаление ревизий записей wordpress
По умолчанию в вордпрессе включены ревизии записи. (Ревизии – это промежуточные редакции записи.) Иногда они бывают нужны, и многие не хотят их отключать. А некоторые просто не знают о такой возможности. Тем временем, база сайта забивается огромным количеством этих ревизий и иногда для улучшения производительности сайта их следует удалять.
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'
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' |
Здесь мы удаляем все записи, и всю связанную с ними информацию, если их тип ‘revision’.
Деактивация всех плагинов wordpress
Иногда какой-то плагин работает некорректно, и на страницу их настройки зайти становится невозможно. Это можно исправить, не удаляя плагин физически, с помощью запроса, деактивирующего все плагины.
UPDATE wp_options SET option_value = '' WHERE option_name = 'active_plugins'
UPDATE wp_options SET option_value = '' WHERE option_name = 'active_plugins' |
Не забудьте после этого зайти в настройки плагинов и активировать те, которые нужны.
На этом всё. Если Вы хотите узнать, как выполнить какие-то другие полезные запросы – пишите в комментариях.
| Все материалы сайта созданы не корысти ради, а токмо волею пославшей меня жены на основе собственного опыта и лучших открытых/закрытых источников по интернет-бизнесу. Если Вам нравится то, что Вы здесь прочитали – покликайте по кнопкам расположенным ниже, поддержите проект.
Понравилась статья? Подпишитесь и читайте новые статьи на сайте сразу после публикации! |
Ещё записи по теме:
sales-text.ru
