WordPress работа с базой данных: Работаем с базой данных WordPress, с помощью класса wpdb

Понимание и работа с данными в WordPress. Часть 1. Введение / Хабр
Данная статья является переводом первой статьи Rachel McCollin из цикла о данных в WordPress. В ней по полочкам разложена структура данных, типы контента и их взаимосвязь в WordPress. Будет полезна в первую очередь новичкам, но и профессионалы могут найти для себя что-либо новое.
Замечание от переводчикаВ переводе используется терминология согласно кодексу WordPress

• Post — запись,
• Page — страница,
• Attachment — вложение,
• Revision — редакция,
• Comment — комментарий,
• Taxonomy — таксономия,
• Category — категория
• Tag — метка,
• Term — термин (конкретное значение пользовательской таксономии)
• User — пользователь
• Metadata — метаданные

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

Замечания об ошибках и опечатках прошу сообщать в личку.

Сайт на WordPress состоит из трех основных элементов:

• Сама установка WordPress
• Содержимое каталога wp-content, которое включает темы, плагины и загрузками
• База данных, где хранится контент в виде данных.

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

В этой серии статей будет детально рассмотрены аспекты базы данных WordPress. Эта серия состоит из девяти частей:

1. Вступление (сейчас вы читаете именно его)
2. Взаимосвязи между данными
3. Типы контента
4. Пользовательские данные
5. Метаданные
6. Таксономии, категории, метки и термины
7. Таксономии VS метаданные
8. Таблица опций
9. Данные WordPress Multisite

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

Типы контента в WordPress

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

• Записи (posts)
• Страницы (pages)
• Пользовательские типы записей (custom post types)
• Вложения (attachments)
• Ссылки (links)
• Элементы меню (navigation menu items)

Эти типы контента имеют такие данные:

• Категории (categories)
• Метки (tags)
• Пользовательские таксономии (custom taxonomies and terms)
• Метаданные (post metadata)

Кроме того существует типы контента, хранящиеся в ином виде:

• Виджеты (widgets)
• Опции (options)
• Пользователи (users)
• Сайты для MU WordPress
• Нестандартный контент (hardcoded content), который добавляют некоторые темы/плагины.
• Сторонний контент (third party content) (например RSS)

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

Структура базы данных WordPress

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

Большинство таблиц связаны с одной или несколькими другими с помощью одного поля. Это поле будет уникальным идентификатором для каждой записи (пример post_id). Более подробно для каждой таблицы:

Таблица	Данные	Связи с другими таблицами
wp_posts	Записи, страницы, вложения, редакции, пользовательские записи	wp_postmeta через post_id wp_term_relationships через post_id
wp_postmeta	Метаданные записей, страниц и т.д.	wp_posts через post_id
wp_comments	Комментарии	wp_posts через post_id
wp_commentmeta	Метаданные комментариев	wp_comments через comment_id
wp_term_relationships	Связи между таксономиями и записями, страницами и т.д.	wp_posts через post_id wp_term_taxonomy через term_taxonomy_id
wp_term_taxonomy	Таксономии (включая категории и метки)	wp_term_relationships через term_taxonomy_id
wp_terms	Ваши категории, метки и термины пользовательских таксономий	wp_term_taxonomy через term_id
wp_links	Ссылки в вашем блоке (как правило, сейчас не используется)	wp_term_relationships через link_id
wp_users	Пользователи	wp_posts через post_author
wp_user_meta	Метаданные для каждого пользователя	wp_users через user_id
wp_options	Опции и настройки сайта (устанавливаются в админке на странице настроек и в темах/плагинах)	Отсутвуют

Стоит отметить несколько вещей:

• Таблицы базы данных по умолчанию имеют префикс wp_. Вы можете его изменить (например, при установке).
• Таблица wp_posts является самой важно. Именно в ней храниться большинство данных.
• Только одна таблица не связанна с другими — таблица wp_options. В ней хранятся данные о сайте и настройках WordPress, которые не имеют отношения к записям или пользователям.
• Две таблицы используются для хранения данных о таксономии. Об это будет отдельная статья.
• В таблицах wp_users и wp_comments данные не связаны. В настройках WordPress можно указать, что только зарегистрированные пользователи могут оставить комментарий. Не смотря на это, WordPress не хранит связи о комментариях и пользователе, который их отправил.
• WordPress MU иметь некоторые дополнительные таблица. Их рассмотрение выходит за рамки данной статьи.

Связь контента и таблиц базы данных

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

Тип контента	Таблица
Записи (posts)	wp_posts
Страницы (pages)	wp_posts
Пользовательские типы записей (custom post types)	wp_posts
Вложения (attachments)	wp_posts
Ссылки (links)	wp_links
Элементы меню (navigation menu items)	wp_posts
Категории (categories)	wp_terms
Метки (tags)	wp_terms
Пользовательские таксономии (custom taxonomies)	wp_term_taxonomy
Термины пользовательских таксономий (custom terms)	wp_terms
Метаданные (post metadata)	wp_post_meta
Виджеты (widgets)	wp_options
Опции (options)	wp_options
Пользователи (users)	wp_users
Нестандартный контент (hardcoded content)	wp_posts (если добавлен к записям) wp_options (если добавлен к виджетам) Файлы тем/плагинов
Стороний контент (third party content)	wp_posts (если добавлен к записям) wp_options (если добавлен к виджетам) Файлы тем/плагинов

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

Заключение

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

Описание структуры базы данных « WordPress Codex

Languages: English • العربية • 日本語 中文(简体) • 한국어 • Русский • (Add your language)

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

WordPress поддерживает только MySQL версии 5.0.15 или выше, или любую версию MariaDB.

См. также предыдущие версии Описания Структуры Базы Данных для WordPress 1.5, WordPress 2.0, WordPress 2.2, WordPress 2.3, WordPress 2.5, WordPress 2.7, WordPress 2.8, WordPress 2.9 и WordPress 3.3.

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

Схема база данных

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

(Схема базы данных WP 4.4.2)

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

Обзор таблиц

В этом разделе представлен обзор всех таблиц, созданных во время стандартной установки WordPress. За этим следует конкретная информация о том, что находится в каждой таблице.

Таблицы WordPress 4.4 (12)
Имя таблицы	Описание	Соответствующие области пользовательского интерфейса WordPress
wp_commentmeta	У каждого комментария есть информация, называемая метаданные и она хранится в таблице wp_commentmeta.
wp_comments	В таблице wp_comments в WordPress хранятся собственно сами Комментарии.
wp_links	Таблица wp_links хранит информацию, относящуюся к ссылкам функциональность которых была введена как Links в WordPress. (Эта функциональность устарела, но её можно снова включить с помощью плагина Links Manager plugin.)
wp_options	Настройки, сделанные в Administration > Settings панели хранятся в таблице wp_options. Названия настроек option_name и их значения по умолчанию, см. в Option Reference.
wp_postmeta	У каждой записи есть информация, называемая метаданные и она хранится в таблице wp_postmeta. Некоторые плагины могут добавлять в эту таблицу их собственную информацию.
wp_posts	Самые важные данные в WordPress это записи. Они хранятся в таблице wp_posts. В этой таблице также хранятся Страницы и элементы меню навигации.
wp_terms	В таблице wp_terms хранятся категории как для записей так и для ссылок, а также теги для записей.
wp_termmeta	У каждого термина есть информация, называемая метаданные и она хранится в таблице wp_termmeta.
wp_term_relationships	Записи связываются с категориями и тегами с помощью таблицы wp_terms и эти связи обслуживаются в таблице wp_term_relationships. Связи ссылок с соответствующими их категориями, также хранятся в этой таблице.
wp_term_taxonomy	Эта таблица описывает таксономию (категорию, ссылку или тег) для записей в таблице wp_terms.
wp_usermeta	У каждого пользолвателя есть информация, называюемая метаданные и она хранится в таблице wp_usermeta.
wp_users	Списокпользователей обслуживается в таблице wp_users.

