Почему роли не отображаются в мультисайтовой сети WordPress?

11 мар. 2011 г., 02:05:38
Просмотры: 17.5K
Голосов: 17

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

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

Можно ли это исправить?

Ниже изображение текущей ситуации.

Роли не отображаются

Ниже показано изображение основного сайта, где роли отображаются корректно, в отличие от подсайтов сети.

Роли отображаются

0
Все ответы на вопрос 7
7
34
  1. Определите ID вашего блога в Multisite. В качестве примера я буду использовать 99
  2. Зайдите в базу данных
  3. Перейдите в таблицу: wp_##_options (wp_99_options) — у вас будет отдельная таблица для каждого блога
  4. Найдите запись, где option_name = wp_user_roles
  5. Измените текст 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, и здесь это выглядит как баг при создании таблицы.

19 июл. 2011 г. 23:27:18
Комментарии

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

ZaMoose ZaMoose
17 сент. 2011 г. 19:48:27

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

Xananax Xananax
15 дек. 2011 г. 17:09:05

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

Paolo Paolo
19 февр. 2013 г. 11:36:33

Блестящий ответ!

jnthnclrk jnthnclrk
26 авг. 2013 г. 18:36:40

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

Xhynk Xhynk
17 нояб. 2014 г. 23:59:37

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

Privateer Privateer
6 окт. 2017 г. 17:36:18

Спасибо, отличный ответ, который недавно спас меня при миграции/объединении. Также комментарий Xhynk об изменённых префиксах крайне важен, если префикс изменяется при миграции/объединении!

Andrew T Andrew T
17 мая 2018 г. 18:38:49
Показать остальные 2 комментариев
0

У меня возникла эта проблема с установкой Multisite после переустановки WordPress и восстановления из резервной копии Updraft Plus.

Когда я проверил запись user_roles, параметр option_name всё ещё был установлен на оригинальный четырёхсимвольный префикс, например pre1_user_roles, тогда как префикс для второй установки был что-то вроде pre2_user_roles.

Я обновил его на pre2_user_roles, и параметры сразу же снова появились на странице пользовательских настроек.

23 мая 2017 г. 23:54:36
2

Если это та самая известная мне проблема, вы используете 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/>";
}
11 мар. 2011 г. 03:39:53
Комментарии

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

Geo Geo
11 мар. 2011 г. 04:50:12

Извините, что это не решило вашу проблему. Я часто сталкиваюсь с этим, поэтому это была моя лучшая догадка. Я бы продолжил изучать объект roles для того блога. Существует ли он? Обновил свой ответ выше, надеясь, что это поможет.

editor editor
11 мар. 2011 г. 20:24:06
0

СПАСИБО. Эта проблема заняла у меня целых 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();
  }
9 апр. 2018 г. 18:47:41
0

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

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

4 дек. 2014 г. 06:28:44
1

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

  1. Перейдите в таблицу wp_usermeta
  2. Найдите все записи с meta_key wp_capabilities
  3. Измените meta_key с wp_capabilities на wp_1_capabilities

Я считаю, что "1" всегда является ID корневого сайта.

Удачи.

21 июл. 2016 г. 21:41:27
Комментарии

Префикс wp_ устанавливается в файле wp-config.php и по умолчанию имеет значение wp_. Цифра 1 действительно обозначает корневой сайт. Однако это не обязательно должна быть 1, так как это уникальный инкрементируемый ID, который генерируется автоматически.

kaiser kaiser
21 июл. 2016 г. 22:05:34
0

Установите этот плагин: https://wordpress.org/plugins/capability-manager-enhanced/

Перейдите в админку вашего сайта > Capabilities > Settings > Backup > Reset Roles, нажмите "Reset to WordPress Defaults" и это исправит ваш сайт.

Ничто другое у меня не сработало.

4 нояб. 2021 г. 16:30:24