Почитать другие заметки или статьи

Вчера мне досталась нетривиальная задачка. Заказчик предоставил сайт, где располагался весьма интересный модуль выбора городов. Каждый город формально открывался на отдельном поддомене, но физически все располагалось в одном каталоге. То есть, Joomla одна, а сайтов много.

Создавал сие чудо опытный пользователь Joomla, однако, не программист.

Это достаточно хорошо прослеживалось при анализе кода сайта.

Впрочем, чудо работало и всех всё устраивало.

До вчерашнего дня.

Когда по неизвестной причине стал осуществляться редирект с поддоменнов на «центральный» сайт.

Для посетителя это выглядело, так, как-будто выбор городов не работал.

А он, собственно говоря, и не работал.

Был ли редирект?

Честно говоря, первая моя мысль была о том, что собака зарылась на сервере и нужно писать техподдержке хостинга.

Однако, в течении получаса выяснилось, что административная панель сайта прекрасно открывается на поддомене.

Более того!

Если на фронтальной части сайта я вызывал страницу ошибки, например, вводил неверный адрес страницы, переадресация также не происходила.

Системный плагин во всём виноват

Всё указывало на то, что редирект осуществляет один из системных плагинов, только вот незадача:

При последовательном отключении всех активированных системных плагинов переадресация никуда не исчезала.

Как сделать редирект в Joomla?

Нужно отметить, что вся идеология построения компонентов в Joomla построена на редиректе.

В Joomla для него существует отдельный метод. И он достаточно часто используется.

Поэтому поиск по файлам сайта вряд ли поможет найти место, где запускается переадресация.

Создать редирект можно так:

use Joomla\CMS\Factory;

$url = '/page'; // Страница, куда будет осуществляться редирект
$app = Factory::getApplication();
$app->redirect($url);

Это будет работать, как для Joomla 3, так и для Joomla 4 и Joomla 5.

Работая с данной CMS следует понимать: если в коде встретился метод запускающий редирект, то всё, что будет написано после $app→redirect($url) — не запустится.

Кто виноват и что делать?

Чтобы найти скрипт, запускающий редирект, мне пришлось сделать временный хак в системном файле Joomla, а именно внести изменения в метод redirect класса AbstractWebApplication.

Происходило сие здесь:

libraries/vendor/joomla/application/src/AbstractWebApplication.php

Как узнать, какой скрипт вызвал функцию?

В PHP есть замечательная функция, позволяющая узнать: кто именно посмел вызывать исследуемую функцию или метод.

Называется она: debug_backtrace

Функция возвращает массив с данными, при просмотре которого можно увидеть не только пути к файлам, но и номера строк, где происходил вызов, а также список переменных.

При этом, если вы попробуйте вывести на экран всё то, что возвращает функция, с большой вероятностью из за нехватки оперативной памяти получите 500 ошибку.

Проблема заключается в том, что Joomla начиная с 4 версии в своих системных переменных хранит огромный массив данных. И если тщательно порыться, там можно найти кратчайший путь к Альфе Центавра и многое другое.

В моем расследовании мне было достаточно понять: какой именно скрипт вызывал редирект.

Поэтому в начало метода redirect класса AbstractWebApplication я добавил следующий код:

$scripts = debug_backtrace();

foreach ($scripts as $script) {
	echo $script['file'];
	echo '
'; } die();

Выполнение этого кода выведет на экран список файлов, где осуществлялся запуск скриптов перед вызовом метода redirect.

Таким образом, я смог выяснить:

Причиной всех бед был плагин под названием «Aimy Canonical».

Располагался он в каталоге:

plugins/system/aimycanonical/

Костыли, костыли, костыли…

Если вы внимательно читали эту заметку, могли обратить внимание на абзац, где я рассказывал о том, что ещё в начале своего расследования последовательно отключал все системные плагины.

И это никак не решало проблему.

Как только я обнаружил плагин, который создавал никому не нужный редирект, я с огромной радостью пошел и еще раз отключил его в административной панели.

И это конечно же опять не помогло.

Что заставило меня несколько удивиться.

Расследование продолжилось и позволило выяснить, что некий любитель костылей, работавший над сайтом ранее, подключил файл плагина напрямую в своем скрипте.

Как итог: помогла правка плагина.

Однако, это уже совсем другая история.

Заключение

Что хочется сказать…

Друзья! Прежде чем вставлять очередной костыль, подумайте о потомках. О тех, кто будет править ваш код спустя столетия.

При этом если у вас появились вопросы и предложения, с радостью жду их в своей группе VK по ссылке:

https://vk.com/sitogon

С уважением, Владимир Егоров