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

- Определите ID вашего блога в Multisite. В качестве примера я буду использовать 99
- Зайдите в базу данных
- Перейдите в таблицу:
wp_##_options
(wp_99_options) — у вас будет отдельная таблица для каждого блога - Найдите запись, где
option_name
=wp_user_roles
- Измените текст
wp_user_roles
наwp_##_user_roles
("wp_99_user_roles")
Таблица, которую вы редактируете, будет содержать поля option_id
, blog_id
, option_name
, option_value
, autoload
. Однако НЕ ИЗМЕНЯЙТЕ НИКАКИЕ ДРУГИЕ ЗАПИСИ, кроме записи, где option_name
= wp_user_roles
. В этой таблице будет только одна такая запись.
wp_user_roles
используется, когда нет установки Multisite, и здесь это выглядит как баг при создании таблицы.

Спасибо! Это просто спасительный совет. Это ТОЧНО правильный ответ.

У меня в таблице НЕ БЫЛО "wp_user_roles", что я сделал — скопировал содержимое wp_4_options>wp_user_roles (большой JSON-объект или сериализованный массив, не знаю) в новую запись под названием wp_5_options (это был блог с отсутствующими ролями), и это решило мою проблему. Тем не менее, поставил +1, потому что это направило меня на верный путь.

Я также решил проблему, УДАЛИВ запись "wp_##user_roles" из основной таблицы wp_options, потому что, похоже, она переопределяет ту, что находится в wp##_options.

Для людей, которые перенесли свой сайт и изменили префиксы, ошибка может быть в "wp_##user_roles" вместо "{new_prefix}##_user_roles"

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

У меня возникла эта проблема с установкой Multisite после переустановки WordPress и восстановления из резервной копии Updraft Plus.
Когда я проверил запись user_roles
, параметр option_name всё ещё был установлен на оригинальный четырёхсимвольный префикс, например pre1_user_roles
, тогда как префикс для второй установки был что-то вроде pre2_user_roles
.
Я обновил его на pre2_user_roles
, и параметры сразу же снова появились на странице пользовательских настроек.

Если это та самая известная мне проблема, вы используете memcache в вашей MU-установке? Я обнаружил, что существует проблема с кешированием (наблюдалось в версии 2.9) для объекта опций, когда что-то важное (например, ключ wp_user_roles) застревает в массиве "notoptions" memcache.
Если вы действительно используете memcache, и это похоже на вашу ситуацию, попробуйте подключиться к серверу через telnet на порт 11211. Введите delete blogid:options:notoptions
, где blogid — это ID блога, на котором вы наблюдаете проблему. Обновите админ-панель и проверьте, появились ли роли в выпадающем списке. Если да, вы нашли свою проблему.
ОБНОВЛЕНИЕ: Итак, проблема не нашлась — вы не использовали memcache. Я бы всё равно проверил объект ролей на предмет повреждений или его отсутствия. Думаю, это ваш лучший след. Вы можете использовать этот код для вывода содержимого таблицы опций:
global $wpdb;
$array = $wpdb->get_col("SELECT option_name FROM $wpdb->options");
foreach ($array as $key) {
echo $key . ": <code>";
var_dump(get_option($key), true));
echo "</code><br/>";
}

Редактор. Я не знаю, как memcache попал на мой сервер. Я вообще его не использую. Возможно, из-за того, что я установил w3 cache. Я попытался удалить его, но получил сообщение not_found. Я отключил memcache, так как не использую его. Но проблема осталась.

СПАСИБО. Эта проблема заняла у меня целых 10 часов отладки. Для меня это было действительно сложной задачей.
Чтобы расширить решение, я добавил функцию на свой сайт, которая поможет вам решить эту проблему, если вы создаёте сайты программно.
По сути, функция проверяет, было ли установлено значение wp_user_roles
в указанном блоге. Если да, функция использует wp_user_roles
для правильной установки новой опции.
/**
* Иногда роли пользователей не устанавливаются корректно при создании нового сайта
* Для исправления этой проблемы мы проверяем правильность добавления данных и обновляем при необходимости
* Смотрите https://wordpress.stackexchange.com/questions/11725/why-are-my-roles-not-visible-in-a-multi-site-network
*/
function maybeAddUserRoles($blog_id){
switch_to_blog($blog_id);
if(get_option('wp_user_roles')){
update_option('wp_'.$blog_id.'_user_roles', get_option('wp_user_roles'));
delete_option('wp_user_roles');
}
restore_current_blog();
}

Я просто хотел сказать спасибо за эту статью, потому что я долго искал решение этой проблемы.
Оказалось, что проблема была в том, что я использовал плагин для клонирования своих сайтов, и он никогда не обновлял таблицу wp_##_user_roles
должным образом. Когда сайт был скопирован из wp_13...
в новый сайт wp_81...
, эта запись оставалась привязанной к wp_13
.

Хочу обратить внимание, что у некоторых пользователей до сих пор может быть пустая таблица пользователей сайта — особенно для корневого сайта. Если вы столкнулись с этой проблемой, исправить её можно следующим образом:
- Перейдите в таблицу wp_usermeta
- Найдите все записи с meta_key wp_capabilities
- Измените meta_key с wp_capabilities на wp_1_capabilities
Я считаю, что "1" всегда является ID корневого сайта.
Удачи.

Установите этот плагин: https://wordpress.org/plugins/capability-manager-enhanced/
Перейдите в админку вашего сайта > Capabilities > Settings > Backup > Reset Roles, нажмите "Reset to WordPress Defaults" и это исправит ваш сайт.
Ничто другое у меня не сработало.
