После обновления до последней версии Вордпресса не могу зайти на /wp-admin/. Получаю сообщение "Вы не имеете достаточно прав для доступа к данной странице". Вроде бы все делал по инструкции, но в 2 часа ночи мог где-то и протупить.
Что сделано не так? Подскажите кто сталкивался с подобной проблемой.
А по инструкции бэкап делали?
Попробуйте вернуть все как было.
Хочется разобраться и запустить, вернуть можно в любое время.
Я тоже не мог зайти в админку когда поставил htaccess зашиту на папку wp-admin проверьте может у вас также.
Если я правильно понял, то это сообщение выдает WordPress.
Поэтому нужно обязательно разлогиниться. Запустить второй этап инстраляции (где комментарии убрать). После этого сбросить кэш браузера (Ctrl+F5) и очистить кэш WordPress (wp-content/cache). Все должно работать.
Да, это сообщение WordPress.
Проделал все манипуляции. Никакого результата. Уже пожалел, что затеял обновление.
В чем может быть причина? Я ведь все операции делал по readme.txt с самого начала.
Огромная благодарность Максиму за участие и личную помощь в решении моей проблемы.
Все закончилось почти благополучно 🙂
Разобрались. Значит ситуация такая, что кодировка базы данных по умолчанию стяла одна, а сопоставление другая. При этом данные вносились в кодировке базы. Получилась мешанина.
Настраивается это дело так.
В wp-config.php нужно выставить DB_CHARSET и DB_COLLATE в ту кодировку, которая указана в таблицах (сопоставление – в phpMyAdmin это видно).
Включить перекодировщик: define(‘MAXSITE_DB_CONVERT’, true);
Установить кодировку перекодировщика в туже, что и DB_CHARSET (utf-8 или win)
После этого на блоге должно быть корректное отображение текста.
Если после этого все равно нет входа, то выполните второй этап.
Если же и это не помогло, то с помощью phpMyAdmin откройте таблицу wp_options, в ней поле option_name со значением wp_user_roles – жмем редактировать и в option_value добавляем:
Этим самым мы обновляем все роли вручную.
Схожая проблема. Причем, если строки
define(‘DB_CHARSET’, ‘utf8’);
define(‘DB_COLLATE’, ‘utf8_general_ci’)
включить, то на сайте крякозябры, но в админку войти можно. Если выключить, весь текст в нормальном UTF-8, но появляется указанная проблема: "Вы не имеете достаточно прав для доступа к данной странице".
Включать перекодировщик пробовал, менять роли пробовал, не помогает.
База данных utf-8, "сопоставление" utf8_unicode_ci. Пробовал и в define(‘DB_COLLATE’ подставить utf8_unicode_ci, и в базе utf8_general_ci. На результат не влияет.
Кто-нибудь сталкивался?
Попробуйте вот-так
define(‘DB_CHARSET’, ‘cp1251’);
define(‘DB_COLLATE’, ‘cp1251_general_ci’);
Спасибо, сработало!
Но почему?!
Если база в utf и страница выводится в utf, зачем вот это все:
define(‘DB_CHARSET’, ‘cp1251’);
define(‘DB_COLLATE’, ‘cp1251_general_ci’);
define(‘MAXSITE_DB_CONVERT’, true);
define(‘MAXSITE_DB_CHARSET’, ‘cp1251’);
Почему сработало именно при таком сочетании?
Черт, теперь RSS крякозябрами. Может для него тоже какой-то конвертер включать надо?
Что за хостинг?
Peterhost
В .htaccess выставлена utf как default
Адрес doitq.ru
По базе данных. Сейчас про петерхост ничего не скажу, но раньше у них была принудительная отсылка windows-1251 в заголовке http. По базе данных – скорее всего реальная кодировка cp1251. Тут недавно у некоторых хостингов, например мажордомо и мастерхост были переходы на MySQL 5, но сделали они это через одно место, поэтому только ко мне обратилось человек 5 у которых вдруг слетела кодировка базы данных. Возможно что в петерхосте такая же ситуация. То есть нужно смотреть саму базу, можно попробовать сделать дамп и если нет вылетевших букв (в мажордомо буквы терялись), то попробовать перезалить таблицы в нормальной utf-8. Естественно перекодировщик в WordPress потом нужно отключить.
RSS у вас нормально отображается. Скорее всего кэш сработал, поэтому вы и видели старые искаженные данные.
Спасибо. С кешем я запутался, честно говоря. Вроде отключал и удалял, и фидберновский плагин отключил, но что-то вот…
В дампе базы, открытом текстовым редактором, вообще мешанина: большая часть текста в utf-8, но часть в другой кодировке. Если сейчас все работает, стоит ли заморачиваться с конвертацией? Тем более, что я не знаю, как конвертировать такой «частично не utf» текст.
Я так и думал, что на петерхосте ка были проблмы с кодировками, так и остались. 🙁
Нет, ничего не меняйте. У вас корректно отображается из-за того, что в моей сборке при включенном перекодировщике происходит анализ текста и при необходимости он перекодируется в кодировку блога. Поэтому в базе данных тексты могут находиться в разных кодировках.
Если решите обновиться и исправить все глюки, то лучше сделать это через импорт записей. Я на своем блоге описал этот процесс.
Спасибо еще раз. И вообще спасибо за вашу сборку.
поле wp_user_roles имеет наименование только по умолчанию, так как wp_
есть не что инное как префикс таблиц (заданный при инсталяции)
вот пример возникновения описанной ошибки:
данные из таблицы wp27_option перенесли в gr_wp_option,
следовательно поле wp27_user_roles в таблице gr_wp_option меняем на gr_wp_user_roles
gr_wp_ – это $table_prefix из файла wp-config.php
Такое же сообщение, как у ТС.
Установил плагин WP Security Scan (http://wordpress.org/extend/plugins/wp-security-scan/). Кроме всего прочего, он меняет префикс таблиц c wp_ на что-либо произвольное. Поменял.
Теперь при попытке зайти в админку получаю:
Вы не имеете достаточно прав для доступа к данной странице.
Подскажите, пожалуйста, куда копать?
Поиском надо пользоваться!
http://forum.maxsite.org/viewtopic.php?pid=53077
После нереноса сайта на новый хостинг И ДОМЕН. Получил такую ошибку: сайт открывается, а любая стираничка – нет, ерор 404.
Вылечил путем удаления в базе из строки permalink_structure всю инфомарцию.
Теперь все ссылки работают и все хорошо. Но не могу попасть в админ панель. Просто появляется белая страничка.
Если заменить всю таблицу wp_options в базе на новую, то все работает отлично. В таблице 400 записей, может быть знаете, какая из них может влиять на работу wp-admin?
Методом тыка установил что wp-admin останавливается грузитсья на строке require_once(ABSPATH . ‘wp-admin/includes/admin.php’);
Список активных плагинов.
Не думал….