Подробное описание таблиц

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

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
meta_id	bigint(20) unsigned		PRI		auto_increment
comment_id	bigint(20) unsigned		IND	0
meta_key	varchar(255)	YES	IND	NULL
meta_value	longtext	YES		NULL

Индексы

Имя ключа	Тип	Поле
PRIMARY	PRIMARY	meta_id
comment_id	INDEX	comment_id
meta_key	INDEX	meta_key

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
comment_ID	bigint(20) unsigned		PRI		auto_increment
comment_post_ID	bigint(20) unsigned		IND	0
comment_author	tinytext
comment_author_email	varchar(100)		IND
comment_author_url	varchar(200)
comment_author_IP	varchar(100)
comment_date	datetime			0000-00-00 00:00:00
comment_date_gmt	datetime		IND & IND Pt2	0000-00-00 00:00:00
comment_content	text
comment_karma	int(11)			0
comment_approved	varchar(20)		IND Pt1	1
comment_agent	varchar(255)
comment_type	varchar(20)
comment_parent	bigint(20) unsigned		IND	0
user_id	bigint(20) unsigned			0

Индексы

Имя ключа	Тип	Поле
PRIMARY	PRIMARY	comment_ID
comment_post_ID	INDEX	comment_post_ID
comment_approved_date_gmt	INDEX	comment_approved comment_date_gmt
comment_date_gmt	INDEX	comment_date_gmt
comment_parent	INDEX	comment_parent
comment_author_email	INDEX	comment_author_email

Таблица: wp_links

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
link_id	bigint(20) unsigned		PRI		auto_increment
link_url	varchar(255)
link_name	varchar(255)
link_image	varchar(255)
link_target	varchar(25)
link_description	varchar(255)
link_visible	varchar(20)		IND	Y
link_owner	bigint(20) unsigned			1
link_rating	int(11)			0
link_updated	datetime			0000-00-00 00:00:00
link_rel	varchar(255)
link_notes	mediumtext
link_rss	varchar(255)

Индексы

Имя ключа	Тип	Поле
PRIMARY	PRIMARY	link_id
link_visible	INDEX	link_visible

Таблица: wp_options

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
option_id	bigint(20) unsigned		PRI		auto_increment
option_name	varchar(64)		UNI
option_value	longtext
autoload	varchar(20)			yes

Индексы

Имя ключа	Тип	Поле
PRIMARY	PRIMARY	option_id
option_name	UNIQUE	option_name

Таблица: wp_postmeta

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
meta_id	bigint(20) unsigned		PRI		auto_increment
post_id	bigint(20) unsigned		IND	0
meta_key	varchar(255)	YES	IND	NULL
meta_value	longtext	YES		NULL

Индексы

Имя ключа	Тип	Поле
PRIMARY	PRIMARY	meta_id
post_id	INDEX	post_id
meta_key	INDEX	meta_key

Таблица: wp_posts

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
ID	bigint(20) unsigned		PRI & IND Pt4		auto_increment
post_author	bigint(20) unsigned		IND	0
post_date	datetime		IND Pt3	0000-00-00 00:00:00
post_date_gmt	datetime			0000-00-00 00:00:00
post_content	longtext
post_title	text
post_excerpt	text
post_status	varchar(20)		IND PT2	publish
comment_status	varchar(20)			open
ping_status	varchar(20)			open
post_password	varchar(20)
post_name	varchar(200)		IND
to_ping	text
pinged	text
post_modified	datetime			0000-00-00 00:00:00
post_modified_gmt	datetime			0000-00-00 00:00:00
post_content_filtered	longtext
post_parent	bigint(20) unsigned		IND	0
guid	varchar(255)
menu_order	int(11)			0
post_type	varchar(20)		IND Pt1	post
post_mime_type	varchar(100)
comment_count	bigint(20)			0

Индексы

Имя ключа	Тип	Поле
PRIMARY	PRIMARY	ID
post_name	INDEX	post_name
type_status_date	INDEX	post_type post_status post_date ID
post_parent	INDEX	post_parent
post_author	INDEX	post_author

Таблица: wp_terms

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
term_id	bigint(20) unsigned		PRI		auto_increment
name	varchar(200)		IND
slug	varchar(200)		UNI
term_group	bigint(10)			0

Индексы

Имя ключа	Тип	Поле
PRIMARY	PRIMARY	term_id
slug	UNIQUE	slug
name	INDEX	name

Таблица: wp_termmeta

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
meta_id	bigint(20) unsigned		PRI		auto_increment
term_id	bigint(20) unsigned		IND	0
meta_key	varchar(255)	YES	IND	NULL
meta_value	longtext	YES		NULL

Индексы

Имя ключа	Тип	Поле
PRIMARY	PRIMARY	meta_id
term_id	INDEX	term_id
meta_key	INDEX	meta_key

Таблица: wp_term_relationships

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
object_id	bigint(20) unsigned		PRI Pt1	0
term_taxonomy_id	bigint(20) unsigned		PRI Pt2 & IND	0
term_order	int(11)			0

Индексы

Имя ключа	Тип	Поле
PRIMARY	PRIMARY	object_id term_taxonomy_id
term_taxonomy_id	INDEX	term_taxonomy_id

Таблица: wp_term_taxonomy

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
term_taxonomy_id	bigint(20) unsigned		PRI		auto_increment
term_id	bigint(20) unsigned		UNI Pt1	0
taxonomy	varchar(32)		UNI Pt2 & IND
description	longtext
parent	bigint(20) unsigned			0
count	bigint(20)			0

Индексы

Имя ключа	Тип	Поле
PRIMARY	PRIMARY	term_taxonomy_id
term_id_taxonomy	UNIQUE	term_id taxonomy
taxonomy	INDEX	taxonomy

Таблица: wp_usermeta

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
umeta_id	bigint(20) unsigned		PRI		auto_increment
user_id	bigint(20) unsigned		IND	0
meta_key	varchar(255)	Yes	IND	NULL
meta_value	longtext	Yes		NULL

Индексы

Имя ключа	Тип	Поле
PRIMARY	PRIMARY	umeta_id
user_id	INDEX	user_id
meta_key	INDEX	meta_key

Таблица: wp_users

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
ID	bigint(20) unsigned		PRI		auto_increment
user_login	varchar(60)		IND
user_pass	varchar(64)
user_nicename	varchar(50)		IND
user_email	varchar(100)
user_url	varchar(100)
user_registered	datetime			0000-00-00 00:00:00
user_activation_key	varchar(60)
user_status	int(11)			0
display_name	varchar(250)

ОБРАТИТЕ ВНИМАНИЕ: NOTE: Включение функции мультисайтов в WordPress добавляет два поля в таблицу wp_users: spam и deleted. См. Мультисайтовую версию.

Индексы

Имя ключа	Тип	Поле
PRIMARY	PRIMARY	ID
user_login_key	INDEX	user_login
user_nicename	INDEX	user_nicename

Обзор таблиц при работе фукнциональности мультисайтов

Этот раздел представляет собой обзор таблиц, созданных для использования с функциональностью мультисайтов в WordPress. Эти таблицы создаются с помощью процессов в разделе

Administration > Tools > Network.

Эти таблицы считаются многосайтовыми глобальными таблицами.

