Комментарии 15
Такс, напомните пожалуйста, в Битриксе до сих пор пишут страницы на php? Шаблонизатор так и не завезли? Ну типа там Twig.
Да, страницы создаются на php. Но в Битриксе есть возможность добавлять разные шаблонизаторы. Но для того, чтобы их добавить, нужно еще потрудиться и покодить. Ну по сути для Битрикса это не сильно актуально.
Тут еще можно почитать: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=3235&ysclid=m1ktie6elk969199473
Так ли плох Битрикс на самом деле?
Да.
Очень кратко и ёмко, немного расширю ваш ответ. Битрикс кусок го...на. Архитектурно просто жесть. Нахрен ненужное нам ваше неймспейсы, у нас свои. Нахрен не нужно mvc и доктрины разработки. Просто блядь рак, который манагеры 1с втюхивают бедным людям. Которые согласны хоть на что перелезть лишь бы не на Битрикс. Интеграция с 1с как заявляют из коробки не работает. Нихера там не работает нормально. Все через сраку. Написанные официальные модули для регистрации - сифилис мозга. Вот какой дол...ёб делает херову гору инклудов в куче файлов ?! Нахера???? Вот разрабы этой ебанины!!! Отвечайте! Почему половина Битрикс а это инклуды?!!!! Уже школьники врубаются что такое актив рекорд, у Битрикса же просто всратый построитель запросов. Такое ощущение что дали конченным мудакам задание , написать кусок говна. Нахера Битрикс весит 200-500 мегабайт для того что бы открывать пару десятков страниц .
При том, что я достаточно хорошо отношусь к битриксу, проблемы всё же у него обычно отмечаются совсем другие.
Существующие на маркетплейсе модули (действительно сильное маркетинговое преимущество битрикса для разработчиков и для клиентов) частенько реализованы через жопу или с применением хаков и трюков для обхода ограничений существующего ядра Битрикс (что вызовет проблемы при смене ядра, а вы потом устанете искать ошибку);
Стиль программирования в 1С-Битрикс совершенно особенный, конечно, и далёк от лучших практик;
Для реализации некоторых пожеланий клиента стандартных компонентов в битриксе нету, хотя некоторые просьбы о такой функциональности висят на сайте годами. Скоро совершеннолетними будут. И для их реализации надо брать или п.1, или нанимать программиста, который напишет компонент, и это в любом случае будет больно.
Если нужна стандартная функциональность и можно отказаться от всего, что долго, дорого и больно реализовывать на битриксе — выбор норм. Программистов на битриксе много, предложение на рынке РФ бьёт почти любое другое, по доступности. Цена ошибки не очень велика, скорость запуска и надёжность работы — достаточны.
Как только нужно что-то уникальное (иногда на полшага в сторону от типовых потребностей, буквально) — разработка на Yii или Symfony может оказаться быстрее, надёжнее и дешевле.
Написать интернет магазна yii с нуля и интегрировать его с 1с, складом, доставкой ,оплатами, с любым дизайном займет много меньше времени чем отлаживать этот битро-рак
Это если есть компетентный менеджер со стороны заказчика, заинтересованный в результате.
А так: взяли битрикс, взяли шаблон «Аспро», вкатили изменения в дизайн настройками Аспро, воткнули одно в другое, отдали — и пусть изучают в реальности, что им на самом деле от интернет-магазина надо.
А «программист» тут нужен для маркетинга.
Мне пришлось плотно поработать с Битриксом, к тому же вечер пятницы, и мне есть что сказать! Вот мои не "типичные аргументы о недостатках платформы":
Инфоблоки без сомнения являются "сердцем" Битрикс, на них построено очень много решений, в частности каталог товаров в стандартных компонентах магазина. Чтож, попробуем создать инфоблок, заполяем замечательные поля NAME, CODE, IBLOCK_TYPE_ID и т.д.
А потом попробуем получить инфоблок - по названию (NAME) находит, по коду (CODE) находит, а по типу (IBLOCK_TYPE_ID ) - нет. Ну как так? А оказывается, для фильтра по типу нужно использовать ключ TYPE, а не IBLOCK_TYPE_ID. Почему, а главное, зачем?
О, документация, любимица всех битриксойдов! Получение списка элементов инфоблока, чуть ли не основной метод Битрикса - в первом же примере кода ошибка.
Описание части методов вообще утрачено, пример.
Придумали D7, несколько лет назад, до сих пор создать элемент инфоблока нельзя. Зато у нас "ко-пилоты" и BI-аналитика в последнем обновлении.
Про обновления, кстати. В статье ошибкой номер 1 указано "создание самописных компонентов". А вот без самописных компонентов на чистом Битрксе, да на том же Аспро - ставишь обновление - пропадают цены у товаров. Купить ничего нельзя, в корзину добавить нельзя, все товары недоступны - это так называемая обратная совместимость. Каждое обновление как пороховая бочка - сперва на тесте, потом на тесте теста, потом тестирование теста... ну вы поняли. В итоге придумали параметр "COMPATIBLE_MODE", везде пойди проставь, при обновлении-то нельзя автоматически это сделать.
Или вот, хочешь например сделать в инфоблоке свойство-привязку к разделу. Например что бы показывать сопуствующие товары для элемента, или комплектующие какие-нибудь - к этому же инфоблоку товаров привязать нельзя через админку. Ну почему? А потому что если ты вдруг это сделаешь, сломается непонятно что непонятно где, т.к. часть стандартных механизмов не умеет работать с отдельными свойствами-разделами, а сразу по всем смотрит. Ладно, делаешь отдельный инфоблок "сопутки" - так в некоторых компонентах нельзя 2 инфоблока выбрать\подключить.
Компанию по email получить нельзя... Email и телефоны в отдельную таблицу засунули, ладно многие-ко-многим, понятно. Но почему в эту же таблицу засунули и Email-ы контактов и лидов, всё в кучу.
Или вот еще, допустим, была у вас на сайте форма, создающая лиды в портале. Простой понятный процесс - форму заполнил, лид создался. Обновляешь портал - файлы из формы не грузятся. А почему? Потому что выпилили загрузку файлов в лидах! Как говорится в статье, "встает вопрос «Кто виноват?» "...
Ух наболело, разошелся я что-то. Вот вам последняя загадка.
Как называется таблица в которой хранится URL сайта (для многосайтовости)?
Варианты:
1. b_site
2. b_url
3. b_domain
4. b_lang
Работал с этим чудом, абсолютно согласен, но зато подписочки хорошо стоят, а без некоторых можно даже не начинать )0)0
Докину ещё парочку "остроумных инженерных решений":
Если в публичке в константе SITE_ID содержится id сайта, то в админке эта константа будет содержать id языка ( то есть "ru" вместо "s1" ).
(скорее всего, следствие из п.1) в админке не подключаются файлы раздельных init.php для сайтов ( то есть, например, /local/php_interface/s1/init.php )
некоторые методы в классах ядра объявлены как final, так что нельзя просто взять, отнаследоваться и переопределить; приходится подниматься выше по цепочке наследования и копипастить не совсем нужное.
Каждый раз когда приходится работать с битриксом, то всегда возникают проблемы с урлами. #section_code#/ работает, #section_code_path#/ - держи, дружище, 404. И каждый раз как лотерея
Я из за битрикса ушел во фронтенд, react/next. Получил эстетической оргазм от документации и концепции в целом
Про запросы к БД в цикле, как будто стандартные компоненты так не делают. Битрикс можно заставить работать быстро, если не использовать стандартные компоненты, нот тогда чем он лучше любого другого фреймворка? Наличием админки только если, но и эта админка не так уж хороша.
Типичная ситуация, когда знакомишься с новым проектом на Битрикс, первым же делом лезешь в php_interface, чтобы посмотреть сколько костылей поверх Битрикса поставили предыдущие разработчики. А почему? А потому что без них нельзя, писать модуль для расширения стандартного функционала будут только мазохисты.
И да, после меня в php_inerface останется ещё пара костылей, так принято, такие у нас традиции...
А потому что битрикс сделан не как набор лего-конструктор из которого можно лепить что угодно. А как монолит в который впрыскиваются настройки, соответственно везде настройки не сделаны, и из такого не удобно ничего делать кастомного.
Изначальный подход был не верный, и такого софта большинство к сожалению.
Так ли плох Битрикс на самом деле? Разбираем возможные причины технических проблем и низкой скорости интернет-магазина