Программируем на CakePHP

Уметь быстро разбираться в чужом коде — страшно полезное умение. Сегодня звонил один из клиентов (пользуется у нас только хостингом). Говорит — так и так, закачал сайт, установил, настроил, потом поменял тему оформления у себя в движке — и теперь не могу зайти, все время выдает 404 ошибку.

Полез смотреть в чем дело.

Движок оказался — e107, я его честно говоря не люблю. По структуре ничего, но оформление — никакое. В хорошем движке как в человеке — все должно быть прекрасно, и код, и внешний вид админки, и дизайн сайта по-умолчанию. Все это говорит о внимательности авторов движка к деталям и серьезности разработки.

Вход в админку происходит через скрипт http://example.com/login.php. Он, как не трудно догадаться, отображает форму логина. При заполнении и отправке формы вылезает та самая ошибка 404. Одного взгляда на строку адреса хватило, чтобы понять почему вылезает ошибка — форма переадресовывалась на https://example.com/login.php — то есть на защищенное соединение. А поскольку заказчик SSL на хостинге себе не заказывал, то естественно у него вылезала ошибка. Но ведь еще утром админка исправно работала. Что же произошло при смене темы оформления?

Начал смотреть исходники файла login.php. Там самого кода формы нет, зато в строке 48 есть вызов шаблона формы логина login_template.php, который ищется в папке с текущей темой. Ну, думаю, попался! Просматриваю все каталоги с темами, установленными заказчиком (их всего 16), но ни в одной папке нет файла login_template. Значит изменение темы оформления — ни при чем. На всякий случай просматриваю шаблон формы логина по-умолчанию (в папке themes/templates), но в нем форма создается просто вызовами вида $rs->form_open(), $rs->form_close(), и т.п.

Еще раз перечитываю исходник файла login.php. В самом начале, в 20 строке, подгружается файл class2.php. Читаю его чтобы понять порядок загрузки, порядок обработки запроса и представить диаграмму классов. После инициализации кеширования, загрузки и обработки параметров из запроса, установки переменных по-умолчанию и подключения обработчиков ошибок, встречается интересный комментарий:

1

//clever stuff that figures out where the paths are on the fly.. no more need fo hard-coded e_HTTP :)

И следом за ним загрузка файла e107_class.php. Похоже что разбор и обработка URL-адресов в этом файле.

Открываю его, там на первой же странице вторая функция set_base_path():

1
2
3
4
5

function set_base_path()
        {
                global $pref;
                $this->base_path = ($pref['ssl_enabled']==1 ?  $this->https_path : $this->http_path);
        }

Читает переменную конфигурации ssl_enabled, и если она равна единице — считает, что надо работать с SSL. Где сохранена эта переменная? В файле e107_config.php ничего похожего нет, зато есть реквизиты доступа к базе данных. Смотрим базу данных — это уже чистая догадка, многие движки хранят настройки в БД. И действительно — в таблице e107_core, в записи с e107_name = ‘SitePrefs’, есть эта переменная, и она установлена в 1. Меняю на ноль — админка начинает исправно работать.

Вывод: тема оформления не при чем, клиент сам по-ошибке включил безопасный режим в админке и не смог больше ей пользоваться. Отлючить SSL можно было только через базу или редактированием базовых файлов движка. А для того, чтобы все это понять и исправить — нужен опыт работы с разнообразными движками и умение читать чужой исходный код.

Вот такой 5-минутный детектив из жизни php-программиста

Теги: php, движок, ошибка