Hope, если у человека Битрикс головного мозга и не раз факты и кучу уязвимостей показано. А ему, что в голове пусто и осознанием, что Битрикс говно.
Даже если ничего не знать о внутренностях битрикса и не разу не заглядывать в админку, то просто просмотрев содержание всех презентаций и конференций их маркетологов за последние 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 сообществе и тщательно выбирать исполнителей. Ну и морально подготовиться к тому, что в некоторых местах вас будут отговаривать от его покупки, а после покупки могут уговаривать отказаться от него.
