Короткий ответ: если база доступна по SSH, создаем отдельного пользователя под сайт, выдаем права только на нужную базу, проверяем вход через консоль и только потом обновляем core/config/config.inc.php. Root в конфиг сайта не пихаем, диагностические файлы после проверки удаляем, а mysql_connect оставляем археологам.
Если задача просто поднять MODX после переноса, смены пароля или веселого админского эксперимента в духе "я тут чуть-чуть поправил", обычно хватает именно этого сценария.
Что понадобится
- SSH-доступ к серверу;
- доступ к MySQL или MariaDB под пользователем с правом создавать пользователей БД;
- имя базы данных сайта;
- доступ к файлу
core/config/config.inc.php.
Подключаемся к MySQL или MariaDB
Обычный вариант:
mysql -u root -p
Если на сервере используется бинарник MariaDB:
mariadb -u root -p
Проверяем, что база на месте
SHOW DATABASES;
Если база есть, переключаемся на нее:
USE aboutcmsbase;
Создаем отдельного пользователя для сайта
Не надо жить под root из приложения. Root хорош для администрирования, но не для круглосуточной работы сайта.
CREATE USER 'modx_user'@'localhost' IDENTIFIED BY 'StrongPasswordHere';
GRANT ALL PRIVILEGES ON aboutcmsbase.* TO 'modx_user'@'localhost';
FLUSH PRIVILEGES;
Проверяем, что права действительно выданы:
SHOW GRANTS FOR 'modx_user'@'localhost';
Проверяем вход новым пользователем
mysql -u modx_user -p aboutcmsbase
Если зашли без ругани, уже отлично. Мир не идеален, но база хотя бы не хлопает дверью перед носом.
Что менять в MODX
Откройте файл core/config/config.inc.php и обновите значения:
$database_user = "modx_user";
$database_password = "StrongPasswordHere";
$dbase = "aboutcmsbase";
После этого очистите кэш MODX и заново проверьте вход в менеджер.
Как проверить подключение без legacy-кошмаров
Если очень хочется сделать тестовый PHP-файл, используйте mysqli, а после проверки удаляйте его сразу. Не надо оставлять в корне сайта диагностический скрипт как памятник беспечности.
<?php
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
$mysqli = new mysqli("localhost", "modx_user", "StrongPasswordHere", "aboutcmsbase");
$mysqli->set_charset("utf8mb4");
echo "OK, база отвечает";
Пошаговое решение, если MODX после переноса упрямится
- Проверить, что база существует и доступна по SSH.
- Создать отдельного пользователя БД или заново выдать ему права.
- Проверить вход этим пользователем через консоль.
- Обновить
core/config/config.inc.php. - Очистить кэш MODX.
- Если сайт все еще не ожил, проверить хост БД, порт, кодировку и права на файлы кэша.
Подводные камни
- Не давайте пользователю БД глобальные права на все базы, если ему нужна только одна.
- Не храните root-доступ в конфиге сайта.
- Если база на отдельном сервере, вместо
localhostпридется выдать доступ для нужного хоста. - Если после правки конфига MODX вход все равно не работает, проблема может быть уже не в базе, а в старом кэше, неверном хосте или испорченном переносе.
Современный вариант и альтернатива
Для новых проектов параметры подключения лучше сразу держать в управляемой инфраструктуре и не восстанавливать их потом по памяти, заметкам в Telegram и озарению в три часа ночи. Если проект уже давно живет, хотя бы храните доступы централизованно и используйте отдельного пользователя на каждую базу.
Связанные статьи
Актуально для: MySQL 8.x, MariaDB 10.5+, MODX Revolution 2.8+, MODX 3.x, PHP 8.1+.
Комментарии
Комментарии (0)