Мультисайтовые таблицы WordPress 3.0
Имя таблицы	Описание	Соответствующие области пользовательского интерфейса WordPress
wp_blogs	Каждый созданный сайт хранятся в таблице wp_blogs.
wp_blog_versions	Состояние текущей версии базы данных каждого сайта обслуживается в таблице wp_blogs_versions и обновляется для каждого сайта при его обновлении.
wp_registration_log	Когда администратор создаёт новый сайт, в таблице wp_registration_log создаются соответствующие записи.
wp_signups	Эта таблица содержит пользователя, который зарегистрировался на сайте через процесс регистрации. Регистрация пользователей включается в Administration > Super Admin > Options.
wp_site	Таблица wp_site содержит адрес главного сайта.
wp_sitemeta	У каждого сайта есть информация, называемая данные сайта и она хранится в таблице wp_sitemeta. Также в этой таблице хранится различная информация, связанная с настройкой, включая администратора сайта.
wp_users	Список всех пользователей обслуживается в таблице wp_users. Мультисайтовость добавляет два поля, которых нет в обычной версии.
wp_usermeta	Данная таблица не пересоздаётся для мультисайтовости, но мета данные пользователей для каждого сайта, хранятся в wp_usermeta.
Site Specific Tables	Данные основного сайта хранятся в существующих ненумерованных таблицах. Данные дополнительных сайтов хранятся в новых пронумерованных таблицах.

Подробное описание мультисайтовых таблиц

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

Таблица: wp_blogs

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
blog_id	bigint(20)		PRI		auto_increment
site_id	bigint(20)			0
domain	varchar(200)		IND Pt1
path	varchar(100)		IND Pt2
registered	datetime			0000-00-00 00:00:00
last_updated	datetime			0000-00-00 00:00:00
public	tinyint(2)			1
archived	tinyint(2)			0
mature	tinyint(2)			0
spam	tinyint(2)			0
deleted	tinyint(2)			0
lang_id	int(11)		IND	0

ПРИМЕЧАНИЕ: blog_id идентифицирует сайт, а site_id идентифицирует сеть. Это след прошлого, когда ‘сайт’ назывался ‘блог’ в WordPress 2.x. Если вы добавите свой сайт в сеть, новая запись будет добавлена в таблицу wp_blogs с увеличенным значением blog_id и тем же самым site_id.

Индексы

Имя ключа	Тип	Поле
PRIMARY	PRIMARY	blog_id
domain	INDEX	domain path
lang_id	INDEX	lang_id

Таблица: wp_blog_versions

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
blog_id	bigint(20)		PRI	0
db_version	varchar(20)		IND
last_updated	datetime			0000-00-00 00:00:00

Индексы

Имя ключа	Тип	Поле
PRIMARY	PRIMARY	blog_id
db_version	INDEX	db_version

Таблица: wp_registration_log

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
ID	bigint(20)		PRI		auto_increment
email	varchar(255)
IP	varchar(30)		IND
blog_id	bigint(20)			0
date_registered	datetime			0000-00-00 00:00:00

Индексы

Имя ключа	Тип	Поле
PRIMARY	PRIMARY	ID
IP	INDEX	IP

Таблица: wp_signups

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
signup_id	bigint(20)		PRI		auto_increment
domain	varchar(200)		IND Pt1
path	varchar(100)		IND Pt2
title	longtext
user_login	varchar(60)		IND Pt1
user_email	varchar(100)		IND & IND Pt2
registered	datetime			0000-00-00 00:00:00
activated	datetime			0000-00-00 00:00:00
active	tinyint(1)
activation_key	varchar(50)		IND
meta	longtext	Yes		NULL

Индексы

Имя ключа	Тип	Поле
signup_id	PRIMARY	signup_id
activation_key	INDEX	activation_key
user_email	INDEX	user_email
user_login_email	INDEX	user_login user_email
domain_path	INDEX	domain path

Таблица: wp_site

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
id	bigint(20)		PRI		auto_increment
domain	varchar(200)		IND Pt1
path	varchar(100)		IND Pt2

Индексы

Имя ключа	Тип	Поле
PRIMARY	PRIMARY	id
domain	INDEX	domain path

Таблица: wp_sitemeta

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
meta_id	bigint(20)		PRI		auto_increment
site_id	bigint(20)			0
meta_key	varchar(255)	Yes	IND	NULL
meta_value	longtext	Yes	IND	NULL

Индексы

Имя ключа	Тип	Поле
PRIMARY	PRIMARY	meta_id
meta_key	INDEX	meta_key
site_id	INDEX	site_id

Таблица: wp_users

Поле	Тип	Null	Ключ	Умолчание	Дополнительно
ID	bigint(20) unsigned		PRI		auto_increment
user_login	varchar(60)		IND
user_pass	varchar(64)
user_nicename	varchar(50)		IND
user_email	varchar(100)
user_url	varchar(100)
user_registered	datetime			0000-00-00 00:00:00
user_activation_key	varchar(60)
user_status	int(11)			0
display_name	varchar(250)
spam	tinyint(2)			0
deleted	tinyint(2)			0

Индексы

Имя ключа	Тип	Поле
PRIMARY	PRIMARY	ID
user_login_key	INDEX	user_login
user_nicename	INDEX	user_nicename

Специфичные таблицы для сайта

Когда создается новый дополнительный сайт, создаются таблицы, специфичные для сайта, аналогичные стандартным таблицам выше. Каждый набор таблиц для сайта создается с идентификатором сайта (blog_id) как частью имени таблицы. Это таблицы, которые должны быть созданы для идентификатора сайта 2 и table_prefix wp_:

Данные главного сайта хранятся в ненумерованных таблицах.

Исходный файл

Структура базы данных определяется в wp-admin/includes/schema.php

Ресурсы

Changelog

• 4.2.2 :
  • termmeta table: New table to house term related data.
  • Database Diagram: Added the new diagram including the wp_termmeta table.

• 2.8 :
  • comments table: Changed comment_post_ID column from int(11) to bigint(20) unsigned.
  • links table: Deleted link_category column. Changed link_owner column from int(11) to bigint(20) unsigned.
  • posts table: Deleted post_category column.
  • term_taxonomy table: Added KEY taxonomy.
  • Add unsigned attribute to various bigint(20) fields.

База данных WordPress

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

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

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

Внимание! Любое изменение базы данных может привести к необратимым последствиям и нарушению работы сайта. Все действия выполняются на свой страх и риск. Обязательно делайте резервное копирование!

Поэтому я решил исправить ситуацию и перенести комментарий на другую релевантную страницу 😉 В базе данных в таблице wp_comments я нашёл этот комментарий и отредактировал строку таблицы, изменив значение поля comment_post_ID. Просто сменил ID записи к которой был отправлен комментарий на ID другой записи. После сохранения изменений в базе данных комментарий был успешно перенесён на другую страницу.

Таблицы, из которых состоит база данных WordPress

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

Стандартный префикс wp_ при установке WordPress допускается не изменять. Если планируете создавать несколько сайтов с использованием одной общей базой данных, то обязательно для каждой установки задавайте разный префикс для таблиц 💡

1. wp_commentmeta
2. wp_comments
3. wp_links
4. wp_options
5. wp_postmeta
6. wp_posts
7. wp_termmeta
8. wp_terms
9. wp_term_relationships
10. wp_term_taxonomy
11. wp_usermeta
12. wp_users

Обратите внимание, если ваши таблицы не совпадают с моим списком, их больше или, наоборот, меньше, то причиной может оказаться несколько вариантов:

• Установлена другая версия WordPress. На момент последнего редактирования текущей статьи актуальной версией является 5.0. Настоятельно рекомендую своевременно обновлять CMS.
• Установлены плагины, которые создали в базе данных свои таблицы. Плагины также меняют содержимое таблиц, добавляя новые поля, строки и т.д.
• В процессе установки WordPress был изменён стандартный префикс таблиц.

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

Описание и предназначение таблиц базы данных

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

Таблица wp_commentmeta

