Если не получается зайти в backend (manager)
Не смог сегодня зайти в backend modx'а, никаких ошибок.
Как обычно ввожу логин пароль, жму сабмит и происходит рефреш страницы с логином,
а в таблицу modx_session пишет:
и тут не хватает вот этого modx.mgr.user.config|a:0:{}, то есть должна быть такая запись
Эту тему уже разжевывали много раз но конкретной инструкции которую можно положить в закладки я не увидел.
Сайт rtfm.modx.com по этой теме пишет
Для исправления бага: нужно зайти в phpmyadmin найти там таблицу «modx_system_settings» и в ней удалить поля
session_name
session_cookie_path
session_cookie_domain
или в phpmyadmin жмем кнопку «SQL» а в поле SQL-запрос вставляем
после чего найти таблицу modx_session и очистить ее,
или так же через запрос (взято у MerinovKV)
далее зайти в файлы сайта в директорию /core/ и переименовать (так быстрее если через ftp) директорию /core/cache/ (например в cache1)
После чего в backend меня лично пускает без проблем )))
P.S. Перед использованием сделайте копию (backup) своей базы, а за сохранность ваших данных я не отвечаю.
Как обычно ввожу логин пароль, жму сабмит и происходит рефреш страницы с логином,
а в таблицу modx_session пишет:
modx.user.contextTokens|a:1 {s:3:"mgr";i:1;}modx.mgr.user.token|s:52:"modx554f612353d315.46764236_1554f822a159273.83157853";modx.mgr.session.cookie.lifetime|i:0
и тут не хватает вот этого modx.mgr.user.config|a:0:{}, то есть должна быть такая запись
modx.user.contextTokens|a:1:{s:3:"mgr";i:1;}modx.mgr.user.token|s:52:"modx554f612353d315.46764236_1554f822a159273.83157853";modx.mgr.session.cookie.lifetime|i:0;modx.mgr.user.config|a:0:{}
Эту тему уже разжевывали много раз но конкретной инструкции которую можно положить в закладки я не увидел.
Сайт rtfm.modx.com по этой теме пишет
The login page keeps redirecting me back to the login screen with no error
This can happen with older Revolution beta installs. To fix it, delete the following 3 system settings from the DB table `[prefix]_system_settings` (where prefix is your table prefix):
session_name
session_cookie_path
session_cookie_domain
Then delete the core/cache/config.cache.php file.
Для исправления бага: нужно зайти в phpmyadmin найти там таблицу «modx_system_settings» и в ней удалить поля
session_name
session_cookie_path
session_cookie_domain
или в phpmyadmin жмем кнопку «SQL» а в поле SQL-запрос вставляем
ALTER TABLE `modx_system_settings`
DROP `session_name`,
DROP `session_cookie_path`,
DROP `session_cookie_domain`;
жмем ok (modx_ это префикс ваших таблиц)после чего найти таблицу modx_session и очистить ее,
или так же через запрос (взято у MerinovKV)
DROP TABLE IF EXISTS `modx_session`;
CREATE TABLE IF NOT EXISTS `modx_session` (
`id` varchar(255) NOT NULL DEFAULT '',
`access` int(20) unsigned NOT NULL,
`data` mediumtext,
PRIMARY KEY (`id`),
KEY `access` (`access`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
жмем ok (modx_ это префикс ваших таблиц)далее зайти в файлы сайта в директорию /core/ и переименовать (так быстрее если через ftp) директорию /core/cache/ (например в cache1)
После чего в backend меня лично пускает без проблем )))
P.S. Перед использованием сделайте копию (backup) своей базы, а за сохранность ваших данных я не отвечаю.
Комментарии: 12
1) Некоторые хостинг провайдеры не поддерживают rss фид modx securty + modx news (Не знаю почему).
Ошибка 504 server time-out
Чтоб решит эту проблему добавте в url
2) Как то после установки на папку core/cache/ chmod стоит 755 на папках а на файлах 644 из за этого админка пустует измените права на всех папках и фалов на 777.
3) Смените хостинг на modhost.pro и живите без проблем!
Ошибка 504 server time-out
Чтоб решит эту проблему добавте в url
site.ru/manager/?a=system/dashboards/update&id=1
После этого удалите эти 2 фида и сохраните.2) Как то после установки на папку core/cache/ chmod стоит 755 на папках а на файлах 644 из за этого админка пустует измените права на всех папках и фалов на 777.
3) Смените хостинг на modhost.pro и живите без проблем!
Rahim Egamov, спасибо за 5 коп
1. А я вообще первым делом убираю все в dashboards )))
2. Ну как то совсем не гуманно 777 ставить
3. Из Штатов и Азии пинги не айс, а для России вообще супер
1. А я вообще первым делом убираю все в dashboards )))
2. Ну как то совсем не гуманно 777 ставить
3. Из Штатов и Азии пинги не айс, а для России вообще супер
Судя по разделу и заголовку — это готовое решение для того, чтобы завалить админку?
Сергей, поясни
Сергей, а вы до конца дочитали?
Виноват. Признаюсь, не дочитал. :)
Поправил название топика ))) дабы не вводить в заблуждение.
После того как изменил настройки
на «ДА», постоянно выкидывало сообщение о том, что время сессии истекло и требовало авторизоваться. Разумеется ввод авторизации ни к чему хорошему не приводил.
Приводило всё вышеизложенное как раз к тому, что и озвучил автор. Вылечил тем, что откатил на хосте базу на 2 дня, после чего смог зайти на 1 мин в админку, быстро изменив настройки обратно на «НЕТ». После чего мне опять выкинуло сообщение об истёкшей сессии, но после обновления страницы и повторной авторизации уже зашло без проблем. Пишу на случай может кому поможет.
P.S. На счёт способа описанного автором. Зачем переименовывать кэш, и нарушать таким образом пути прописанные в ядре, если в инструкции было сказано всего лишь удалить config.cache.php file из кэша? Проще было удалить всё из /core/cache/, если искать этот самый config.cache.php file лень. Может я чего не знаю, конечно… Не настаиваю.
P.S.S. Может ли проблема быть в том, что дата изменённых полей от 2016 года, а остальные поля 1970? И отсчёт сессии идёт от 70 года, соответственно сессия по умолчанию просрочена изначально. Но по идее привязка должна идти к дате входа в сессию по системному времени… Почему вообще такая ситуация возникает?
на «ДА», постоянно выкидывало сообщение о том, что время сессии истекло и требовало авторизоваться. Разумеется ввод авторизации ни к чему хорошему не приводил.
Приводило всё вышеизложенное как раз к тому, что и озвучил автор. Вылечил тем, что откатил на хосте базу на 2 дня, после чего смог зайти на 1 мин в админку, быстро изменив настройки обратно на «НЕТ». После чего мне опять выкинуло сообщение об истёкшей сессии, но после обновления страницы и повторной авторизации уже зашло без проблем. Пишу на случай может кому поможет.
P.S. На счёт способа описанного автором. Зачем переименовывать кэш, и нарушать таким образом пути прописанные в ядре, если в инструкции было сказано всего лишь удалить config.cache.php file из кэша? Проще было удалить всё из /core/cache/, если искать этот самый config.cache.php file лень. Может я чего не знаю, конечно… Не настаиваю.
P.S.S. Может ли проблема быть в том, что дата изменённых полей от 2016 года, а остальные поля 1970? И отсчёт сессии идёт от 70 года, соответственно сессия по умолчанию просрочена изначально. Но по идее привязка должна идти к дате входа в сессию по системному времени… Почему вообще такая ситуация возникает?
Добрый день, подскажите как решить проблему авторизации.
Перестали подходить пароли в админку, через phpmyadmin менял пароли администратору по хешу md5, пароль меняется — в админку не пускает.
вроде бы это готовое решение, но возможно для старых версий modx, у меня 1.4.+
и решение не подходит
"" Для исправления бага: нужно зайти в phpmyadmin найти там таблицу «modx_system_settings» и в ней удалить поля
session_name
session_cookie_path
session_cookie_domain
""
тк нет таких полей в таблице
— по советам предыдущих комментаторов удалял файл config.cache.php
-в базе менял значения таблицы
session_cookie_httponly 0
session_cookie_secure 0
-Откатывал только базу mysql на дамп за полчаса до манипуляций с сервером, авторизоваться так и не получается.
Подскажите куда делись эти поля в таблице и как решить проблему. Спасибо.
Перестали подходить пароли в админку, через phpmyadmin менял пароли администратору по хешу md5, пароль меняется — в админку не пускает.
вроде бы это готовое решение, но возможно для старых версий modx, у меня 1.4.+
и решение не подходит
"" Для исправления бага: нужно зайти в phpmyadmin найти там таблицу «modx_system_settings» и в ней удалить поля
session_name
session_cookie_path
session_cookie_domain
""
тк нет таких полей в таблице
— по советам предыдущих комментаторов удалял файл config.cache.php
-в базе менял значения таблицы
session_cookie_httponly 0
session_cookie_secure 0
-Откатывал только базу mysql на дамп за полчаса до манипуляций с сервером, авторизоваться так и не получается.
Подскажите куда делись эти поля в таблице и как решить проблему. Спасибо.
Парни проблема решилась, трабл был в том что прервал обновление версии modx с 1.4 на 1.5
отпала аутентификация,
возобновил обновление движка, с модулем Simpleupdater все данные об базе подтянулись ничего не вводил, только далее.
После обновления смог нормально залогинится. мой косяк, сорян что отвлек пару уважаемых человек в личке.
отпала аутентификация,
возобновил обновление движка, с модулем Simpleupdater все данные об базе подтянулись ничего не вводил, только далее.
После обновления смог нормально залогинится. мой косяк, сорян что отвлек пару уважаемых человек в личке.
Все прогуглил, ничего не помогало из этого:
1) Зайти из под инкогнито или с другого браузера
2) Чистка кэшей, куки
3) Чистка modx_session
В общем накатил версию 2.8.4 сделал обновление через setup и пустило
1) Зайти из под инкогнито или с другого браузера
2) Чистка кэшей, куки
3) Чистка modx_session
В общем накатил версию 2.8.4 сделал обновление через setup и пустило
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.