В данной статье я постараюсь детально раскрыть тему хаков, и расскажу про правильный подход к разработке сайтов на Joomla, который позволит их не допускать.
Хаки в Joomla. Что это? Почему это плохо? Как избавиться.

Очень часто мне приходиться рассказывать заказчикам про хаки в Joomla. Хаки, в некоторых случаях, могут доставлять большие неприятности. В данной статье я постараюсь детально раскрыть тему хаков, и расскажу про правильный подход к разработке сайтов на 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. Подробный разбор простым языком.

Если ничего не помогает.

А теперь самое интересное. Что делать, если ни один из описанных выше способов, вам не подходит?  Что делать, если необходимо внести изменения в файл, который не покрывается ни переопределением макетов ни плагинами?

Здесь у вас есть два пути и оба они, к сожалению, не слишком-то хорошие.

Первый путь – сделать хак.

Да, хаки – зло. Но если их немного и они критически важны для вашего сайта, то не остается ничего, как мириться с ними. Здесь важно помнить золотое правило: «Сделал хак – сделай и документацию по нему». Если вы аккуратно записываете информацию по созданным хакам, то всегда сможете быстро их восстановить. Ад начинается, когда такой документации не ведется. Просто поверьте мне. Я знаю, о чем говорю. Когда к тебе приходит заказчик с задачей обновить Joomla 2.5 до Joomla 3 и сайтом, полным хаков без единой строчки информации по ним, то это не очень весёлая история.

Второй путь – сделать форк.

Первый путь, при котором вы делаете хаки, документируете их, и восстанавливаете после обновления, применим только в случае, когда хаков немного. Есть и другой случай – хаков много. Такое бывает крайне редко и обычно связано с тем, что CMS или расширение претерпевает масштабные изменения.

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

Форк – это процесс, когда вы берете за основу какое-либо открытое ПО, делаете его копию, и дальше начинаете разрабатывать и поддерживать полностью самостоятельно.

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

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

Мне встречались примеры, когда тот же Virtuemart 1.0.х превращался в полноценный форк. Это происходило, когда сначала вносились недокументируемые хаки разными людьми, а потом их становилось так много, что проще было уже поддерживать продукт своими силами, чем производить миграцию на новый Virtuemart и восстанавливать все накопившиеся изменения.

Надеюсь, тема хаков теперь для вас стала яснее. Если вы программист – будьте хорошим программистом и избегайте хаков. Если вы заказчик – пишите тех.задание для программистов, указывая в нем необходимость отсутствия хаков и создания переопределений. Поверьте, в будущем это сэкономит вам много сил, нервов и денег.

Если вы сомневаетесь в том, можно ли внести то или иное изменение в Joomla без создания хака – спросите у меня в комментариях к статье. Постараюсь подсказать. =).

Об авторе
Об авторе
Wedal (Виталий). Веб-разработчик полного цикла (Full Stack). Создатель и автор сайта Wedal.ru.
Основной профиль – создание сайтов и расширений на CMS Joomla.

Понравилась статья? Сохраните себе на стену:

Ваша оценка материала очень важна для нас. Просим вас оценить статью или оставить отзыв в комментариях.

Комментарии  

