В данной статье я постараюсь детально раскрыть тему хаков, и расскажу про правильный подход к разработке сайтов на Joomla, который позволит их не допускать.
Данная статья будет полезна всем – как разработчикам сайтов на Joomla, так и владельцам сайтов.
Что такое «хак»?
«Хак» Joomla (Joomla Core hack – англ.) – внесение изменений в файлы Joomla, которые могут быть перезаписаны при обновлении.
У вас есть сайт на Joomla. Предположим, вы хотите внести некоторые изменения в код. Вы вносите эти изменения. Проходит время. Выходит обновление Joomla (возможно небольшое, просто правка багов). Вы устанавливаете обновление. Файл, в который вы вносили изменение, перезаписывается. Ваше изменение пропадает. Вот и весь смысл.
Откуда берутся хаки?
По умолчанию в Joomla хаков нет, и быть не может. Это следует из определения хака. Хаки могут быть внесены только человеком. Им можете быть вы или недобросовестный программист, который работал над вашим сайтом.
Хаки могут быть не только в Joomla, а также в расширениях Joomla, например, Virtuemart. Смысл там такой же, как и с хаками Joomla, только речь идет про обновление расширений.
Joomla плохая CMS?
Нет. Хаки свойственны любой CMS с открытым (да и частично закрытым) исходным кодом (да, и WordPress, и Drupal, и Bitrix). Если вы можете изменить хотя бы один стандартный файл CMS, значит, вы можете внести хак.
Хаков не может быть только в CMS с полностью закрытым исходным кодом. Я таких не знаю. Это уже, скорее, самописный продукт, в котором не предполагается внесение изменений никем, кроме разработчиков такого продукта.
Как не допускать хаков?
По понятным причинам желательно не допускать создания хаков на вашем сайте. Как этого можно добиться? Есть несколько способов. Здесь уже важна CMS. В каждой их них имеются свои механизмы. Мы поговорим, разумеется, про Joomla.
Предположим, у вас есть сайт на Joomla, и вам требуется внести некоторые изменения в его код. Есть два способа не допускать хаков в Joomla:
- Переопределение существующих макетов Joomla или создание альтернативных макетов
- Создание плагинов Joomla
Рассмотрим каждый способ подробнее.
Как не допускать хаков? Переопределение макетов и альтернативные макеты.
Уже много сказано на эту темы, но повторим еще раз.
Если вам нужно внести изменение в файл отображения той или иной страницы сайта, в первую очередь вы должны найти ее макет и переопределить его в используемый вами шаблон Joomla. Это относится не только к Joomla, но и ее расширениям: модулям и компонентам.
Как понять, есть ли макет для той или иной страницы? Всё просто. Если есть страница, то есть и макет. В Joomla используется паттерн MVC. Ему следуют и разработчики расширений Joomla. Это означает, что каждый компонент и модуль Joomla содержит в себе папку views, в которой хранятся все его макеты. Вам нужно выбрать подходящий макет, скопировать его в используемый шаблон Joomla и уже в нем вносить изменения.
Какой в этом смысл? Когда Joomla нужен тот или иной макет для отображения, она сначала ищет его в шаблоне и лишь затем берет стандартный из расширения. Это сделано специально для того, чтобы можно было избегать хаков. Когда вы скопируете макет в шаблон Joomla, этот скопированный файл уже не будет файлом ядра. Его вы можете изменять, как хотите. При обновлении Joomla он не перезапишется, а значит хака не будет.
Ниже пишу общие правила переопределения макетов в шаблон Joomla. Это очень важная и полезная информация. Скопируйте ее себе. Запишите себе. Добавьте статью в закладки. А если вы работаете с Joomla часто, просто выучите ее наизусть.
Переопределение макета компонента в шаблон Joomla:
Скопируйте файл:
components/[название_компонента]/views/[тип_макета]/tmpl/[название_макета].php
в:
templates/[название_шаблона]/html/[название_компонента]/[тип_макета]/
и редактируйте уже там.
Переопределение макета модуля в шаблон Joomla:
Скопируйте файл:
modules/[название_модуля]/tmpl/[название_макета].php
в:
templates/[название_шаблона]/html/[ название_модуля]/
и редактируйте уже там.
Ниже привожу реальные примеры.
Пример переопределения макета статьи в шаблон Joomla Protostar:
Копируем файл:
components/com_content/views/article/tmpl/default.php
в:
templates/protostar/html/com_content/article/
и редактируем уже там.
Пример переопределения модуля последних статей в шаблон Joomla Protostar:
Копируем файл:
modules/mod_articles_latest/tmpl/default.php
в:
templates/protostar/html/mod_articles_latest/
и редактируйте уже там.
Вот и всё. На самом деле это предельно просто. Единственное, что хочу добавить – не следует злоупотреблять переопределениями. Переопределяйте только те файлы, в которых реально нужно внести изменения. Не переопределяйте все возможные макеты. Когда вы создаете переопределение, то условно соглашаетесь с тем, что данный конкретный файл у вас не будет получать обновления от разработчиков Joomla. Т.е., к примеру, если в модуле последних новостей разработчики добавят вывод изображений, а у вас будет переопределенный в шаблон макет, то вы не увидите этих изменений, т.к. обновленный файл не будет использоваться – будет браться ваш старый файл из шаблона.
В плане безопасности переживать не стоит. В макетах views крайне редко встречается функционал, способный повлиять на безопасность. Они используется именно для формирования отображения контента.
Помимо переопределения макетов (копирования в шаблон), вы также можете создавать и альтернативные макеты. Они могу помочь, когда нужно внести в макет изменение только в одном месте на сайте, а в другом использовать стандартный макет. Например, вы хотите показать в одном месте на сайте модуль последних новостей с изображениями, а в другом просто списком. В этом случае наиболее правильным решением будет создание альтернативного макета.
Как не допускать хаков? Плагины Joomla.
С макетами понятно. Но что, если изменения, которые необходимо внести, находятся не в макетах отображения (не в папке views)?
Здесь всё сложнее, но также предусмотрен механизм. В Joomla он называется плагинами. Плагины Joomla – это кусочки вашего кода, которые вы можете вставлять в некоторые места выполнения программы. Создавая плагин, вы можете получить необходимый дополнительный функционал, без внесения хаков. Например, SEBLOD практически целиком построен на плагинах. Благодаря этому он невероятно расширяет возможности Joomla без единого хака.
Если ничего не помогает.
А теперь самое интересное. Что делать, если ни один из описанных выше способов, вам не подходит? Что делать, если необходимо внести изменения в файл, который не покрывается ни переопределением макетов ни плагинами?
Здесь у вас есть два пути и оба они, к сожалению, не слишком-то хорошие.
Первый путь – сделать хак.
Да, хаки – зло. Но если их немного и они критически важны для вашего сайта, то не остается ничего, как мириться с ними. Здесь важно помнить золотое правило: «Сделал хак – сделай и документацию по нему». Если вы аккуратно записываете информацию по созданным хакам, то всегда сможете быстро их восстановить. Ад начинается, когда такой документации не ведется. Просто поверьте мне. Я знаю, о чем говорю. Когда к тебе приходит заказчик с задачей обновить Joomla 2.5 до Joomla 3 и сайтом, полным хаков без единой строчки информации по ним, то это не очень весёлая история.
Второй путь – сделать форк.
Первый путь, при котором вы делаете хаки, документируете их, и восстанавливаете после обновления, применим только в случае, когда хаков немного. Есть и другой случай – хаков много. Такое бывает крайне редко и обычно связано с тем, что CMS или расширение претерпевает масштабные изменения.
Если этот редкий случай именно ваш, то стоит подумать над тем, чтобы делать не хаки, а форк.
Форк – это процесс, когда вы берете за основу какое-либо открытое ПО, делаете его копию, и дальше начинаете разрабатывать и поддерживать полностью самостоятельно.
В случае создания форка, тема хаков для вас становится неактуальной, поскольку вы больше не получаете и не устанавливаете обновления. Теперь все правки, вносимые вами в системные файлы, это ваша, и только ваша ответственность.
Создавать форки могут позволить себе только хорошие программисты или команды программистов. Это довольно серьезная задача, а потому десять раз подумайте, действительно ли вам это нужно.
Мне встречались примеры, когда тот же Virtuemart 1.0.х превращался в полноценный форк. Это происходило, когда сначала вносились недокументируемые хаки разными людьми, а потом их становилось так много, что проще было уже поддерживать продукт своими силами, чем производить миграцию на новый Virtuemart и восстанавливать все накопившиеся изменения.