Каждый комментарий, оставленный на сайте, содержит метаданные — эта информация хранится в этой таблице. Например, если установлен плагин Akismet для защиты от спама, то он будет записывать в неё свои данные: одобрен комментарий или нет, имеется ли пометка о спаме.

Таблица wp_comments

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

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

Таблица wp_links

Эта таблица раньше хранила ссылки блогролла на Кодекс, wordpress.org и другие ресурсы. На блоге у меня были удалены все ссылки из консоли, поэтому на скриншоте ниже есть надпись «Ссылок не найдено», а таблица пуста.

Теперь эта функция устарела, но при необходимости её можно включить с помощью плагина Links Manager.

Таблица wp_options

Хранит основные настройки WordPress, в том числе параметры, доступные для изменения в консоли администрирования. Кстати, таблица wp_options очень интересна для изучения, но зачастую после установки и последующего удаления плагинов содержит лишние строки. У меня есть отличное руководство по чистке базы данных от «мусора».

Таблица wp_postmeta

Хранит огромное количество данных о записях и страницах сайта: информацию о прикреплённых файлах (изображения, документы, видео), данные заполняемых полей при создании или редактировании записей. Некоторые плагины могут добавлять свою собственную информацию в эту таблицу. Например, плагин All in One SEO Pack хранит здесь Title, Description и Keywords.

Таблица wp_posts

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

Таблица wp_termmeta

Каждый термин (категории, метки и термины пользовательских таксономий) содержит информацию, называемую метаданными, и хранится в этой таблице. Скриншот не прилагаю, так как у меня эта таблица оказалась пустой. Метки и пользовательские таксономии при этом не использую.

Таблица wp_terms

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

Таблица wp_term_relationships

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

Таблица wp_term_taxonomy

В этой таблице описаны таксономии (категории, теги) для записей в таблице wp_terms. Устанавливается очередность и вложенность категорий, которые могут быть родительскими и дочерними, вот таблица wp_term_taxonomy и отслеживает иерархию между ними.

Таблица wp_usermeta

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

Таблица wp_users

И, наконец, на очереди последняя таблица — wp_users. Она содержит список зарегистрированных пользователей, их логин и пароль в зашифрованном виде, e-mail адрес, дату регистрации и другие сведения.

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

Как экспортировать пользователей WordPress: работа с базой данных

От автора

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

Зачем нужно экспортировать пользователей WordPress

Я вижу три задачи, для чего нужно экспортировать пользователей WordPress.

1.Экспорт содержимого сайта не предполагает перенос пользователей. Имеется в виду не перенос сайта с хостинга на хостинг, а перенос содержания одного сайта WordPress на другой сайт WordPress. При операции Экспорт-Импорт, на новом сайте выбирается (или создается) новый пользователь, которому и прикрепляется всё переносимое содержание. Перенос пользователей инструментами экспорт-импорт не производится и только самостоятельный экспорт поможет перенести пользователей сайта. Внутренний инструмент экспорта wordpress 2.Экспортировать пользователей можно не только на другой сайт WordPress. Можно сделать экспорт в свои подписные листы на почтовых сервисах для создания качественных рассылок. 3. Экспортировав пользователей можно ими обмениваться, объединять пользователей с разных сайтов, редактировать списки независимо от сайта и т.д.

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

Экспорт пользователей из базы данных WordPress

Экспортировать своих пользователей WordPress будем через phpmyadmin своего хостинга. Авторизуемся в phpmyadmin и  открываем базу данных своего WordPress.

авторизуемся в phpmyadmin

Напоминаю, что база данных, в данном случае WordPress, состоит из набора таблиц. У каждой таблицы есть имя. Имя таблицы начинается с префикса. Префикс WordPress по умолчанию wp_. Для безопасности при установке WordPress вы должны его поменять, но в изложении я буду использовать именно префикс wp_.

Итак, пользователи. Все пользователи сайта WordPress лежат в таблице wp_users. Находим её в списке таблиц и открываем для просмотра (кликаем по названию).

Таблица пользователей WordPress

Смотрим на открывшуюся таблицу. Напоминаю, что любая таблица базы данных имеет строки (записи) и столбцы (поля). В данном случае нас интересуют поля таблицы, а именно основные из них:

Поля с данными пользователей wordpress

• user_login: логин пользователя;
• user_nicename: ник пользователя;
• user_email: email адрес оставленный пользователем;
• user_pass: пароль пользователя.

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

Принцип экспортирования данных пользователей

Принцип экспортирования пользовательских данных прост.

• Для начала решаем, какие данные пользователей нам нужны.
• Создаем SQL запрос по выборке этих полей (столбцов) в таблице wp_users;
• Экспортируем их в нужном формате.

Важно! Перед работой с базой данных сделайте полный экспорт базы данных (резервную копию), на случай ошибок.

SQL запрос экспорта выборочных данных пользователей

Для выборки нужных полей в таблице используем оператор SQL SELECT DISTINCT. Он позволяет отсортировать таблицу БД по нужным полям. Синтаксис оператора такой:

SELECT DISTINCT user_login,user_nicename,user_email FROM wp_users

Перевожу, выбираем из (from) таблицы wp_users, поля: user_login, user_nicename, user_email.

• После отправки запроса SQL SELECT DISTINCT таблица пользователей выведется в сокращенном виде, только с нужными полями (столбцами) данных.

Примечание: Таким образом, можно вывести отдельно только email, или email+login и т.п.

• Далее жмем кнопку экспорт (внизу таблицы) и экспортируем нужные данные в нужном формате.

Формат выводимых данных

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

выбираем формат файла с данными пользователей

Что делать с файлом данных пользователей?

Подходим к ответу на вопрос: Зачем нужен файл данных пользователей. Например, чтобы перенести пользователей на сторонний почтовый сервис, типа MailChimp или Smartresponder. Как это сделать в картинках покажу в следующей статье, здесь кратко:

• Смотрим на почтовом сервере, какие форматы файлов с пользователями они принимают;
• Экспортируем выбранные данные из таблицы wp_user в нужном формате;
• Смотрим на почтовом сервисе, как отформатирована их база данных. То есть, как называются поля в таблице пользователей (users) в базе данных почтового сервиса;

Например, на MailChimp поле с email адресами называют: Contact Email Addresses. В WordPress это поле называют user_email. Поэтому, открываем наш файл с данными пользователей в текстовом редакторе, ищем поиском user_email и заменяем его на Contact Email Addresses. Сохраняемся и импортируем отформатированный файл в список подписчиков (list) на MailChimp.

Почти так же, можно перенести пользователей на другой домен WordPress. Больше того, этим способом можно перенести пользователей на сайт другой CMS, например на Joomla.

©www.wordpress-abc.ru

Другие Уроки WordPress

Похожие посты:

Похожее

База данных WordPress сайта | IT-блог о веб-технологиях, серверах, протоколах, базах данных, СУБД, SQL, компьютерных сетях, языках программирования и создание сайтов.

Здравствуйте, уважаемые посетители моего скромного блога для начинающих вебразработчиков и web мастеров ZametkiNaPolyah.ru. Продолжаем разговор о создании блога на WordPress. И сегодня мы поговорим о базе данных WordPress. Разберемся с сервером баз данных, который используется движком WordPress, какой тип движка использует база данных WordPress. Поговорим немного о таблицах базы данных WordPress, и на конец,  мы рассмотрим структуру каждой таблицы.

 

База данных WordPress сайта

Для чего необходимо знать архитектуру базы данных этой системы управления сайтами? Как минимум, для общего развития. Большинству пользователей WordPress эта информация может показаться излишней и не нужной: простые посетители сайтов вряд ли заинтересуются этим вопросам, многие вебмастера, которые используют WordPress, не представляют себе то, как он работает изнутри, поэтому ставят кучу ненужных плагинов и расширений. Начинающим веб-разработчикам, использующим WordPress, как платформу для создания сайтов и блогов, информация из этого   поста может показаться очень полезной и нужной.

