Что нужно знать о Битриксе некоторым потенциальным покупателям. Битрикс ненавижу
Почему я не люблю Битрикс
Ох Битрикс … как много в этом слове. Стоит его только употребить в сообществе веб-разработчиков, так тебя сразу сольют. Надо сказать, что не безосновательно … За все время своего существования эта 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 для разработки и поддержки, развития. Я очень надеюсь, что ситуация со временем будет в корне меняться, т.к. Битрикс крайне сильно раскручен и востребован в бизнесе. Жаль что он так слабо ориентирован на разработчиков …
zhurov.me
Что нужно знать о Битриксе некоторым потенциальным покупателям / Хабр
Эта статья написана не для холивара. Здесь не будет полного обзора плюсов и минусов. Это просто несколько фактов из моего опыта, которые я сам хотел бы знать, перед тем как выбрать 1С Битрикс в качестве CMS.Предыстория, которую можно не читать
Давным-давно, когда словосочетание «web 2.0» было модным, а тени с округлостями были верхом дизайнерской мысли, нашей организации понадобилось упорядочить общение с клиентами и завести себе HelpDesk. И как это обычно бывает, работы по выбору, установке, настройке и внедрению были поручены автору затеи, то есть мне – рядовому сотруднику техподдержки.Навыки программирования у меня на тот момент были исчезающее малы – немного ковыряния в вордпрессе и пара бесполезных «Hello World!» написанных в Notepad++. И вот с этим багажом знаний я свободное от звонков время стал читать мануалы к имеющимся на рынке на тот момент системам HelpDesk и ServiceDesk.
Битрикс казался наиболее понятной, достаточно полно документированной и простой в установке системой, в которой помимо самого HelpDesk были еще другие полезные плюшки, вроде CMS =) Остальные системы были на тот момент либо на басурманских языках, либо непонятно каких денег стоили (цен на сайтах не было), либо требовали сурового бородатого напильника для доведения до ума.
Так вот к чему это я. Мы выбрали редакцию 1С Битрикс – Управление сайтом (БУС на местном сленге) не для интернет магазина. И модуль интернет магазина никогда не использовали (почти). Этот факт сильно сказался на «пользовательском опыте», каким образом – опишу ниже.
Факт 1. Битрикс: Управление сайтом ≈ Интернет магазин
Даже если ничего не знать о внутренностях битрикса и не разу не заглядывать в админку, то просто просмотрев содержание всех презентаций и конференций их маркетологов за последние 5 лет легко понять, что кроме модуля интернет магазина ничего особенно и не развивается.Все новые громкие плюшки вроде фасетных индексов, конверсий и всяких сомнительных мобильных приложений это всё для интернет магазина. Каждый раз когда я смотрю вебинар от битрикса, я чувствую что меня обманули, т.к. кроме разнообразного жонглирования заказами и размусоливания статистики по ним ничего нового в CMS за несколько лет не произошло.
Где-то внутри появилось «ядро D7», но документация об этом не знает (а в коде там не всё очевидно, иногда до нужного места можно добраться только перелопатив 5-7 файлов).
Из чего-то действительно полезного можно вспомнить парноидальный кэш, названый «Композитный сайт». Но все кто видел как битрикс строит запросы, и без композитного кэша понимали что лишний раз базу лучше не беспокоить.
Те модули, которые не нужны интернет магазину, существуют для галочки в списке фич на промо страницах битрикса. Они более менее работают, но не развиваются. Модуль техподдержки каким был в середине нулевых, таким и остался к 2015 году. Форум, wiki, блоги, обучение – это всё мало изменилось со дня своего появления.
Вывод: если вам не нужен интернет магазин и вы планируете использовать другие модули, то не рассчитывайте на их развитие.
Факт 2. Долгое исправление ошибок
Сначала я хотел поставить этот факт в конец списка, но он логически вытекает из первого. Из-за того, что в приоритете у битрикса интернет магазин, то исправление некритичных багов в других модулях происходит крайне долго. Полгода — год, это вполне нормальные сроки. Иногда дольше.Сейчас, например, в админке модуля техподдержки нельзя осуществить поиск обращений по email’у среди обращений поступивших по почте. Некритично, но неприятно. Висит этот баг уже с прошлого года =)
Вывод: если нашли ошибку в модуле – не рассчитывайте на быстрое её устранение (но сообщить о ней стоит)
Факт 3. Медленные инфоблоки
Большая часть данных в битриксе хранится в инфоблоках. Если вдруг кто не в курсе что это за зверь такой, вот выдержка из документации:Информационные блоки — модуль, позволяющий каталогизировать и управлять различными типами (блоками) однородной информации. С помощью информационных блоков может быть реализована публикация различных типов динамической информации: каталоги товаров, блоки новостей, справочники и т.д.Информационные блоки — ключевой момент Bitrix Framework. Практически всё, что делается в системе в той или иной мере завязано на этот модуль, даже если это и не отображается явно.
dev.1c-bitrix.ru/learning/course/?COURSE_ID=43&CHAPTER_ID=04610&LESSON_PATH=3913.4610
Инфоблоки избыточны и обладают всем что может понадобится разработчику сайтов в повседневной жизни. Тут есть инабор типичных полей: название, описание, теги, seo, картинки для превью и т.д.). Также можно создать свои свойства различных типов (типы тоже можно создавать).Также стоит упомянуть довольно удобную админку с разграничением прав, массовым редактированием, выгрузками туда/сюда и давно уже устоявшийся API для всего этого. В общем, инфоблоки это удобно.
Но тут есть подвох:
Инфоблоки — сущность, которая в физической структуре БД создает 4 таблицы, не меняющиеся при изменении структуры данных: типы объектов, экземпляры объектов, свойства объектов и значения свойств объектов. Если перевести с языка документации на пользовательский это грозит вот чем: каждое свойство инфоблока будет храниться в отдельной таблице и чтобы его получить понадобится отдельный запрос к базе данных.Этот подход не доставляет проблем при небольшом количестве записей (зависит от настроек и производительности сервера базы данных) Но когда записей становится несколько миллионов, появляются запросы исполняющиеся за неприличное время. И чем дальше, тем более неприличным это время становится.
Проблему можно решить хорошим производительным сервером БД с правильным конфигом и индексами. Но серебряной пули тут нет, техподдержка не поможет и на форумах информации не так много. Всё придётся делать самостоятельно: анализировать, профилировать и принимать решения.
Есть еще конечно высоконагруженные инфоблоки, но они пока не документированы. Живых примеров по ним мало. И переносить на них несколько десятков инфоблоков с кучей свойств задача не из простых.
Вывод: если у вас нет штатных специалистов по БД, а данных может появиться много, то лучше подумать над выбором других CMS с более оптимальной структурой хранения данных, ну или заложить в проект услуги по настройке БД.
Факт последний. НЕНАВИСТЬ!
Битрикс обладает очень своеобразной репутацией. Очень многие разработчики относятся к нему скептически. Многие разработчики обладают на него аллергией, а некоторые так и вообще ненавидят.Очень многие студии гордо заявляют что они не работают с битриксом. В курилке этих студий ходят легенды про то «как я поддерживал один проект на битриксе».
Вероятно, благодаря этой репутации работники веб студий изначально скептически относятся к заказам связанным с битриксом и выполняют их не лучшим образом. Тут может сказаться некоторая сложность для новичка, т.к. не все вещи в битриксе устроены очевидным образом и многие задачи можно выполнить сотней неправильных или неоптимальных решений.
Вывод: выбирая битрикс в качестве CMS нужно учитывать его репутацию в IT сообществе и тщательно выбирать исполнителей. Ну и морально подготовиться к тому, что в некоторых местах вас будут отговаривать от его покупки, а после покупки могут уговаривать отказаться от него.
Общий вывод
Если вы не планируете пользоваться модулем интернет магазина, но планируете создать популярный динамичный сайт, то битрикс с этим справится. При этом нужно учитывать, что количество накладных расходов может быть больше чем при выборе другой системы. Лучше внимательно взвесить все за и против.habr.com
битрикс! ненавижу ебаный битрикс, Мем Томми Большой Куш
Мем Томми Большой Куш
битрикс! ненавижу ебаный битрикс Мем Томми Большой Куш
Создать мем
Прокомментируй, будь мужиком, блеать!
Имя (необязательно) Запостить
Похожие картинки:
risovach.ru
За что я все-таки люблю Битрикс
В своей предыдущей записи я сильно критиковал Битрикс по многим параметрам. В нем очень много спорных моментов, которые требуют скорейшего решения. Однако есть в битриксе и моменты, за которые иногда рад работать на этой платформе.
Инфоблоки
Я сейчас не хочу вдаваться в подробности технической реализации этого модуля, а больше хочу обратить внимание на саму идею. Мне лично очень нравится идея Базы данных в Базе данных. Это штука, которая позволяет неопытному пользователю сайта создать контейнер для хранения практически любых сущностей. Причем сущности эти могут иметь взаимосвязи между собой, а также иметь набор из полей различных типов. Причем эти типы не ограничиваются стандартными «Строка», «Число», и т.д., а их можно дополнять собственными типами данных. В дополнение к этому пользователь сайта может легко создать страницу, на которой будет выводиться список этих сущностей, а также саму детальную страницу просмотра этой сущности, произведя минимальные настройки. Ну не круто ли, а?
ecommerce
Не зря битрикс так популярен именно в сфере ecommerce. Он обладает достаточно мощной функциональностью для создания интернет-магазина. Удобная продуманная админка, штатная интеграция с многими платежными и логистическими системами, гибкая настройка скидок и купонов, аналитика по заказам и покупателям, маркетинговая составляющая и т.д. Я опять же пока не обращаюсь к технической стороне вопроса (кстати, 15го декабря обещали релиз 16.0, который на момент написания этих строк все еще не вышел. Там все обещали сделать круто).
Для России и стран СНГ эта отрасль имеет еще одно немаловажное преимущество — штатная интеграция с большим количеством конфигураций 1С. И в последнее время в этом плане тоже все очень неплохо развивается (при условии, что каталог будет «стандартным» с точки зрения самого битрикса).
Есть, конечно там, и свои черти (экспорты данных — я про вас), но это все можно решить малой кровью или покупкой сторонних модулей.
Обработчики событий
Люблю обработчики. Они позволяют вклиниться в дефолтное поведение ядра и изменить его под свои нужды нативным способом. Это одна из самых важных фич в битриксе с точки зрения разработки, на мой взгляд. Появилась она очень давно, возможно даже с рождением битрикса, и по сей день активно развивается. Их (обработчиков), конечно, иногда не хватает в самых нужных местах, но они покрывают достаточно большое количество нужд.
Гибкость
Этот момент, конечно, спорен. Так можно сказать о любой платформе, в принципе. Но вот я пока не встречал ни одного типа проектов, который нельзя было бы реализовать на битриксе. Хочешь визитку — на тебе. Хочешь сложнейший интернет-портал с over 100 уникальных типов страниц — на тебе. Хочешь интернет-магазин со всякими современными прибамбасами — запросто! И все это более-менее можно подружить с несколькими языками (при соблюдении определенных условий). Все это можно будет допилить под себя без модификации исходного кода системы (ядра).Не хочу сказать, что продукт гибок на все 100%, иногда все же приходится уступать в чем-то. Однако это не безнадежно.
Быстрый старт для типичных проектов
Если вы ищете платформу для быстрого старта нового интернет-проекта без уникального дизайна с типичным функционалом, то Битрикс — это отличный выбор для Вас. За день можно запустить полноценный продающий интернет-магазин, связанный с 1С.Конечно, со временем все коробочные решения придется выкинуть, т.к. они совершенно не предназначены для дальнейшей поддержки и длительного развития, но для самого начала — пойдет!
Заключение.
Вот в общем-то и все.. Честно говоря, когда начинал писать статью, думал, что будет поболее пунктов в этой части. Вообще говоря — это общеизвестный факт, что реакция на недостатки гораздо ярче, чем на хорошие стороны. Возможно мой мозг уже не способен замечать преимущества системы перед другими платформами, т.к. сталкивается с ними ежедневно и научился не замечать их, не обращать на них внимания. Но это не значит, что этих плюсов нет.
Поэтому давайте вместе активно хейтить битрикс =) Может это сподвигнет их стать более ориентированными на разработчиков, чем сейчас.
zhurov.me
За что я не люблю Битрикс >:|
Да, я не самый самый знаток битрикса, но именно в этом и плюс. Значит, я смотрю на эту систему без предвзятого мнения. Нет, честно, первое время (на основе большого количества лестных отзывов в далеком 2010 году) я искренне верил, что система классная, и, даже пытался полюбить ее. Но не заладилось сразу. Уже с первой встречи, у меня то и дело вырывались фразы типа: «что за бред?» и «как, черт подери так?». Спрограммировав несколько сайтов и написав с десяток компонентов для этой cms, я окончательно в ней разочаровался.
Итак по порядку, очевидные минусы:1) неудобный интерфейс админки (должен признать,он значительно улучшен в последней версии, но многого это не поменяло). Не всегда понятно, где и что искать. Количество пунктов, подуровней и разделов превышает все разумные пределы. Сразу видно, что разработчики не особо задумывались о классификации и группировке функционала.2) неудобная реализация многосайтовости (для такого перекошенного монстра, это вообще лишнее). И главное не понятно, зачем мне при в ходе в админку конкретного сайта, в разделе контента отображаются данные со всех сайтов (я вроде с одним конкретным сайтом сейчас работать собирался)?3) Также глупая была задумка, по реализации страниц как структуры из папок и файлов. Пользоваться ей неудобно. Ну вот, попросите зайти начинающего веб мастера в корень сайта по ftp и понять какие папки имеют системное значение, а какие просто содержать контентные страницы? В нормальных cms, количество файлов и папок в корне сведено к минимуму. В идеале 3-5 директорий и 5-10 скриптов. Здесь же винегрет, из минимум 12-15 директорий и десятков файлов. Это опять же, показатель непродуманности структуры. А количество уровней? Вам доводилось перемещаться между директориями шаблонов компонентов? Как вам такой путь: /bitrix/components/gelend/mest_photogallery_user/templates/ .default/bitrix/photogallery.section.list/.big/script.js ? Девять уровней! И это еще не самый длинный путь! Я видел и 13-14 уровней вложенности. Проще застрелиться, чем лазить по этим директориям.4) В какой-то степени, мне была понятна затея с компонентами, что-то аналогичное делал и сам. Вызываешь себе функцию компонента и передаешь ему параметры. Но чОрт подери! Почему там десятки плохо документированных параметров, которые зачастую между собой конфликтуют, непонятным образом перекрывают или вообще работают не так как написано в документации.5) Оформление кода. Оно повергает меня в шок, как человека, привыкшего делать нормальное форматирование кода. Каждый раз заходя в код компонента, судорожно пытаешься найти глазами, где заканчивается вот этот блок и до какого места действует вон то условие. Без водки IDE вообще не разобраться. Особенно смешат комменты на английском. О да, без них я бы ничего не понял: «/Get data from cache», или «Input params», или «Processing of received parameters». Не понятно, для кого они? Для иностранцев? У них и с drupal жизнь неплохо сложилась, поэтому пользоваться битриксом они просто никогда не будут. Для отечественных битрикс-программистов? Да многие из них, не знают ни слова по английски, они вообще только начинаю программировать. Те, кто уже научился, битриксом не пользуются (ну, если только по насильственному принуждению со стороны работодателя).Конечно можно подумать, что статья злая. Но в действительности, очень обидно, что такой разрекламированный отечественный продукт, так плохо спроектирован. Да в системе видно хорошую задумку, но ее реализация сделана двоешниками, которые пропустили все занятия по проектированию. Досадно еще и потому, что вот с этого кривого кода, многие молодые люди начинают свой путь программиста. То есть если бы это был просто плохой продукт, то фиг с ним, но ведь от его существования еще и негативные последствия.
www.kutsevalov.name
Подборка ссылок про битрикс - zhurov.me
Прошло уже более года с момента последней публикации в этом блоге. Наверное, пора сменить формат постов. Если раньше я старался писать больше объемных статей, что отнимает тонну времени, то теперь буду стараться ужимать поток мыслей в более удобочитаемый, немногословный формат. Но обещаю все же писать и большие статьи по возможности.
На этот раз хочу опубликовать небольшую подборку статей про Битрикс, которые раскрывают его не с самой лучшей стороны. Надеюсь, что эта подборка поможет кому-то в будущем сделать правильный выбор.
Итак:
Минусы Битрикса, или Битрикс глазами программиста.
Крик души одного из разработчиков, который проливает свет на некоторые аспекты подхода к построению внутренней «Архитектуры» 1С-Битрикс. Статья немногословна, но в нескольких словах описывает довольно большой пласт проблем системы.
Обзор обзора минусов, или чувак читает только первые 5 страниц.
Ответ одного из любителей битрикса на предыдущую статью. Безуспешная попытка …
Исповедь битрикс хейтера.
А это уже моя статья, которую я написал в ответ на предыдущие две 🙂 Статья рассчитана на начинающих разработчиков, которые не могут определиться с выбором между суровым миром Enterprise разработки и экосистемой 1С. Также она может быть полезна продуктовым менеджерам и технарям, которые выбирают фреймворк или платформу для создания нового проекта.Статья раскрывает технические тонкости реализации тех или иных функций в битриксе, описывает проблемы архитектуры, с которыми обязательно придется столкнуться разработчику.
Мода на фреймворки. Эталон ужаса.
Вырезка из шуточной статьи, слепленной в стиле Lurkmore. Данная вырезка поднимает на смех реализацию некоторых аспектов архитектуры Битрикс. Не было бы так смешно, если бы не было так грустно. В каждой шутке есть доля правды, а в этой статье, к сожалению, правда — всё, за исключением, разве что, стоимости на максимальную редакцию, которая за последние годы выросла раз в 6.
Что нужно знать о Битриксе некоторым потенциальным покупателям
Описание некоторых аспектов для тех людей, которые хотят купить себе коробку с битриксом.
Битрикс24 CRM. Обзор.
Обзор возможностей CRM из Битрикс24. Описывает в статье возможности CRM и сравнивает с другими аналогичными платформами, намекая на то, что система не стоит тех денег, которые за нее просят и в очередной раз подчеркивает, что заявления вендора очень сильно расходятся с полученным после покупки результатом. В данном случае, покупая Б24 ради CRM вы получаете недоделку с кучей дополнительного, не связанного с CRM другого функционала.
Как Битрикс чуть Новый год не погубил.
История о том, с чем пришлось столкнуться обычному разработчику при разработке под Битрикс. Обычные рядовые будни обычного разработчика, который описывает свою боль на эту тему.
Описание одной интеграции 1С и Битрикс, и почему я не рекомендую своим клиентам использовать такую интеграцию
Собственно, все что нужно знать, находится в заголовке этой статьи 🙂 Разрушение мифов о том, что интеграция 1С и 1С-Битрикс делается в пару кликов и личное мнение автора на эту тему.
Методология разработки на 1С-Битрикс – опыт дурака
Статья описывает проблемы как отрасли в целом (в данном случае под отраслью я имею в виду отдельное направление — разработка под 1С-Битрикс), так и проблемы битрикса, которые мешают разработчикам делать их работу.
1С-Битрикс — CMS от маркетологов. Плюсы и минусы
Несколько слов о том, почему возникает недопонимание между разработкой и менеджментом в битриксе. Снова отраслевые проблемы по большей части, которые породил битрикс.
Интеграция сайта с 1С — риски и немного реальности
Статья для менеджеров об 1С, и об интеграции ее с сайтом. На примере Битрикс (хоть это явно и не сказано). Как нужно вести себя с заказчиком. Также данная статья отлично показывает, что интеграция 1С и Битрикс — это довольно муторный и сложный процесс, который потребует не только огромного количества времени на менеджмент, но и титанических усилий разработчиков как со стороны Битрикс, так и со стороны 1С.
Ох уж эти «золотые партнёры»
Интересный тред, который раскрывает одну из системных проблем экосистемы битрикса — самих разработчиков, которые обучаются по материалам битрикса.
Забавный вопрос на Stackoverflow
Такое может спросить только истинный битриксоид …
Буллшит Бинго. Битрикс
Прикольная игра (не только про битрикс). Генерируем карточки, печатаем, и читаем правила, как пользоваться.
Три с половиной способа доработки Битрикс24. Теория
Статья Интерволги, которую битрикс опубликовал у себя в центре помощи! Эта статья показывает, насколько ужасна схема расширения Б24 и какого геморроя стоит поддержка Б24. Тотальный фейл
Отрыжка сознания. Битрикс — беспомощное говно
Говорящее название поста 🙂 Битриксоиды умеют фантазировать 🙂
Грехи и добродетели — в веб-разработке
Статья Александра Сербула на хабре про то, что архитектура не стоит ничего, и лучше решить задачу в 150 строк говнокода, чем строить сложные абстракции. И это официальная позиция Битрикса. Очень печально ..
Вот и все на сегодня. Не забывайте смотреть комменты к этим статьям, там порой может быть даже больше интересной информации для размышления, чем в самой статье.
На самом деле, в интернете довольно много статей о том, что битрикс является довольно нелепой CMS и фреймворком. И это должно заставлять задуматься потенциального покупателя этой платформы, а также самих разработчиков: если так много негатива вокруг этой CMS, то может быть она не стоит того, чего за нее просят? Почему про другие CMS и фреймворки не слышно такого флейма, а про Битрикс это в порядке вещей? Определенно, есть повод задуматься …
Ну а если станет скучно, можно просто загуглить:Битрикс говно или Symfony sucksРазница, как говорится, налицо
zhurov.me
Организация кода в Битрикс. Часть 3. Переделываем все к черту и делаем еще лучше!
Я уже раньше писал о том, как я организовываю свой код. Однако с течением времени приходит понимание того, как все же сделать эту схему удобнее. И поэтому данная серия статей никогда не будет иметь финального ответа на вопрос, как же все-таки удобнее всего. Но мы постоянно приближаемся к этому недостижимому идеалу. На этот раз я решил все кардинально изменить.
Раньше я затрагивал только вопрос того, как хранить файлы внутри битрикса, однако начинать надо было не с этого. Начинать надо с того, как хранить файлы проекта, а не битрикса. Каждый сайт, сделанный на битриксе, имеет смысл рассматривать как целостный проект, индивидуальный и самодостаточный. И подход в разработке должен быть соответствующий, включая организацию кода.
Ранее и сейчас, весь код проекта на Битрикс хранился исключительно внутри DOCUMENT_ROOT. Это, конечно, прозрачно и понятно, однако не имеет никакого смысла хранить весь код именно там. Причин тому несколько:
- Этот код будет доступен из веб (в случае с битриксом, это вполне вероятно, если за этим специально не следить)
- Есть всякие другие интересные вещи, которые не имеет смысла хранить в DOCUMENT_ROOT, например логи, конфиги, сторонние библиотеки
Рассмотрим на примере. Назовем наш абстрактный сайт site.ru. Ранее он хранился бы где-нибудь в /var/www/site.ru и это был бы его DOCUMENT_ROOT. Но в реальности правильнее было бы создать еще один уровень вложенности и переместить корень туда. В нашем примере это может быть, например, /var/www/site.ru/htdocs.Что в реальности это дает?
Во-первых, логи
Вы можете создать директорию с логами. /var/www/site.ru/log. В этой директории можно хранить логи веб-сервера, а также логи самого проекта. Благодаря этому, вы можете быстро с помощью консоли получить доступ к нужным логам. В директории с логами можно организовать любую удобную структуру. Например, для логов веб-сервера использовать такие имена директорий, как apache2 и nginx (как в /var/log). Для каждого своего сервиса создать отдельную директорию с логами. Кстати, если кто-то еще пишет свои собственные классы с логами, то примите к сведению, что есть такая мега-удобная и гибкая штука, как monolog, а также его адаптация под битрикс от BEX. Этот логгер полностью соответствует стандарту логирования PSR-3.Удобно.
Во-вторых, зависимости.
Пропадает необходимость хранить библиотеки composer в /local директории битрикса. Само по себе хранение зависимостей внутри /local как-то противоречит самой идее данной директории, т.к. в ней должен находиться только версионируемый код разработчиков. Да и обычно все зависимости размещаются непосредственно начиная от корня проекта, но в случае с битриксом это может превращаться в неудобство.Если же мы переносим зависимости из /local в корень проекта (а не DOCUMENT_ROOT), то мы сразу убиваем двух зайцев, удовлетворяя обычным практикам использования composer, а также более правильно следуем самой идее директории /local.Таким образом, получается, что composer.json, composer.lock и директория /vendor будут располагаться в /var/www/site.ru. И эти файлики не будут беспокоить заказчика, если он дотошный. А чтобы поставить зависимости, достаточно зайти в корень проекта и запустить команду установки, все логично и очевидно:
cd /var/www/site.ru && composer install
cd /var/www/site.ru && composer install |
Удобно!
В-третьих, статика.
Прошлый пост этой серии я закончил на том, что у меня осталась нерешенной проблема со статикой. На момент написания этих строк, проблема со статикой почти решена. Пока что я пришел к выводу, что нет пока более удобного инструмента для сборки статики, чем webpack. Мы постепенно внедряем его в наши проекты, однако его конфигурация, а также все зависимости npm хранятся также внутри DOCUMENT_ROOT, что не является целесообразным.
В данном же случае, вся конфигурация, все исходники статики, а также зависимости, необходимые для организации процесса сборки переносятся за пределы DOCUMENT_ROOT. А сам процесс сборки можно настроить таким образом, чтобы файлы сборки попадали в итоге в DOCUMENT_ROOT в какую-нибудь директорию /assets.
В-четвертых, версионный контроль.
Я надеюсь, что ни для кого из вас не секрет, что хранить системные файлы репозитория внутри DOCUMENT_ROOT не очень хорошо. Обычно, достаточно вынести репозиторий на уровень выше, и слинковать его с рабочей копией с помощью опции worktree. Однако это лишает репозиторий возможности использовать некоторые фишки, например stash, или submodules (будь они прокляты! не используйте их 🙂 ), и еще некоторых возможностей. Хорошо, если на продакшене это не нужно, но мне бы хотелось иметь полный контроль над репозиторием. В связи с этим, я в последнее время переношу репозиторий в корень рабочей копии, и закрываю директорию /.git с помощью .htaccess, например.
Если же мы используем предложенную схему, то рабочей копией репозитория можно сделать директорию /var/www/site.ru, и не придется ничего мудрить.Крутяк!
В-пятых, да придумать то можно что угодно!
Хотите хранить бекапы — можно вынести их на новый уровень вложенности. Хотите какие-то консольные скрипты — выносите их туда же. Юнит тесты — да легко! Любые конфигурационные файлы — всегда пожалуйста: composer.json, package.json, bower.json, webpack.config.js, phpunit.xml.dist, travis.yml — к вашим услугам, не надо это хранить в DOCUMENT_ROOT. Можно и кеши какие-то свои вынести на этот уровень. Да все, что душе угодно.
Таким образом, получается нечто такое (серым помечены исключенные из версионного контроля вещи, а структура начинается с /var/www/site.ru):
Немного по модификациям того, о чем я писал ранее.
Автозагрузка классов
Ранее я писал, что для автозагрузки использую свой класс. Однако это совсем не обязательно. Поскольку composer сейчас является стандартом де-факто для любого проекта, то он содержит в себе очень гибкий автозагрузчик, который в пару строк организует подключение нашей папочки classes. Достаточно написать в composer.json секцию автозагрузки:
"autoload": { "psr-4": { "Maximaster\\": "htdocs/local/classes/" } }
"autoload": { "psr-4": { "Maximaster\\": "htdocs/local/classes/" } } |
Ну и остается следовать стандарту PSR-4, тогда автозагрузчик будет прекрасно работать в тандеме со всеми вашими зависимостями.
Ajax
К черту /local/ajax. Самым правильным решением будет организация единого API. Например, для внутреннего API использовать путь /api/internal. Создавать директорию под это дело совсем не обязательно, лучше обойтись без лишних папочек, несмотря на всю файловую природу битрикса.
Cron
К черту /local/cron :). Не надо плодить отдельные скрипты для каждой задачи. Используйте symfony/console или console jedi (который основан на symfony/console) для создания консольных команд. А на крон уже цепляйте созданные задачи, а не выполнение конкретных скриптов.
UPD. Нашелся, все же, небольшой косячок у всей этой структуры. В PHPStorm $_SERVER[‘DOCUMENT_ROOT’] резолвится в корень проекта. А тут корень проекта не будет соответствовать корню виртуального хоста на сервере. Из-за этого многие инклюды в битриксе не будут резолвиться корректно при просмотре их в IDE. Но это, на мой взгляд, очень несущественная и маленькая проблема, которая полностью покрывается всеми теми плюсами, которые дает предложенная структура.
zhurov.me
