Второй способ с shardb более предпочтительнее, добавлен ниже
Они везде добавляют свои js / css и туда, где они не нужны. Таким образом, если установить несколько мощных тяжёлых плагинов и еще + 10-15 дополнительных поменьше, можно увидеть огромное количество скриптов и стилей везде, практически на каждой странице.
Решение этому нашлось — режим multisite.
Подключить его не составит труда и начать пользоваться можно за пару минут.
Для этого нужно добавить строку в wp-config.php
/* Это всё, дальше не редактируем. Успехов! */
define('WP_ALLOW_MULTISITE', true);
После чего пройти в Инструменты -> Установка сети.
Её обязательно нужно выполнять с выключенными плагинами.
Вам предложат заменить данные в wp-config и .htaccess и авторизоваться ещё раз на сайте.
Система multisite
Режимов сайта всего 2 — это либо папки / или поддомены.
сайт.ru/сайт2
сайт2.сайт.ru
Одна таблица общих пользователей — при регистрации на любом из них они смогут войти во все остальные так же, так что не придётся регистрироваться по нескольку раз.
Управление плагинами и темами для всех сайтов из панели. Можно добавить необходимые для всех в одном месте и далее активировать их только на тех, где они нужны по отдельности. Так же есть возможность активировать их сразу для всей сети.
Таким образом, возможно сократить потребление плагинов на 50% и более. Вроде бы всё хорошо, с фронтендом уже все в порядке, но вот беда:
multisite использует одну базу на все сайты — создавая на каждый из них отдельные таблицы.
wp_
wp_2
wp_3
Теперь одна база будет увеличиваться в несколько раз от каждого нового сайта.
Multisite c отдельной бд по каждый сайт
Для этого мы будем использовать плагин multi-db. Конечно, есть и другие, такие как HyperDB, SharDB, но я не нашёл никакой информации о них. Скачать multi-db вы можете по любой ссылке ниже.
cloud.mail.ru/public/KMNr/WDpoUeyUV
drive.google.com/open?id=0Bw4XcI3lCfQSUWZWLUUyUHZFVTA
Сам он предлагает сначала определиться, сколько баз вам нужно (16, 256, 4096).
Начну с 16. Важна последовательность. Сначала установите multisite, я буду начинать разделять базы данных, имея 3 созданных сайта — для того, чтобы протестировать его работу после этого.
Создание vip баз
Эта опция позволяет размещать конкретный сайт в конкретной базе данных. Мне она не нужна. Затрагивать её не буду. Без разницы мне, в какую, главное — что в любую другую, а не в одну.
Первым делом нужно подготовить новые базы
CREATE DATABASE `dbname_0` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `dbname_1` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `dbname_2` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `dbname_3` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `dbname_4` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `dbname_5` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `dbname_6` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `dbname_7` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `dbname_8` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `dbname_9` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `dbname_a` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `dbname_b` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `dbname_c` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `dbname_d` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `dbname_e` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `dbname_f` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `dbname_global` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
Выполните этот sql запрос и тогда вы увидите их.
Создание пользователей и паролей в PhpMyAdmin
Так как я на Localhoste, мне это не нужно. Подойдёт root, но вам может понадобиться создать новые имена и пароли, а так же дать нужные привилегии в случае, если вы делаете сайт не для себя одного, а, например, для нескольких людей. Поэтому я пропущу этот пункт.
Распаковка файлов
db-config.php, db.php нужно разместить в wp-content
move-blogs.php в любой папке после wp-content, например в новой /wp-content/scripts/
Настройка подключаемых модулей
DB-config.php
define ('DB_SCALING', '16');
//------------------------------------------------------------------------//
//---DC IPs---------------------------------------------------------------//
//------------------------------------------------------------------------//
// Usage: add_dc_ip(IP, DC)
// EX: add_dc_ip('123.123.123.', 'dc1');
add_dc_ip('127.0.0.', 'dc1');
Здесь нужно указать кол-во баз, 16 в данном случае и ip сервера. В конце вместо последних цифр ставится точка 127.0.0.
Далее ниже на первом месте добавим глобальную таблицу add_global_table('dbname_global');
//------------------------------------------------------------------------//
//---Global Tables--------------------------------------------------------//
//------------------------------------------------------------------------//
// Do not include default global tables
// Leave off base prefix (eg: wp_)
// You don't really have to register these, they will work fine without.
// However registering at least your busiest ones might shave a few milliseconds off by avoiding some regexes.
//
// Usage: add_global_table(TABLE_NAME)
// EX: add_global_table('something');
add_global_table('dbname_global');
add_global_table('affiliatedata');
add_global_table('affiliatereferrers');
add_global_table('am_actions');
add_global_table('am_queue');
add_global_table('am_schedule');
add_global_table('autoblog');
add_global_table('bp_activity');
add_global_table('bp_activity_meta');
add_global_table('bp_friends');
add_global_table('bp_groups');
add_global_table('bp_groups_groupmeta');
add_global_table('bp_groups_members');
add_global_table('bp_messages_messages');
add_global_table('bp_messages_notices');
add_global_table('bp_messages_recipients');
add_global_table('bp_notifications');
add_global_table('bp_user_blogs');
add_global_table('bp_user_blogs_blogmeta');
add_global_table('bp_xprofile_data');
add_global_table('bp_xprofile_fields');
add_global_table('bp_xprofile_groups');
add_global_table('domain_mapping');
После чего ниже останется установить логин и пароль для входа в mysql:
//------------------------------------------------------------------------//
//---DB Servers-----------------------------------------------------------//
//------------------------------------------------------------------------//
// Database servers grouped by dataset.
// R can be 0 (no reads) or a positive integer indicating the order
// in which to attempt communication (all locals, then all remotes)
//
// Usage: add_db_server(DS, DC, READ, WRITE, HOST, LAN_HOST, NAME, USER, PASS)
// EX: add_db_server('global', 'dc1', 1, 1,'global.mysql.example.com:3509','global.mysql.example.lan:3509', 'global-db', 'globaluser', 'globalpassword');
//
// Note: you can also place this section in a file called db-list.php in wp-content
// EX: add_db_server('global', 'dc1', 1, 1,'global.mysql.example.com:3509','global.mysql.example.lan:3509', 'global-db', 'globaluser', 'globalpassword');
add_db_server('global', 'dc1', 1, 1,'localhost','localhost', 'dbname_global', 'root', '1');
add_db_server('0', 'dc1', 1, 1,'localhost','localhost', 'dbname_0', 'root', '1');
add_db_server('1', 'dc1', 1, 1,'localhost','localhost', 'dbname_1', 'root', '1');
add_db_server('2', 'dc1', 1, 1,'localhost','localhost', 'dbname_2', 'root', '1');
add_db_server('3', 'dc1', 1, 1,'localhost','localhost', 'dbname_3', 'root', '1');
add_db_server('4', 'dc1', 1, 1,'localhost','localhost', 'dbname_4', 'root', '1');
add_db_server('5', 'dc1', 1, 1,'localhost','localhost', 'dbname_5', 'root', '1');
add_db_server('6', 'dc1', 1, 1,'localhost','localhost', 'dbname_6', 'root', '1');
add_db_server('7', 'dc1', 1, 1,'localhost','localhost', 'dbname_7', 'root', '1');
add_db_server('8', 'dc1', 1, 1,'localhost','localhost', 'dbname_8', 'root', '1');
add_db_server('9', 'dc1', 1, 1,'localhost','localhost', 'dbname_9', 'root', '1');
add_db_server('a', 'dc1', 1, 1,'localhost','localhost', 'dbname_a', 'root', '1');
add_db_server('b', 'dc1', 1, 1,'localhost','localhost', 'dbname_b', 'root', '1');
add_db_server('c', 'dc1', 1, 1,'localhost','localhost', 'dbname_c', 'root', '1');
add_db_server('d', 'dc1', 1, 1,'localhost','localhost', 'dbname_d', 'root', '1');
add_db_server('e', 'dc1', 1, 1,'localhost','localhost', 'dbname_e', 'root', '1');
add_db_server('f', 'dc1', 1, 1,'localhost','localhost', 'dbname_f', 'root', '1');
логин root, пароль 1. Так же тут нужно указать эти названия которые мы регистрировали вначале: dbname_0, dbname_1…
Настройка move-blogs.php
Это самая важная часть. Здесь также формируется вывод разных ошибок.
$dbname = "multi"; //This is your current database
$blog_table_prefix = 'wp_'; //Prefix of your wpmu blog tables, most likely this won't need to be changed
$newdb_prefix = 'dbname_'; //This is the prefix of the db's you're moving your tables into - we assume they are all the same, if not, you're in trouble
//We need info to connect to the databases
$dbhost = 'localhost';
$dbuname = 'root';
$dbpass = '1';
//How many db's are you moving into (16, 256, or 4096)?
$db_scaling = '16';
$dbname = «multi»; //multi — это имя моей общей базы данных которую я хочу разделить на куски, нужно писать без префикса
$blog_table_prefix = 'wp_'; //это префикс в общей базе
$newdb_prefix = 'dbname_'; //новое имя
Логин, сервер и пароль, а так же количество баз.
$dbhost = 'localhost';
$dbuname = 'root';
$dbpass = '1';
$db_scaling = '16';
Теперь стоит пройти по адресу: localhost/wp-content/scripts/move-blogs.php
Жмём Click here.
Дожидаемся, когда закончится процесс, ссылка в адресной строке должна поменяться. После этого жмём clicking here для обновления страницы. Статус обновлен.
Теперь видно, что создалась одна глобальная база, в которой содержится wp_users и т.д.
Остальные два сайта помимо основного раскидало по другим базам в рандомном порядке, например, второй сайт попал в dbname_c, а третий в dbname_e.
Теперь нужно проверить, что случилось. Можно попробовав, например, записать пост в несколько сайтов и проверить, где они будут отображаться. И действительно, в новых и глобальной появляются записи.
В старую «multi» ничего не добавляется. Тогда, наверно, на этом всё. Пока что это только первые мнения об этой системе, выводы еще делать рано.
Нюансы multisite
Первое — это невозможность задать роли для новых зарегистрированных участников. Но для этого есть плагин. Помимо этого представим себе ситуацию, у вас два сайта — сайт 1 (основной) и сайт 2. Человек регистрируется на сайте 2 и он таки может теперь входить и отображаться на сайте 1, но вы его не видите из консоли сайта 1, несмотря на то, что он есть. Увидеть его можно или в общей сети, либо в сайте 2, с которого он совершил регистрацию.
Редирект регистрации
Если вы захотите регистрироваться через wp-login, wp-admin, wp-register с сайта 2, то вас перебросит на сайт 1. Как говорят разработчики multisite, это является логичным, так как аккаунт создаётся один для всей сети. Но это может быть неудобно и совсем не то что вам нужно. WooCommerce с его страницей My Account и шорткодом [woocommerce_my_account] поможет с нормальной регистрацией, так же можно использовать Login With Ajax.
Еще по теме
P.s Оказывается легко можно и объединять стили/скрипты у плагинов и включать только на определённых страницах. Multi-db выложен на гитхабе, не сразу увидел.
premium.wpmudev.org/forums/topic/multi-db-plugin-conlict-with-woocomerce
premium.wpmudev.org/forums/topic/db-error-could-not-list-tables-1
github.com/wpmudev/multi-db
premium.wpmudev.org/forums/topic/re-multi-db-plugin
maxtop.org/wordpress-otklyuchenie-skriptov
maxtop.org/wordpress-obedinenie-css-fajlov-stilej-otklyuchenie-zagruzki-lishnix-css-fajlov
bavatuesdays.com/wpmu-multi-db-tutorial
www.inmotionhosting.com/support/website/wordpress/heartbeat-ajax-php-usage
Ответы на вопросы
Может у кого-то ещё возникнут вопросы такие же.
Под потреблением имеется ввиду потребление места? Почему только 50%?
В прямом смысле потребление плагинов. Допустим у вас есть один сайт который использует 20-30 плагинов.
С помощью multisite вы делите его на 2 куска. Таким образом, что каждая его часть использует по отдельности по 10-15 плагинов. Например:
сайт.ру — это доска объявлений или каталог
сайт.ру/shop/ или shop.сайт.ру — это магазин внутри сайта.ру
сайт.ру использует одни 10-15 плагинов
сайт.ру/shop/ использует другие 10-15 плагинов
При этом вам не нужно беспокоиться о пользователях и про админку, так как вы управляете этими сайтами через одну и ту же админку и пользователи тоже общие.
(16, 256, 4096) Бред.
Это допустимое в плагине кол-во баз. Если у вас будет миллион сайтов в сети multisite — тогда они заполняться равномерно по этим базам, в таком случае нужно было бы лучше конечно выбирать 4096. Для этого почитайте wp-форумы. Миллион сайтов я не тестировал.
Но без этого плагина все эти миллион сайтов будут содержаться в одной единой базе.
define ('DB_SCALING', '16'); — А если потом будет 32 базы, то все поедет? :)
Ответ выше. Нужно изначально прикидывать сколько вам нужно их в зависимости от кол-ва сайтов. Использование multi-db это шаг в оптимизации базы для тех у кого уже есть очень много сайтов в режиме multisite.
Экономили на css/js, а взяли разрезали базу. Я логики не вижу. :)
В том чтобы для экономии js/css резать базу — логики нету. Разрез базы это уже второй этап после оптимизации js / css. Он не имеет отношение к ним.
Когда на сайте много плагинов (учитывая что ещё в самом сайте, шаблоне есть они и немало) тогда встаёт вопрос о том как разграничить всё это для разных частей сайта. Большое количество их плохо действует на админку, она начинает тормозить.
Multisite и без разреза базы решает вопрос самих плагинов чтобы их было меньше на каждом сайте или куске сайта.
Более хороший способ
Так как сам плагин multi-db является списанным и не поддерживается — есть ещё другое, лучшее решение и удобное — это SharDB
Работать с ним куда проще чем multi-db. И после более тщательной проверки я обнаружил что multi-db глючит с некоторыми плагинами, а этот shar-db не вызывает никаких проблем с ними же.
Сначала нужно распаковать файл db-settings.php в корень сайта, чтобы с ним на одном уровне лежал wp-config.php и подключить его в нём
/* Это всё, дальше не редактируем. Успехов! */
...
...
...
...
...
...
require_once('db-settings.php');
Его настройки
// If you have multiple datacenters you can come up with your own datacenter
// detection logic (php_uname?). This helps ensure the web servers try to
// connect to the nearest database servers first, then distant ones.
define( 'DATACENTER', '' );
function add_slave($read, $host, $lhost = '', $user = DB_USER, $password = DB_PASSWORD) {
global $slaves;
$slaves[] = compact('read', 'host', 'lhost', 'user', 'password');
}
/* Add your configuration here */
// how many characters of hexidecimal hash
$shardb_hash_length = 2;
// what is the prefix of your blog database shards (everything before the hexidecimal hash)
// Префикс вашей базы
$shardb_prefix = 'set';
// set a string to be used as an internal identifier for the dataset
$shardb_dataset = 'abc';
// do you want to put your primary blog (blog_id 1) in its own 'home' database?
$enable_home_db = true;
// how many, if any, VIP databases do you have?
$num_vipdbs = 5;
// add this to set the write master read priority (default 1)
$shardb_master_read = 99;
// add this if all of your databases are on a local server
// Добавить это, если все ваши базы находятся на локальном сервере
$shardb_local_db = true;
// use this function to add a read slave host
add_slave($read_priority, $hostname, $local_hostname, $user, $password);
// instructions for adding vip blogs at the bottom of this confg filei
/* That's all, stop editing! Happy blogging. */
set — это имя базы в которой содержатся все сайты.
Далее скопировать файл shardb-admin.php в папку с плагинами, как обычно, активировать этот плагин для сети.
После чего в админке перейти к настройкам плагина. Управление сетью ---> Настройки--->SharDB Migration.
И тут первый шаг — это Migrate Global Tables. Он предложит записать её в отдельную таблицу — в setglobal
Далее первый сайт
Если база называлась «set» то он предлагает переместить её в sethome
Всё копируется нормально, можно копировать далее всё сайты, «Migrate Sites»
И так далее… нумерация сайтов и ихние таблицы отображаются на экране. Названия таблиц в которые хочет записывать плагин так же видны.
После того как всё на месте нужно распаковать файл db.php в папку wp-content
Теперь в админке виден статус тех сайтов которые я например не докопировал, там видны и желаемые таблицы с новыми названиями для каждого из них.
Соединение не удалось — это сообщение выводит db.php. Если этот файл у вас лежит в wp-content, он по умолчанию пытается подключаться к разным базам по отдельности, а не к одной общей. Если перенести все остальные сайты по такому же принципу — то они тоже будут работать.
Для копирования баз у вас не должно быть файла db.php, иначе будет не доступен пункт настроек в админке (SharDB Migration), после копирования нужно его загружать в последнюю очередь. Он служит просто связывающим звеном.
При создании нового подсайта нужно удалять на это время или переименовывать файл db.php и потом по желанию по такому же методу его отделять в другую базу.
Эта мера может не иметь для вас никакого значения если у вас немного сайтов. Но сама база движка имеет свойство засоряться с течением времени, и тормозить отклик от сайта. Если это бывает для одного сайта и одной базы, то имея режим multisite это будет в десятикратном+ размере так как все эти таблицы сайтов будут в одном месте.
Это ещё одна возможность движка которую в некоторых случаях можно использовать.
Комментарии (10)
vgray
03.08.2016 12:58+1Поясните пожалуйста какую проблему Вы решали?
В итоге у вас получилось 10 сайтов, с 10 разными базами, но которые используют одну кодовую базу.
Какие минусы у схемы, когда вы делаете 10 директорий, копируете в каждую из них код сайта и настраиваете 10 сайтов по отдельности?
В вашем случае вижу выйгрыш только в том, у вас код хранится в одном месте и занимает в 10 раз меньше места, чем в случае с 10 разными сайтами. Но 50-100 мбайт на хостинге — это вообще ни о чем, экономим на спичках.E_STRICT
03.08.2016 14:45в 10 раз меньше места, чем в случае с 10 разными сайтами
Сайтов может быть не 10, а 100 или даже 1000. Хотя я думаю, главное тут деплой. При обычном подходе пришлось бы вносить изменения в код каждого сайта по отдельности.
Альтернативное решение это использование какой нибудь системы контроля версий.
Rathil
04.08.2016 08:52А ОбКешер? Если вы положите каждый сайт в свою папку, ему придётся закешировать и держать в память в Н (сколько сайтов) раз больше данных!
alex1nd
05.08.2016 00:37Никакую проблему особо не решал. Это просто небольшой эксперимент, сам режим имеет суть общей базы, я попытался сделать отдельные.
10 директорий, копируете в каждую из них код сайта и настраиваете 10 сайтов по отдельности
Так нельзя будет на всех десяти таких сайтах использовать одну учётную запись для пользователя — в этом суть multisite — и ещё управление всеми сайтами через одну панель — это экономит время.
Есть ещё что-то вроде такого для объединения в одну панель,
https://managewp.com/
https://infinitewp.com/
Если при нескольких небольших сайтах разницы почти нет, что одна база что несколько — но если таких сайтов будет больше то это лучше чем все в 1-ой. Особенно это помогает тем у кого сотни и тысячи сайтов в режиме multisite в одной базе. Когда-то давно купил я сайт на telderi — и вроде бы оптимизировал его — но что-то всё время мне писало что отклик плохой. И я никак не мог найти корень проблемы. Потом увидел что в базе куча таблиц и весит она довольно много для обычного блога. В итоге вычистил все оттуда — весила 30 мб стала 2 мб — тогда сразу отклик от сайта стал мгновенный. С тех пор пошли такие опасения у меня.
web2033
03.08.2016 14:53+2Плагины, скачанные с неофициального репо, как минимум должны вызвать подозрение (речь о упомянутом multi-db, которого в бесплатном доступе нет)
safari2012
03.08.2016 18:15Подскажите, кто знает хорошо связку wp/woocommerce. Этот мультисайт режим позволит иметь на одном wp несколько интернет магазинов?
Lailore
Эм… проблема в архитектуре движка решается дичайшим костылем? Или я что-то путаю?
Даже в битриксе компоненты подключают свои css и js только когда используются :)