Особенности работы базы данных 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 способных изменять, как архитектуру базы данных, так и содержимое некоторых таблиц.

Таблица базы данных WordPress

Имя таблицы WP	Содержимое таблицы WP	Пользовательский интерфейс
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.

Интеграция своей БД с БД WordPress

необходимо также предусмотреть вывод результатов по каждому пользователю в личном кабинете.

это вы кому адресовали?

• В зависимости от вашей Структуры вашей Затеи, целесообразно либо использовать существующие Таблицы в существующей DB, либо создать и использовать новые Таблицы в существующей DB.

создавать новые поля в уже существующих таблицах WordPress, таких как — posts, usermeta

Таблица usermeta в общем случае подходит для хранения любых данных о пользователе, создавать в ней новые поля нет необходимости.

@wpgear , упоминая про личный кабинет я просто конкретизировал суть проекта.

<p>В зависимости от вашей Структуры вашей Затеи, целесообразно либо использовать существующие Таблицы в существующей DB, либо создать и использовать новые Таблицы в существующей DB.</p>

То есть либо создавать свои собственные новые таблицы, либо использовать существующие таблицы в существующей DB без какого-либо добавления в них новых полей (и таким образом, структуру исходных таблиц базы данных WP не редактировать) ? Я правильно понял?

структуру исходных таблиц базы данных WP не редактировать

Совершенно верно.
И если вы сформулируете хотя бы в общих словах Цели и Возможности вашего ЛК, то можно будет надеяться на получение разумных советов.

И если вы сформулируете хотя бы в общих словах Цели и Возможности вашего ЛК, то можно будет надеяться на получение разумных советов.

@wpgear , помимо целей и возможностей — ниже также сформулировал приблизительные входные и выходные данные:

Цели:
• предоставить пользователям доступ к расчетной системе (круг пользователей ограничен)
• предоставить пользователям возможность вводить определенные данные в расчетную систему и получать на их основе необходимые расчетные данные

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

Входные данные:
• логин/пароль пользователя
• ФИО
• e-mail
• № телефона
• адрес
• период расчета
• вид населенного пункта
• наименование населенного пункта
• показатели a,b,c,d,e
• Каждый пользователь обладает определенным набором прав доступа к данным (первая категория пользователей: только просмотр всей ветки; вторая категория: просмотр и редактирование определенной области ветки)
• Каждый пользователь относится к определённой организации — на основе принадлежности к той или иной организации определяется уровень доступа к данным
• существует третья главная категория пользователей, одобряющая или отклоняющая введенные данные первой категорией пользователей

Выходные данные
• расчетные показатели f1,f2,fn на основе введенных a,b,c,d,e

Буду очень признателен за любой совет и комментарий

Для Хранения всего перечисленного идеально подходит Таблица usermeta, о чем вам сказал sergeybiryukov
Для Управления с распределением Прав Доступа, можно попробовать некоторые Плагины, типа Ultimate Members или WP-Recall
Но скорее всего, учитывая ваши хотелки, проще написать свой Плагин, добавив пару собственных Таблиц.

Если 4-6 параметров — то wp_usermeta для хранения вполне подойдет.
А вывести в существующий ЛК — не сложно.
Оформляете функцию в шорткод (в которой получаете нужные значения) и в произвольной вкладке, WP-Recall например, вписываете этот шорткод.

Функционал произвольных вкладок позволяет вписать переменную в шорткод — она передает id владельца кабинета

{MASTERID} — выводит идентификатор хозяина текущего личного кабинета

. Дока

Но скорее всего, учитывая ваши хотелки, проще написать свой Плагин, добавив пару собственных Таблиц.

@wpgear , сейчас в моей базе 8 таблиц:

1. Пользователи
2. Организации (каждый пользователь принадлежит определенной организации)
3. Типы организаций (каждая организация имеет свой тип и данный тип определяет категорию доступа к данным отчетов)
4. Населенные пункты (каждая организация принадлежит определенному населенному пункту)
5. Типы насел. пунктов (каждый насел. пункт имеет свой тип)
6. Регионы (каждая организация находится в определенном регионе)
7. Отчеты ( @otshelnik-fm , именно сюда и сохраняются те 4-6 параметров, о которых я упоминал выше)
8. Типы отчетов (каждая организация на основе своего типа имеет доступ к определенным типам отчетов)

Правильно ли я понимаю —

1. поля таблицы Пользователи(фамилия, имя, отчество, должность, идентификатор организации как внешний ключ) вписываются для хранения в таблицу usermeta ?
2. Можно ли таблицы Организации Типы организаций Населенные пункты Типы насел. пунктов Регионы вписать для хранения в таблицы terms termmeta и term_taxonomy в качестве таксономий или же нужно создавать свои собственные таблицы ?
3. В таблице Отчеты хранятся идентификаторы пользователя, насел. пункта, id типа отчета и 4-6 параметров, вводимых пользователем в форму + расчетный параметр — для таблицы Отчеты наверное нужно точно создавать свою таблицу ?

Поправьте, пожалуйста, наверняка я где-то ошибаюсь
Заранее благодарен за любые советы

Заранее благодарен за любые советы

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

Правильно ли я понимаю

Очень хорошо.

Скорее всего: «Типы организаций», «Типы насел. пунктов», «Типы отчетов» — они не будут иметь больших Списков, и не они будут часто обновляться.
Поэтому, можно (но не обязательно) их перечислить в обычных Массивах.

Поэтому, можно (но не обязательно) «Типы организаций», «Типы насел. пунктов», «Типы отчетов» перечислить в обычных Массивах

@wpgear , спасибо за комментарии, но осталась одна неясность — большие по объему таблицу Организации и таблицу Населенные пункты вписывать для хранения в таблицы terms, termmeta и term_taxonomy в качестве таксономий (и затем привязывать к пользователям и отчетам в качестве той или иной категории) или же лучше не извращаться и создавать для организаций и населенных пунктов собственные таблицы ?

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

Если вывести резюме из всей темы, то можно сформулировать следующее:

• Целесообразно либо использовать существующие Таблицы в исходной DB WorpPress, либо создавать и использовать новые Таблицы в исходной DB WordPress при помощи функции dbDelta(), и, таким образом, структуру исходных таблиц базы данных WP НЕ РЕДАКТИРОВАТЬ
• Таблица usermeta идеально подходит для хранения любых данных о пользователе, создавать в ней новые поля нет необходимости (также как и нет необходимости править структуру любой другой исходной таблицы DB WordPress)
• Для хранения небольших списков данных (например, «Типы организаций», «Типы насел. пунктов», «Типы отчетов») можно как создавать собственные таблицы в DB WordPress, а можно и перечислить их в обычных Массивах без создания таблиц в DB
• Для хранения больших списков данных (например, «Организации», «Насел. пункты») нужно либо создавать собственные таблицы в DB WordPress, либо использовать Пользовательские Таксономии и соответственно хранить всю информацию данных списков в таблицах terms, termmeta и term_taxonomy
• Для Управления с распределением Прав Доступа между пользователями, можно попробовать некоторые Плагины, например Ultimate Members или WP-Recall, но проще будет написать свой Плагин, добавив пару собственных Таблиц
• оформить всё вышесказанное вообще в отдельный плагин, который при активации будет вносить все изменения в DB и создавать необходимые таблицы, и далее данный плагин будет выполнять остальной функционал — управление с распределением прав доступа между пользователями, ввод данных пользователем в формы, расчеты, сохранение данных в DB, отображение личного кабинета пользователя и прочее

