Ох Битрикс … как много в этом слове. Стоит его только употребить в сообществе веб-разработчиков, так тебя сразу сольют. Надо сказать, что не безосновательно … За все время своего существования эта CMS завоевала рейтинг самой говнокодерской из всех ныне живущих. Достаточно заявить, что ты создаешь сайты на Битрикс — тебе сразу же присвоят сан почетного говнокодера.
Увы и ах, но в большинстве случаев оно так и выходит. Я повидал немало проектов, разработанных кем-то на битриксе, и навидался разного. И у меня сложилось определенное мнение, которым я и хочу поделиться.
Копипаста
У каждой CMS есть свои принципы расширения функционала. Многие предоставляют систему хуков (в битриксе она тоже есть). Какие-то предоставляют возможность наследоваться от базового функционала. В битриксе же основной механизм расширения базового функционала — это копипаста 🙂
Возьмем для примера интернет-магазин. Битрикс позиционирует себя как система, которую купил, развернул, запустил продавать. Купив коробку, ты получаешь полный набор готовых инструментов для запуска бизнеса в интернете. Но как всегда — этого функционала часто начинает не хватать. Или наоборот — его обилие слишком давит.
В этот момент нужно что-то немного докрутить, доработать. Хорошо, если разработчики битрикса предусмотрели этот момент, и добавили возможность отключения или какой-то степени модификации той или иной фичи. Но всего то не предусмотришь … Приходится привлекать разработчиков. И хорошо будет, если задача решится с помощью определения какого-нибудь хука, но это не всегда возможно ..
И вот тут-то начинается вся свистопляска. Допустим возникла задача переместить кнопку «Купить» в карточке товара в другое место. Сие действие можно решить средствами css (переписав дефолтные стили поверх) или html (переместить блок из одного места в другое, если css позволит). Переписывать стили поверх существующих, как мне кажется, не очень хороший вариант, поэтому мы решаем изменить тот стиль, который уже есть у нас. Находится этот стиль в т.н. «ядре». Ядро системы должно оставаться нетронутым по идее, т.к. при обновлении все выполненные изменения могут быть легко затерты. Так вот чтобы изменить css файлик, его надо скопировать в другое место вне ядра. Причем скопировать придется не только этот файл стилей, а весь шаблон того компонента, который содержит этот стиль. В худшем случае такое копирование может привести к созданию дубля не одной сотни файлов стилей, картинок, php-шных шаблонов и т.д. И все это ради одной единственной строчки в css! Хорошо подумав ты принимаешь решение все-таки не копировать шаблон из ядра, а переписать стиль поверх существующего. А что, если задача с помощью изменения стилей не решается? Тогда, хочешь не хочешь, придется создавать копию.
Масла в огонь подливает тот факт, что создавать такие копии сама CMS-ка то и помогает и мотивирует это делать. Ничего не мешает неведающему владельцу интернет-магазина взять и создать такую копию шаблона. При желании, можно внести изменения в исходный код таких шаблонов прямо через веб-морду, что еще больше усугубляет дело.
Но и это все не самое страшное. Самое страшное начинается, когда нужно модифицировать логику работы какого-то компонента. Тут есть несколько путей.
Самый любимый — это модификация логики работы компонента через … шаблон! Создаем клон шаблона (шаблон — это папочка со структурированным набором файлов), заводим там специальный файлик result_modifier.php и херачим туда свою логику … Логика в шаблоне, да …
Если не получается и нужно серьезно повлиять на работу встроенного в ядро компонента, то придется копировать этот компонент целиком, выносить из ядра, и вносить правку в копию. Тут есть одно но .. в 12й версии в компонентах появилась «поддержка ООП» (меня всегда так умиляет это определение). Это значит, что каждый компонент может являться классом, со всеми вытекающими. Неграмотные разработчики настолько привыкли копировать компоненты, что копируют и эти классы, совершенно забивая на возможность наследования. Хотя иногда и наследование не позволит решить стоящие перед разработчиком задачи в виду того, что код в этих компонентах формально и организован в виде класса, но по факту этот класс является тупым набором из нескольких методов, которые обязывают при наследовании скопипастить содержимое этих методов и внести изменение в одну строчку посреди этого метода.
Файлы .. много файлов … еще больше файлов!
Битрикс очень любит файлы. Где-то читал, что они позиционируют себя как «файловая» CMS. Для создания статичной страницы нужно создать файл (ну лан, это еще ничего). Для создания своего компонента нужно создать папочку с кучкой файлов, имеющих определенную организационную структуру. Для создания модуля нужно создать папочку с еще бОльшим количеством файлов и вложенных папочек.
А еще внутри каждой директории проекта может быть файл такой, файл сякой … бэээ (
Со временем, благодаря копипасте, общее количество файлов проекта растет с астрономической скоростью. Типичный проект на битриксе состоит из более чем 30к файлов! И достаточно большая часть из них никогда не будет использоваться. Черт, да не на каждой машине git сможет быстро переварить такой объем, чтобы комфортно с ним работать …
А еще, битрикс дает возможность наполняльщику иметь доступ к содержимому файлов. Мало того, что в этих файлах хранятся конфиги компонентов, настройки каждой страницы, разделов. Эти конфиги можно поменять с помощью т.н. визуального редактора, который страсть как не любит неожиданных для себя ситуаций. Если он увидит в редактируемом файле неожиданный для себя php код, то при попытке отредактировать его есть риск, что ваш код будет обернут в htmlspecialchars() и сохранен как есть, что естественно сломает страницу. А может и целый раздел.
Как-то не до конца ..
Когда смотришь презенташки битрикса, конференции, то на них рассказывают крутые вещи. Да красиво так рассказывают, что хочется верить в светлое будущее платформы.
Однако после презентации начинаешь копаться в тех фишках, которые тебе презентовали в красивом фантике, начинаешь понимать, что под фантиком скрывается какая-то недоделка.
Вот например — распиаренное ядро d7. Как же любят им хвалиться, оно такое крутое, мы его развиваем … ага. В Битриксе есть модуль — инфоблоки. Это самый часто используемый модуль после «Главного» модуля. Он до сих пор работает без этого самого d7. Нет, ну отдельные сущности, конечно, можно дергать с помощью ORM, но вот никаких толковых взаимосвязей между сущностями модуля нет. Удалив раздел инфоблока 2го уровня вложенности, его подразделы останутся существовать без привязки к родителю. Элементы и разделы инфоблока не имеют связи со своими же свойствами … ну в общем — полный отстой. Хотя этот d7 презентовали еще 3 года назад. В общем получается, что он как бы есть, но пользоваться им в полной мере еще нельзя. Я понимаю, что процесс перехода на новое ядро еще не завершен, но уж один из важнейших модулей системы то надо было давно уже перевести.
Или еще пример — композит. Ну хорошо, придумали очередной велосипед (который, например к wordpress прикрутили уже давно), запатентовали (каким-то макаром), завернули в красивый фантик, начали рекламировать. Я не спорю, он действительно работает, неповоротливая черепаха (битрикс) со включенным и нормально работающим композитом действительно начинает работать быстро. Но не все так радужно, как хотелось бы. Из минусов, которые для меня стали критичными — нельзя никак вмешаться в ход выдачи композитной страницы. Есть возможность отдавать страницу через php и через nginx как статику. Так вот в режиме php нет даже никакого хука, который позволил бы встроить свой код до того, как CMS выдаст страницу.
Иногда случается тупняк, и композит отрубается. Чтобы выяснить — почему, битриксоиды предусмотрели логирование. Но это логирование логирует не все аспекты композита. Так прикольно наблюдать, что композит не работает, а в логах ошибок работы композита ничего нет, пусто. Вот и думай …
Пример с тем же ООП в компонентах. Он существует аж с 12й версии битрикса, но бОльшая часть всех встроенных компонентов не использует этой возможности, а значит по сути нет практически ни одного шанса, что можно расширить их функционал.
Работа со сторонними шаблонизаторами была заявлена (и она работает) уже давно. Можно подключить к битриксу twig, или на худой конец smarty. Но вот полноценной работы с ними не получится, т.к. шаблонизатор можно подключить нативно только к компонентам. А вот шаблоны сайтов так и останутся. Соответственно самая главная фишка шаблонизаторов — наследование — просто не работает. Эх …
Многоязычность в битриксе тоже реализована как-то не до конца. Чтобы иметь возможность вести каталог товаров в нескольких языках, нативно нужно создать несколько копий каталога и поддерживать актуальность каждого.. Если будет отсутствовать локализация какой-либо языковой фразы, то данные из «дефолтного» языка выводиться не будут.
Недавно еще пришлось заниматься переводом старого корпоративного портала на шаблон Битрикс 24. Так вот визард, который выполняет перевод, тоже как-то не до конца сделан. Пришлось потом за ним вручную много чего доделывать ..
Таких примеров можно найти массу. CMS и фреймворк вроде бы предоставляют какой-то функционал, но он как-то не до конца, что ли, сделан.. и документация по нему всегда не до конца .. печально 🙁
Стандарты? Не, не слышали
Опять про d7. 3 года назад нам сказали — мы придумали офигенную штуку! Это будет бомба! А что же на деле?
Автозагрузчик — свой велосипед. Есть же современный стандарт psr-4, который отвечает всем требованиям самого битрикса, однако нет, надо обязательно создать свой.
Еще один велосипед — ORM. Сделанная с нуля. Не продуманная, молодая, неопытная, бедная, но своя.
Логгера до сих пор нет нормального.
Классы для работы с http протоколом — опять свое. Причем без какой-либо возможности подменить их на сторонние решения, вроде компонентов Symfony. Вообще не припомню, чтобы в ядре использовались интерфейсы.
Нет, я конечно, могу понять… битрикс, может быть, и не хочет отвечать за чужие ошибки в бесплатных библиотеках, все-таки это коммерческая CMS. Однако jquery то он использует, и распространяет с ядром. Он использует bootstrap, FPDF … почему же тогда он не хочет использовать PSR стандарты, composer, компоненты symfony? Мне этого не понять …
Несогласованность и неопределенность
Они прослеживаются во многих модулях системы. Я, конечно, понимаю, что разные модули системы разрабатываются разными командами. Но часто бывает так, что в рамках одного модуля системы тоже существует несогласованность.
Вот пример — события добавления сущности. Для элемента инфоблока это будут OnBeforeIBlockElementAdd и OnAfterIBlockElementAdd. Тогда как для заказа — OnBeforeOrderAdd и OnOrderAdd.
Вроде бы договорились, что разрабатываем с php 5.3+ (а пора бы уже 5.5+, как минимум), однако в относительно свежем модуле highloadblock инсталлятор написан еще под 4ку.
Вроде договорились, что классы и методы будут описаны с phpDoc в ядре. Но что-то как-то неактивно этот процесс идет. Очень большое количество методов если и снабжено phpDoc комментарием, то это автоматически сгенерированный коммент от IDE только лишь со списком параметров. Иногда проскакивают и описанные методы, но описание скудновато …
Версии продукта вообще не имеют никакой связи с реальностью. Смена версии зависит исключительно от времени года, а не от количества реализованного функционала.
С Битрикс 24 как то вообще наткнулся на удивительнейшую вещь. Оказывается — его вообще нельзя модифицировать! После длительного обсуждения с техподдержкой выяснилось, что это целостная система, и в нее нельзя вносить изменения. Несмотря даже на то, что возможность внесения изменений есть (почему бы ее не закрыть в таком случае?).
На самом то деле все потому, что шаблоны просто пестрят бизнес-логикой. Скопипастив шаблон, вы получите связанный с ядром код, который надо будет поддерживать при обновлениях системы.
Конфиги — наше все
Возможность гибкого конфигурирования — это, бесспорно, очень важный момент. Однако все сводится на нет, если нет четкого центра управления этими конфигами.
Каждый компонент битрикса (разработанный битриксом), по идее, имеет физическую привязанность к конкретному модулю. Например — компонент catalog.element привязан к модулю каталога, тогда как main.register привязан к главному модулю. Только вот конфиги этих модулей и компонентов располагаются в разных местах. Компонент, как я писал уже выше, настраивается в том файле, где его разместили. Настройки модуля — могут находиться на специализированной странице настроек модуля, а могут быть вынесены на отдельную страницу в админке. Настройки роутинга для инфоблоков могут находиться как в настройках самого инфоблока, так и в настройках компонента, который показывает данные этого инфоблока.
Настройки прав доступа — это вообще отдельная песня. Есть настройка доступа к каждой физической директории в document_root, к каждому физическому файлу, к каждому модулю, к каждому инфоблоку. Порой бывает очень не просто понять, по какой причине битрикс не дает доступ к той или иной административной странице, ведь он не объясняет причин — просто говорит что доступ закрыт, а ты думай сам.
Заключение.
В общем говоря все, что обозначено выше, а также еще немного больше, делает битрикс очень неудобной CMS для разработки и поддержки, развития. Я очень надеюсь, что ситуация со временем будет в корне меняться, т.к. Битрикс крайне сильно раскручен и востребован в бизнесе. Жаль что он так слабо ориентирован на разработчиков …