0 # А что с CSS?Александр 09.03.2018 15:04
Спасибо за такое разложение по полочкам. Перееопределения views в шаблон давно использую, но очень напрягает то, что в joomla нет такого же понятного механизма переопределения css. Например в том же virtuemart ну очень часто приходится менять цвета и расположения блоков, вообще внешний вид. На уровне css. И редактировать эти файлы приходится в качестве хаков...
Ответить | Ответить с цитатой | Цитировать
0 # RE: А что с CSS?Wedal 10.03.2018 01:05
Александр, механизма переопределения CSS нет, потому что он не нужен. CSS сам по себе настолько гибкий, что позволяет переопределять практически любые правила в отдельном файле. Вы не должны вносить изменения в файлы CSS Virtumart. Это хак. Вы должны дублировать CSS-правила в CSS-файле вашего шаблона Joomla, причем делать это таким образом, чтобы ваши правила имели приоритет над правилами из CSS-файла Virtuemart. Обычно для этого достаточно указать к основному правилу еще какой-нибудь уточняющий класс родителя. Ну и на самый крайний случай можно добавлять к стилям конструкцию !important, хотя это плохой вариант, который должен использоваться в самом крайнем случае.
Ответить | Ответить с цитатой | Цитировать
0 # RE: А что с CSS?Александр 10.03.2018 18:45
Это понятно. Но опять же возникает "хак шаблона". Если предположить, что шаблон тоже обновляется производителем, то все правки CSS тут же слетают. Все же предлагаю согласиться, что удобного механизма замещения CSS в joomla попросту нет. А шаблон без стилей - что лопата без черенка.
Ответить | Ответить с цитатой | Цитировать
0 # RE: А что с CSS?Wedal 13.03.2018 04:22
Александр, вы затронули большую и больную тему. Дело в том, что термина "хак шаблона" не существует. Точнее не должно существовать. Joomla задумывалась разработчиками так, чтобы шаблон был чем-то уникальным для сайта. Он не должен обновляться, а должен один раз устанавливаться и далее дорабатываться собственными силами под конкретный сайт. Именно поэтому все переопределения выносятся в шаблон.
Но сейчас развитие шаблонов пошло совсем по другому руслу. Конкуренция сделала свое дело. Теперь, чтобы продать шаблон, недостаточно просто сделать его. Это должен быть полноценный сайт, включающий в себя расширения и демо-данные. Разработчики шаблонов вынуждены идти этим путем, чтобы выдерживать конкуренцию и продавать свои решения.
Таким образом, шаблон, из инструмента кастомизации отдельного сайта превратился в еще одно комплексное решение, обладающее достоинствами и недостатками других таких расширений, например, компонентов. Теперь шаблоны настолько сложные, что для них выпускают обновления.
Но вот стоит подумать: что если вас не устраивает какой-то функционал шаблона из коробки? Вам нужно внести в него свое, уникальное изменение. Это же действительно получается "хак шаблона". Но куда тогда вообще вносить изменения, если всё может обновляться?
Некоторые разработчики таких шаблонов добавляют специальный файл, вроде custom.css. Этот файл пустой. Он предназначен для дополнительных стилей, вносимых пользователем и он не обновляется. Хорошо, это CSS. А что делать с html и php шаблона, если требуется внести в них изменения?

В общем, для себя я выработал следующую стратегию. Вы можете соглашаться или не соглашаться с ней, использовать ее или не использовать. Это ваше право. Для меня она работает и создает минимум дополнительных проблем.
1) Никаких фреймворков шаблонов. Фреймворк шаблона - зло. Здесь я не буду расписывать почему. Да, он позволяет быстро и без знаний сделать довольно красивый сайт, но вот сложность шаблона из-за этого повышается многократно. Там вам потребуются и обновления шаблона и обновления фреймворка.
2) Никаких обновлений шаблона. Правило простое - установил шаблон, дальше работай с ним сам. Стандартный шаблон Joomla прост, как две копейки. Там ну нечего обновлять. Условно: 1 php-файл, 1 css-файл, 1 js-файл. Остальное - усложнения, иногда сделанные для удобства. Такому шаблону не требуется вообще никаких обновлений. Раз вы знаете, что такое CSS, то должны уметь управляться с таким шаблоном самостоятельно. При этом вы можете придать ему поразительную гибкость, которую никогда не обеспечит ни один из фреймворков. Можете идеально "заточить" его под сайт. Я уже молчу про нагрузку на сервер при большой посещаемости. В случае простого шаблона она будет значительно ниже, т.к. для каждой генерируемой страницы Joomla не придется прогонять запрос через дополнительный фреймворк и проверять на тучу опций.
Ответить | Ответить с цитатой | Цитировать

Добавить комментарий

Для отправки комментария введите код с картинки:
Защитный код
Обновить

Вверх