@wpgear , поправьте, пожалуйста, если я где-то ошибся и спасибо огромное за помощь.
p.s. еще не совсем понял, что Вы имели ввиду под этой фразой (видимо эта фраза как-то связано с использованием либо пользовательских таксономий, либо собственных таблиц в структуре DB) :

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

но проще будет написать свой Плагин, добавив пару собственных Таблиц

смотря что вы считаете должно быть в ЛК.

В готовых ЛК масса уже готового функционала — который включается по необходимости. У реколл это оформлено в виде дополнений.
Готовый ЛК сэкономит вам время — т.к. останется только вывести вашу табличку и не думать о профилях, вкладках, полях профиля, форме регистрации и логина…

Но возможно, что вы захотите, чтобы все в вашей Админке имело единый Интерфейс в плане Навигации и Управления.

Если вы решитесь на создание собственного Плагина, то у вас будет своя Админка для него. В которой, можно будет настраивать, редактировать все ваши Организации, Населенные пункты и всевозможные их Типы.
Для этого у вас должны быть предусмотрены необходимые элементы управления и должен быть обеспечен вывод этих Записей, их Поиск и Сортировка.
В конченом счете, вы каким-то образом все это оформите, следуя собственным предпочтениям и полагаясь на собственный вкус или его отсутствие.

Ну и вот.

А Таксономии — они уже имеют вполне определенный Механизм, в стиле и концепции WP.
И если ваш Интерфейс будет сильно отличаться от WP-Интерфейса, то — это будет заметно.
Однако, для Прототипа — это не принципиально. Лишь бы заработало.

Создание базы данных для WordPress | WordPress.org

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

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

1. Войдите в Plesk.
2. Нажмите Базы данных в области Пользовательский веб-сайт своего сайта на странице Сайты и домены:
   

. Пользовательские базы данных Plesk

3.Нажмите Добавить новую базу данных , измените имя базы данных, если хотите, создайте пользователя базы данных, указав учетные данные, и нажмите ОК . Вы сделали!

Топ ↑

Если ваш хостинг-провайдер предоставляет панель управления хостингом cPanel, вы можете следовать этим простым инструкциям для создания вашего имени пользователя и базы данных WordPress. Более полный набор инструкций по использованию cPanel для создания базы данных и пользователя можно найти в разделе Использование cPanel.

1. Войдите в свою cPanel.
2. Щелкните значок MySQL Database Wizard в разделе «Базы данных».
3. В Шаг 1. Создайте базу данных , введите имя базы данных и нажмите «Следующий шаг».
4. В Шаг 2. Создание пользователей базы данных введите имя пользователя базы данных и пароль. Убедитесь, что вы используете надежный пароль. Нажмите Создать пользователя.
5. В Шаг 3. Добавить пользователя в базу данных , установите флажок Все привилегии и нажмите «Следующий шаг».
6. В Шаг 4. Выполните задачу , запишите имя базы данных и пользователя.Запишите значения имя хоста , имя пользователя , имя базы данных и пароль, который вы выбрали. (Обратите внимание, что имя хоста обычно будет localhost .)

Топ ↑

Lunarpages разработала собственную версию cPanel.

1. Войдите в свой аккаунт.
2. Перейти к панели управления.
3. Нажмите на кнопку на левой панели с надписью «Перейти к LPCP».
4. Перейти к MySQL Manager.
5. Добавьте имя пользователя и имя базы данных, но оставьте имя хоста в качестве IP-номера по умолчанию.
6. Обратите внимание на IP-адрес базы данных справа, который отличается от стандартного IP-адреса хоста, указанного на предыдущем шаге.
7. При изменении файла wp-config.php используйте IP-номер БД, а не «LOCALHOST».
8. При изменении файла wp-config.php обязательно используйте полное имя базы данных и имя пользователя, обычно это «accountname_nameyoucreated».
9. Для получения дополнительной информации обратитесь к http://wiki.lunarpages.com/Create_and_Delete_MySQL_Users_in_LPCP.

Топ ↑

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

Примечание: Эти инструкции написаны для phpMyAdmin 4.4; Пользовательский интерфейс phpMyAdmin может немного отличаться в зависимости от версии.

1. Если база данных, относящаяся к WordPress, еще не существует в раскрывающемся списке База данных слева, создайте ее:
   1. Выберите имя для своей базы данных WordPress: «wordpress» или «блог» — это хорошо, но большинству хостинговых услуг (особенно виртуального хостинга) потребуется имя, начинающееся с вашего имени пользователя и подчеркивания, поэтому даже если вы работаете самостоятельно компьютер, мы рекомендуем вам проверить требования к хостингу, чтобы вы могли следить за ними на своем собственном сервере и иметь возможность передавать свою базу данных без изменений.Введите выбранное имя базы данных в поле Создать базу данных и выберите наилучший порядок сопоставления для вашего языка и кодировки. В большинстве случаев лучше выбрать из серии «utf8_» и, если вы не нашли свой язык, выбрать «utf8mb4_general_ci» (ссылка: [1]).

Раскрывающаяся кодировка языка phpMyAdmin

2. Щелкните значок phpMyAdmin в левом верхнем углу, чтобы вернуться на главную страницу, затем перейдите на вкладку Users . Если пользователь, относящийся к WordPress, еще не существует в списке пользователей, создайте его:

Вкладка phpMyAdmin Users

1. Нажмите Добавить пользователя .
2. Выберите имя пользователя для WordPress («wordpress» подходит) и введите его в поле « Имя пользователя ». (Убедитесь, что Использовать текстовое поле: выбрано из выпадающего списка.)
3. Выберите безопасный пароль (в идеале содержащий комбинацию букв верхнего и нижнего регистра, цифр и символов) и введите его в Пароль поле. (Убедитесь, что Использовать текстовое поле: выбрано из выпадающего списка.) Повторно введите пароль в поле Повторите ввод .
4. Запишите имя пользователя и пароль, которые вы выбрали.
5. Оставьте все опции под Глобальные привилегии по умолчанию.
6. Нажмите Go .
7. # Вернитесь к экрану Users и щелкните значок Изменить привилегии на пользователе, которого вы только что создали для WordPress.
8. # В разделе «Права доступа к базе данных » выберите базу данных, которую вы только что создали для WordPress, в разделе «». Добавьте права доступа к следующей выпадающей базе данных и нажмите « Перейти ».
9. # Страница обновится с привилегиями для этой базы данных. Нажмите Отметить все , чтобы выбрать все привилегии, и нажмите Перейти .
10. # На открывшейся странице запишите имя хоста, указанное после Server: в верхней части страницы. (Обычно это будет localhost .)

Топ ↑

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

 $ mysql -u adminusername -p 
 Введите пароль: 
 Добро пожаловать на монитор MySQL.Команды заканчиваются на; или \ g. 
 Идентификатор подключения MySQL 5340 к версии сервера: 3.23.54 
 Введите help; или '\ h' для помощи Введите «\ c», чтобы очистить буфер. 
 
 mysql> CREATE DATABASE имя базы данных; 
 Запрос в порядке, 1 строка затронута (0,00 с) 
 
 mysql> ПРЕДОСТАВИТЬ ВСЕ ПРИВИЛЕГИИ по имени базы данных. * TO "wordpressusername" @ "hostname" 
 -> ОПРЕДЕЛЕНО "паролем"; 
 Запрос в порядке, затронуто 0 строк (0,00 с) 
 
 mysql> ПРИВИЛЕГИИ ПРОМЫВКИ; 
 Запрос в порядке, затронуто 0 строк (0.01 сек) 
 
 mysql> EXIT 
 Пока 
 $ 
 
 

Пример показывает:

