Причина:
Когда JSite (наследник от JApplication) инициализируется, то он пробует запустить новый сеанс. А это требует записи в таблицу сессии #__session. При подключения к базе данных при некорректном или отсутствии параметра вызывается JError:: raiseError. Настройки по умолчанию JError указывают, что заданная по умолчанию обработка ошибок уровня это — E_ERROR, который вызывает callback (откат), который в конечном счете опять вызывает запрос JError:: customErrorPage(). Он старается получить копию глобального объекта с JFactory:: getApplication (), который приводит опять к тому же самому исключению, которое будет вызываться снова и снова, вызывая бесконечную проблему цикла. Довольно запутанно, но что сделаешь, из песни слов не выкинешь!
1. В большинстве форумов предлагают такой вариант. Удивительно, как это копируется с одного форума на другой форум как единственное решение. Люди не присваивайте чужие решения, тем более ошибочные!
— Зайти на ftp в папку libraries->joomla->filesystem
— Скачать файл folder.php на ваш компьютер (не забудьте сделать резервную копию этого файлы)
— Открыть файл folder.php редактором и найти строку $obd = ini_get(’open_basedir’)
— Закоментировать ее // $obd = ini_get(’open_basedir’)
— Сохранить изменения и закачать файл назад на сервер.
В итоге конечно помогает, все радуются, ставят плюсы, но это чисто отношения к нашему вопросу не имеет. Обязательно находится кому не помог данный вариант решения проблемы. Следовательно основная причина не в этом.
Лучше не закомментить, а написать $obd = NULL с точки зрения прогера.
Этот вариант тесно связан JFolder::create: Path not in open_basedir paths
Warning! — Failed to move file
Это связано с тем, что разработчики намеренно заблокировали возможность создания каталогов на серверах, где значение параметра ‘open_basedir’ не совпадает с корнем сайта.
В таком случае вообще ничего не исправлять в folder.php. В настройках Apache для хоста или в php.ini установить -open_basedir «полный_путь_к_document_root:.» — где установлена Joomla и точка.
Так что файл folder.php — невиновен.
2. Второй вариант.
Предложение изменить тип configuration.php public $dbtype = ‘mysqli’; на public $dbtype = ‘mysql’;
Некоторым помогает, но обязательно найдется кто скажет: «А у меня не работает, не помогло».
3. Следующий вариант.
Настроить пути tmp, log.
public $log_path = ‘/home/u119234/adsmirnyru/www/logs’;
public $tmp_path = ‘/home/u119234/adsmirnyru/www/tmp’;
Многим помогает, но опять не всем.
4. А вся беда заключается в configuration.php и только в нем. Строк много, остановимся только на некоторых:
public $dbtype = ‘mysqli’; какой на локалке такой и должен быть на хостинге
public $host = ‘70.108.70.10’; поставьте свой
public $user = ‘u119234’; а это имя юзера
public $password = ‘v34cmAaK’; пароль юзера
public $db = ‘b119234’; имя базы данных
public $dbprefix = ‘jos_’; внимание, это префикс таблицы, хостер всегда меняет, если он ставят joomla
public $log_path = путь к logs;
public $tmp_path =путь к tmp; пишется полный путь в ‘’ одинарных
Совет: через свой хостинг «доберитесь» до своей базы данных MySQL, т.е. запустите phpMyAdmin.
Он требует пользователя, пароля, имени базы данных. Если вы раскрыли базу данных — отлично. Вот эти данные проставьте в строки configuration.php. И еще проверьте, какой префикс. С путями надеюсь, понятно.
Обычно этого бывает достаточно, чтобы проблема исчезла. Если проверка «спотыкается» на одном из строк configuration.php при подключении к базе данных – идет прерывание и в «штопор», т.е в «бесконечный цикл».
В подтверждении последнего варианта, пришло письмо от хостера:
В новогодние праздники произошел взлом некоторых сайтов хостинга, который чаще всего выглядел как удаление одной или нескольких таблиц из баз данных mySQL. Анализ показал, что злоумышленник подключался к базам данных mySQL извне с использованием пароля вашей базы данных.
Для того, чтобы обеспечить сохранность ваших данных, мы предприняли ряд мер, которые затруднят подключение, но мы также приняли решение немедленно изменить пароль на mySQL базу данных для одной или более баз вашего аккаунта.
Затронута база данных: gbua
К сожалению в этой ситуации ваш сайт вероятно прекратит работу, так как в конфигурационных файлах вашего сайта хранится старый пароль. Для продолжения работы необходимо посмотреть текущий пароль к базе данных на странице «пароли на ресурсы» в личном кабинете, и затем прописать его в конфигурационный файл вашего сайта по FTP.
Файл называется обычно configuration.php, settings.php, db_connect.php или как-то аналогично.