• , что root также adminusername . Более безопасной практикой является выбор так называемой «смертной» учетной записи в качестве администратора mysql, чтобы вы не вводили команду «mysql» в качестве пользователя root в вашей системе. (Каждый раз, когда вы можете избежать работы с правами суперпользователя, вы уменьшаете вероятность использования.) Используемое вами имя зависит от имени, которое вы назначили администратором базы данных с помощью mysqladmin.
• WordPress или блог хорошие значения для базы данных .
• wordpress — хорошее значение для wordpressusername , но вы должны понимать, что, поскольку он используется здесь, весь мир узнает об этом.
• имя хоста обычно будет localhost. Если вы не знаете, каким должно быть это значение, уточните у системного администратора, не являетесь ли вы администратором своего хоста WordPress. Если вы системный администратор, рассмотрите возможность использования учетной записи без полномочий root для администрирования вашей базы данных.
• пароль должен быть трудно угадываемым паролем, в идеале он должен содержать комбинацию букв верхнего и нижнего регистра, цифр и символов. Хороший способ избежать использования слова, найденного в словаре, — это использовать первую букву каждого слова в фразе, которую вам легко запомнить.

Если вам нужно записать эти значения где-нибудь, не пишите их в системе, которая содержит защищенные ими вещи. Вам нужно запомнить значение, используемое для имя базы данных , wordpressusername , имя хоста и пароль .Конечно, поскольку они уже находятся (или будут в ближайшее время) в вашем файле wp-config.php, нет необходимости размещать их где-то еще.

Топ ↑

а. Если вы являетесь обычным пользователем учетной записи веб-хостинга на одном сайте, вы можете войти в систему как обычно. Затем нажмите Управление MySQL . (Если это не так легко увидеть, возможно, вашему хосту нужно изменить ваш «пакет» для активации MySQL.) Затем следуйте части «c» ниже.

б. Учетные записи посредников. Для учетных записей администраторов может потребоваться нажать .Сначала они должны войти в систему в качестве посредника, если соответствующий домен является основным доменом посредника… или войти в систему как пользователь, если домен не является основным доменом посредника. Если это основной домен посредника, то, войдя в систему как посредник, просто нажмите Уровень пользователя . Однако если соответствующий домен не является основным доменом посредника, вы должны войти в систему как пользователь. Затем нажмите Управление MySQL . (Если он невидим, возможно, вам нужно вернуться на уровень посредника или администратора и изменить «Управление пакетом пользователя» или «Управление пакетом посредника», чтобы включить MySQL.)

в. В MySQL Management нажмите на маленькие слова: Создать новую базу данных . Здесь вам предлагается предоставить два суффикса для базы данных и ее имя пользователя. Для максимальной безопасности используйте два разных набора из 4-6 случайных символов. Затем в поле пароля есть кнопка «Случайный выбор», которая генерирует 8-символьный пароль. Вы также можете добавить больше символов к паролю для максимальной безопасности. Нажмите Создать . На следующем экране будет представлена ​​база данных, имя пользователя, пароль и имя хоста.Обязательно скопируйте и вставьте их в текстовый файл для дальнейшего использования.

,

WP Data Access — плагин WordPress

WP Data Access — это мощный инструмент для администрирования, публикации и разработки данных, который позволяет выполнять задачи, связанные с базой данных, с панели управления WordPress. Интуитивно понятный пользовательский интерфейс помогает создавать полностью отзывчивые публикации и страницы администрирования данных. Навыки программирования не требуются!

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

Data Explorer

Управление данными и базами данных

• Управление локальными и удаленными базами данных
• Администрирование базы данных (переименование, копирование, удаление, усечение…)
• Администрирование данных (поиск, вставка, обновление, удаление…)
• Экспорт в SQL, XML, JSON, CSV и Excel
• Импорт файлов SQL и CSV
• Интеграция WordPress Media Library
• Создание динамических гиперссылок (подстановка значений столбцов)

Data Publisher

Публикация адаптивных таблиц

• Отзывчивые HTML-таблицы
• Поддержка Ajax (без загрузки страницы)
• Интеграция WordPress Media Library
• Интеграция с динамической гиперссылкой
• Простой уровень: не требуются навыки кодирования
• Продвинутый уровень: требуются базовые знания JSON
• Уровень эксперта: требуется знание JavaScript
• Поддерживает локальные и удаленные базы данных

Data Projects

Напишите свои собственные приложения WordPress

• Автоматически сгенерированные страницы CRUD
• родительско-дочерние страницы
• Интеграция ролей в WordPress
• Интеграция медиатек WordPress
• Интеграция с динамической гиперссылкой
• Доступно с панели управления WordPress
• Поддержка шорткода для веб-страниц
• Поддерживает локальные и удаленные базы данных

Data Designer

Создание таблиц и индексов

• Создание и изменение таблиц и индексов
• Поддержка реверс-инжиниринга и сверки

Настройки плагинов

Управление поведением, стилем и безопасностью плагина

• Много подробных настроек плагина
• Доступ и разрешение пользователя
• Интегрированное управление ролями WordPress

Плагин Ссылки

(1) Загрузите плагин WP Data Access в свой блог
(2) Активируйте его
(3) Перейдите в меню WP Data Access

1, 2, 3 и все готово!

«WP Data Access» — это программное обеспечение с открытым исходным кодом.Следующие люди внесли свой вклад в этот плагин.

участников ,

Структура базы данных WordPress —

WordPress и почти все плагины хранят его настройки в специальном месте на вашем сервере под названием база данных. Данные, хранящиеся в базе данных, организованы в так называемые «таблицы».

Представьте себе что-то вроде листа Excel с одной строкой заголовка и значениями в строке ниже.

Например, вы можете увидеть здесь небольшой раздел таблицы wp_options :

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

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

Основные таблицы WordPress

Другие таблицы в базе данных WordPress создаются другими плагинами и не обязательно необходимы для успешной работы сайта.

wp_options

Таблица wp_options является одной из наиболее важных таблиц базы данных WordPress и хранит все настройки сайта WordPress, такие как URL, заголовок, установленные плагины и т. Д.Большинство плагинов также хранят настройки в этой таблице.

Все настройки, которые вы видите на панели управления WordPress, хранятся в этой таблице.

wp_users,
wp_usermeta

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

wp_usermeta хранит метаданные (дополнительные данные ) пользователей.Это расширяет таблицу wp_users большим количеством данных. Например, имя пользователя сохраняется в таблице wp_usermeta вместо таблицы wp_users.

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

wp_posts,
wp_postmeta

wp_posts В таблице хранятся все данные, связанные с контентом веб-сайта WordPress. Все посты, страницы и их редакции доступны в таблице wp_posts .Это может сбивать с толку, но WordPress хранит гораздо больше в этой таблице.

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

В wp_posts — это столбец таблицы post_type , который сегментирует такие типы данных, так что конкретные типы данных могут быть запрошены запросом базы данных. post_type — самый важный столбец в этой таблице.

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

Таблица wp_postmeta , как и таблица wp_usermeta , расширяет таблицу wp_posts дополнительными данными и может использоваться другими плагинами.

Например, плагины для совместного использования в социальных сетях, такие как MashShare, хранят подсчет общего ресурса для определенного поста в этой таблице, а плагин Yoast SEO также хранит там теги, посты и URL-адреса пользовательских открытых графиков.

wp_terms,
wp_term_relationships,
wp_term_taxonomy

В таблице wp_terms хранятся категории и теги для сообщений, страниц и ссылок.

Один из столбцов в этой таблице — «Слаг». Слаг — это термин, который отражает тег определенного поста.В WordPress вы можете использовать теги для соединения записей, страниц и ссылок между собой.

wp_term_relationship является соединением и связывает эти теги с записями, страницами и ссылками. Это как карта между терминами объектов и терминами.

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

wp_comments хранит комментарии к постам и страницам. Эта таблица также содержит неутвержденные комментарии и информацию об авторе вместе с иерархией комментариев. Таблица wp_commentmeta содержит дополнительные метаданные о комментариях.

wp_links

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

Графическая структура базы данных WordPress

Эта диаграмма показывает, как связаны таблицы WordPress:

Источник: WordPress.org

,

WP Migrate DB — Легкая миграция WordPress — плагин WordPress

Нужно ли каждый раз настраивать перенос WordPress вручную?

Нет! WP Migrate DB включает в себя так называемые «профили миграции». Эти профили позволяют сохранить настройки миграции WordPress, чтобы сделать процесс максимально быстрым.

Совместима ли WP Migrate DB с многосайтовым WordPress?

Бесплатная версия WP Migrate DB совместима с WordPress Multisite, однако при обновлении до Pro мощность возрастает до 11.Pro включает полную поддержку импорта одного сайта в сеть Multisite, а также вы можете экспортировать дочерний сайт в один сайт.

У меня есть тонна спам-комментариев на моем сайте, могу ли я исключить их из миграции?

Вы уверены, что можете! WP Migrate DB позволяет исключить спам-комментарии из любой миграции WordPress одним щелчком мыши.

Что если плагин повредит мою миграцию WordPress?

Не волнуйся! Начиная с WP Migrate DB 1.0 и выше, все плагины переводятся в режим совместимости, что по существу не позволяет им загружаться только для запросов на миграцию.

Плагины

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

Могу ли я перенести весь мой сайт WordPress с этим?

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

Вопрос: В каком формате экспортируется моя база данных WordPress?

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

Мне всегда говорили, что экспортировать мою базу данных WordPress сложно, чем это отличается?

WP Migrate DB поставляется со всем, что вам нужно, и с тем, что у вас нет.Благодаря дружественному и простому в использовании пользовательскому интерфейсу надежный экспорт файлов базы данных WordPress никогда не был таким простым.

Можно ли использовать WP Migrate DB для перехода на новый веб-хостинг?

Да! Вы можете легко экспортировать свою базу данных и импортировать свою базу данных в новую учетную запись веб-хостинга, используя такой инструмент, как phpMyAdmin или аналогичный. Хотите еще больше энергии? Обновитесь до Pro и просто нажмите или извлеките все ваши файлы мультимедиа и темы / плагина.

Что конкретно означают базы данных push / pull?

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

Однако ваша база данных будет не синхронизирована между ними, в какой-то момент вы пропустите важные данные!

WP Migrate DB Pro облегчает эту задачу. Вы можете перетащить базу данных из оперативной в промежуточную, внести изменения, а затем одним нажатием вернуться на действующий сайт. Помните, однако, что эта функциональность доступна только в WP Migrate DB Pro.

Как насчет сериализованных данных? Мои данные останутся нетронутыми?

WP Migrate DB полностью поддерживает поиск и замену сериализованных данных.Просто введите данные, которые вы хотите найти, и данные, которые вы хотите заменить, и WP Migrate DB сделает все остальное.

Будете ли вы переносить мой сайт WordPress для меня?

В настоящее время мы не предлагаем услуги переноса WordPress, но вы можете попробовать WP Migrate DB Pro. Это плагин WordPress для миграции со всем необходимым для быстрой и простой миграции на новый хост. А если вам это будет слишком сложно, у нас есть 100-процентная 60-дневная гарантия возврата денег без риска, чтобы вы могли легко получить возмещение.

Можно ли использовать командную строку (WP-CLI)?

Да, WP Migrate DB включает в себя команды export и find-replace . С лицензией WP Migrate DB Pro Developer или выше вы получаете дополнение CLI, которое включает в себя дополнительные шесть команд: push , pull , профилей , профилей , настроек и импорта . Проверьте нашу документацию для получения дополнительной информации о наших командах WP-CLI.

Могу ли я перейти на новый домен?

WP Migrate DB идеально подходит для перехода на новый домен! Вы можете использовать встроенную функцию поиска и замены, чтобы найти URL старого сайта (доменное имя) в содержимом базы данных и заменить его новым.

Как выполнить миграцию моего сайта с помощью WP Migrate DB?

Если вы используете бесплатную версию, просто установите плагин. Введите URL-адреса, которые вы хотели бы найти и чем их заменить, и экспортируйте базу данных WordPress, которая загрузит файл SQL.Теперь получите доступ к своей базе данных MySQL (или MariaDB!), Используя предпочитаемый инструмент (например, phpMyAdmin или SequelPro), импортируйте файл SQL, и все готово.

Почему WP Migrate DB лучше, чем Updraft, Duplicator и Search Replace DB?

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

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

Быстрое сравнение с Updraft Plus — в то время как Updraft Plus предоставляет множество функциональных возможностей, это, прежде всего, плагин для резервного копирования с расширенной опцией для миграции вашего сайта. Сравните это с WP Migrate DB — инструментом миграции сайта, который используется и рекомендуется профессиональными разработчиками WordPress.

Дополнение «Темы и плагины» для WP Migrate DB Pro от @dliciousbrains — настоящий гений. Так много вариантов использования, о которых я даже не подумал, когда они выпустили его. В основном: 1) Постановка сайтов 2) Поддержка плагинов Экономит мне время каждую неделю. — Клифтон Гриффин, ведущий специалист по развитию в Objectiv

Наконец, Duplicator — это плагин миграции, который сильно отличается от WP Migrate DB. Duplicator создает zip-файл вашей базы данных и файлы, которые необходимо вручную (через FTP / SFTP) перенести в новое местоположение вашего сайта. Затем этот пакет необходимо распаковать и запустить скрипт установщика. Все эти операции намного более обременительны для ресурсов сервера, чем то, что делает WP Migrate DB, и намного менее гладкие, чем WP Migrate DB Pro.

Можно ли клонировать WordPress или дублировать WordPress с помощью WP Migrate DB?

можно! Хотя клонирование сайта WordPress может быть затруднено, WP Migrate DB делает его быстрым.То же самое происходит, если вы хотите дублировать WordPress, что является другим способом сказать то же самое. Вот краткое пошаговое руководство.

Шаг 1: Установите плагин на установку WordPress, к которой вы хотите клонировать WordPress.
Шаг 2: Заполните поля поиска и замены в WP Migrate DB.
Шаг 3: Экспортировать базу данных.
Шаг 4: Импортируйте базу данных на ваш новый сайт.

И это так просто, ваши данные были клонированы на новый сайт, готовый к работе.Pssst¦ Если у вас есть WP Migrate DB Pro, клонировать ваш веб-сайт еще проще, включая все медиафайлы, темы и плагины.

FTP ушел в прошлое?

Если вы используете WP Migrate DB Pro, вам больше не нужно использовать эти старые неуклюжие FTP-клиенты. Вместо этого вы можете нажать и вытащить свой плагин, тему и медиа-файлы в один клик. Это не могло быть проще.

Будет ли это работать с моим хостинг-провайдером?

WP Migrate DB отлично работает со всеми провайдерами веб-хостинга и даже с вашей локальной установкой! Никогда не было проще перенести ваш сайт на новый сервер, обновить домен или внести изменения между локальным и промежуточным.

Как насчет резервного копирования моей базы данных?

WP Migrate DB Pro выполняет резервное копирование базы данных перед экспортом SQL. Однако, если вы используете WP Migrate DB бесплатно, мы рекомендуем использовать плагин или делать резервные копии через панель управления веб-хостинга, прежде чем переносить ваш сайт.

Какая поддержка предоставляется?

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

Где я могу узнать о ценах на WP Migrate DB Pro?

Узнайте всю необходимую информацию о ценах на нашем официальном сайте.

,