Однажды, в понедельник, мне пришла в голову мысль — "а покопаюсь ка я в новом ядре" (новым относительно, но об этом позже). Мысль не появилась на ровном месте, а предпосылками для нее стали:
- тестовое задание, от одной из крупных студий матушки-России (в котором фигурировала аббревиатура ORM),
- идея написать простенький модуль,
- желание одного из клиентов, в перспективе, сделать магазин.
Так вот, историей об этом походе, в густые тропические джунгли, я хочу поделиться.
Коротенькое предисловие
Я не считаю себя гуру программирования ни на Битриксе, ни на чем либо еще. В статье отражены мои наблюдения, опыт и мысли. Конструктивная критика приветствуется, как и аргументированные споры (как Сократ завещал). В предпосылках выделены три обширные темы, которые не будут рассматриваться. Как и их основной аспект — программирование работа с данными в рамках ядра Битрикса D7 (ORM), хотя и является основополагающим фактором для ее написания.
В омут с головй
Аспект работы с данными — основополагающий и без него никуда, подумал я и решил пойти сразу в гугл просмотреть документацию, в надежде на подробное описание и наличия примеров, ну и конечно заглянуть в курсы. С легкой руки и надеждой на что-то вкусное и новенькое. Не видя повода для беспокойства, я отправился в поход. Тучи сгущались...
Что нужно знать о джунглях или правила выживания
Правило №1 — Остерегайтесь недобросовестных турагентов
Решил начать с курсов, увидев интересующие меня пункты меню (модуль и ORM), кучу текстов и вставок кода подумал — все будет быстро, поехали… Так совершилась моя очередная ошибка. По факту же, оказалось:
курсы плохо структурированы — порядок изучения не продуман, можно встретить отсутствие какой либо связи между главами;
постоянные ссылки — я не говорю про отсылки к документации, но ссылки на stack overflow и другие главы (в конце курса, между которыми море информации) очень сильно отвлекают, это не серьезно;
вода и общие слова — галочку по количеству символов поставить можно;
Жирный шрифт используется для выделения важных в смысловом значении слов, терминов, фраз и предложений. То есть то, что особенно важно в контексте описываемого функционала:
трактовка понятий на свой лад — это еще старая тема (API — Component — Template aka MVC);
вставки из документации — копипаст целых кусков, иногда просто чтобы заполнить место;
цитаты разработчиков — тут просто слов нет -_-, зачем это бахвальство;
устаревшие главы — просто удалить их кажется нельзя, усиливают путаницу в разы.
Взаимосвязи между сущностными (устаревший вариант) или Настройки скидок на товар
Конечно плюс в том, что курсы в принципе есть. Наверное плюс, ведь написать что-то только на их основе еще та задача. Ну да ладно. Просмотрев курсы, в основном вставки кода, решил пробовать, еще же есть документация. Дождь начинал моросить...
Правило №2 — Остерегайтесь густых зарослей
Сделав пару простых выборок используя скотч документацию, решил попробовать вывести скидку на товар. И тут начался ливень. Псевдоновое ядро и пасхалочки:
- два модуля для скидок — да да, я долго думал — почему я добавил скидку, в товаре она есть, но я не могу ее получить через класс сущности
DiscountTable. Пришлось писать в поддержку. Ответ был такой:
DiscountTable — скидки на товар, принадлежат к модулю Торговый каталог, функционал устарел и не используется. Рекомендуем использовать Правила корзины.
- отсутствие документации — а можно получить ссылочку на документацию — спросил
я. Ожидая, что с 2013-2015 она появилась. Ответ:
Документация по созданию Правил корзины пока находится в разработке.
- сценарии работы не продуманы — следующий мой вопрос был логичен — А как мне вывести скидку? На что я получил фееричный ответ и закончил общение с поддержкой:
Чтобы получить правила работы с корзиной, которые применяются к товару, вам необходимо будет создать объект корзины и выполнить расчет для товара.
- незавершенный функционал — некоторые методы классов могут вернуть сообщения об ошибках наподобие:
Для добавления скидок на товар используйте вызов CCatalogDiscount::Add()
- сложная архитектура — для создания сложной выборки из нескольких таблиц используются специальные объекты отношений, которые нужно добавить в метод
SomeTable::getMap(). Это не всегда просто (некоторые классы описания сущностей генерируются автоматически). Так же, огорчает факт, что сложную выборку получить просто в формате многомерного массива — нельзя. Да и конструкции отношений могут занимать не один десяток строк. - лабиринты функциональности — в D7 есть места, которые постоянно переписываются и при этом все вариации поддерживаются. Те же объекты для отношений могут быть реализованы через:
Entity\ReferenceField||Bitrix\Main\ORM\Fields\Relations||runtime(при запросе)
Все это очень удручает и заставляет негодовать, мягко говоря. А помимо этого еще и прочие неудобства есть.
Правило №3 — Чертовы насекомые
Битрикс имеет ряд странных и назойливых особенностей, про которые постоянно забываешь, но они вновь мелькают перед твоими глазами:
- правила именования классов и файлов — свой автопогрузчик приводящий все к нижнему регистру, разные имена классов и файлов;
- пути подключения сторонних решений — например composer или vue
(которое просто содержится в библиотеке BX без каких либо явных причин и надстроек);
Углубился в вопрос.
По факту, BX заявляет о следующих плюсах обертки Vue:
- Поддержка многоязычности (Bitrix Framework) — можно добавлять в компонент Vue некоторые функции из BX js, с отключенной для них реактивностью;
- Глобальный Event Bus — для коммуникации между приложениями (если их несколько);
- Наследование компонентов — синтаксический сахар, простой extends;
- Кастомизация компонентов — синтаксический сахар, что-то наподобие подмены (как /bitrix/components/ и /local/components/);
- Единая версия библиотеки (в рамках сайта) — логично, сразу не подумал (спасибо k0rinf).
- поддержка старого кода — куча лишних, ненужных классов и постоянная путаница;
- забытые компоненты — обновлялись только компоненты модуля iblock;
- шаблоны компонентов — пресловутые и всем известные, с бизнес логикой наперевес;
- неявная логика и проблемы кастомизацией — после изменения сценария заказа можно поймать трудноуловимую ошибку и проблемы с модулями;
- вездесущий статик — начинаешь думать, что это нормально;
- спорная админка — местами не удобная и не адаптивная, а разрабатывать модули под нее… ммм;
Мелочи, но они постоянно рядом.
Правило №4 — Незнакомцы и туземцы бывают опасны
У Битрикса есть еще одно благо (нет) — большое сообщество. Ты можешь найти любую информацию, но ее правильность и релевантность будет под большим вопросом. Зачастую можно научиться только создавать костыли или использовать древний код, у которого уже есть адекватная замена. Но встречаются и мессии, способные указать путь своей пастве. Один из таких сказал:
Для работы с инфоблоками пользуйтесь старым ядром, которое хорошо и стабильно работает.
Думаю так и сделаю.
Правило №5 — Хищники где-то рядом
Маркетологи хвалящие продукт. Сравнительные статьи, где Битрикс безусловный лидер. Куча полу программистов, как собственно и я. Множество сайтов, которые просят закончить их мучения. Тоже бич сообщества.
Правило №6 — Имейте запасы воды
С каждой новой проблемой и отсутствием адекватного решения, мораль падает и ты пропускаешь ход приходят мысли, а нужно ли это все, к чему эта трата времени. Может лучше фрэймворк, контейнеризация и непрерывная интеграция, а не эти полумеры. В таких случаях только волевое решение ну и спрос спасает ситуацию.
Правило №7 — Тропический дождь это тяжело
И добивает один малоприятный факт, на попытки программирования, поиск и структурирование информации, общение со знатоками и возвращения к пройденному, узнав что-то новенькое, уходит уйма времени, при отсутствии внятного результата — это постоянно угнетает.
Цивилизация aka выводы
И вот ты выходишь из джунглей. Потрепанный, но живой. Надломленный, но все еще не сломленный. Твои уставшие глаза открыты и они видят все. Путь, куда действительно стоит двигаться и тропы, где нужна особая осторожность.
Битрикс спорный продукт, говорить о том, что он вообще развивается развивается неправильно — не стоит. Но и говорить, что он лучший, не замечая недостатки — это слепо верить.
Для себя я определился, Битриксу — нет. Полный отказ, конечно, не получится, но развиваться в продукте, в котором за 5 лет не появилась поддержка основного функционала и внятной документации, для нового и анонсированного ядра — смысла не вижу. Лучше написать простенькое решение, которое будет использоваться от проекта к проекту на старом ядре и идти изучать новенькое.
Старик Франкенштейн, конечно, достоин жизни, хотя бы пару достойных идей в нем есть. В конце концов, мы же не в средневековье, чтобы сжигать на кострах всех инакомыслящих. Или все таки стоит, что думаете?
P.S Статья написана на скорую руку, сорь если не получилось выстроить последовательную цепочку мысли.
Комментарии (40)
AiZen_13
29.10.2019 21:21И снова — причём тут 1С?
Sergik_DS Автор
29.10.2019 21:31«1С» и «Битрикс» = «1C-Битрикс» — компания (партнерство в равных долях), под которой выпускается продукт «Управление сайтом». Это с юридической точки зрения. Больше никакой связи, с продуктами «1С» (бухгалтерия, предприятие и т.п.), эта статья не имеет. А в названии, разделено просто по причине нежелания дублировать «Битрикс».
justhabrauser
30.10.2019 00:09Потому что два сапога пара (ну или одного поля ягодицы).
Если дать здесь ссылку на недавнюю статью человека типа «как я работал в 1С», то многое за этот Битрикс становится понятно.
istepan
30.10.2019 12:36Почему бы компании не выкинуть Битрикс первой версии и не написать новый с нуля, используя какой нибудь фреймворк? Например Yii.
Это бы дало огромный буст. Да и сейчас модно поддерживать OpenSource решения.
k0rinf
30.10.2019 12:49Это же равносильно смерти. Выбросить рабочий продукт, и начать писать новый. В чем бизнес плюсы? Придется поддерживать и старую и новую версию на Yii.
Для них очень важна совместимость версий. Активная лицензия позволяет получать все последние обновления. Вы можете поставить Битрикс 9 версии, и обновится до последней и при этом все должно остаться рабочим.istepan
30.10.2019 12:50Можно написать что-то типа миграции. Хотя бы для типовых решений.
k0rinf
30.10.2019 12:57Я бы посмотрел на эту миграцию. Битрикс это продукт который живет уже очень много времени. Это все ровно что выкинуть код Photoshop и переписать его с нуля. Даже типовые решения займут кучу времени. У них же есть еще и Битрикс24, и отраслевые решения и т.п. Кода очень много.
k0rinf
30.10.2019 12:54или vue (которое просто содержится в библиотеке BX без каких либо явных причин и надстроек )
Причина в конфликте версий. Битрикс может использовать в своих компонентах Vue одной версии, а вы можете захотеть использовать Vue другой версии. И разные версии Vue могут между собой конфликтовать.
Sergik_DS Автор
30.10.2019 15:44Сразу не подумал. Спасибо, обновил статью. Пока (как я понял), есть только компонент чата (написанный на Vue).
yurievyuri
30.10.2019 15:45Да, все так. Как-то даже уже привыкли.
А какие альтернативы, кто подскажет?
Fahrain
30.10.2019 17:00$order = \Bitrix\Sale\Order::load(123); $shipmentCollection = $order->getShipmentCollection(); foreach ($shipmentCollection as $shipment) { $itemCollection = $shipment->getShipmentItemCollection(); foreach($itemCollection as $it) { ... } }
Это — новое апи битрикса. Разработчики считают, что вот это вот говно — лучше, чем то, что было раньше. Ведь старый код возвращал всего лишь один массив, с которым можно было работать просто в цикле или даже напрямую изменить в нем значение.
Это было слишком просто! Теперь все функции d7 возвращают коллекцию, у которой есть методы, которые не описаны в документации, название которых придумывал бухой китаец не знающий английского. Поэтому одни и те же сущности запрашиваются методами, которые названы похоже, но по-разному и ты каждый раз гадаешь, по какому-же ключевому слову можно нужный тебе метод найти.
Но это на самом деле фигня. Потому что после нахождения нужного метода коллекции ты получаешь новую коллекцию, а внутри нее будет еще одна, и еще, и еще. И в каждой такой коллекции цикл поиска методов работы с данными будет повторяться.
Ну и да, если вы думаете, что «ну можно же в логи print_r сделать и посмотреть», то вы глубоко ошибаетесь, ведь в приведенном примере $itemCollection напечатанный в лог — это всего-лишь 1,6 мб логов (порядка 38 тыс строчек!), в которых есть всё, включая положение звёзд на небе и фазы луны, кроме нужных тебе данных, т.к. они лежат во вложенной коллекции, которую тоже надо дернуть методом, который таки не упоминается в этой портянке логов. И да, у этой самой коллекции тоже будет такой же объем данных — ищите!
А! Самое главное забыл — это же всё древовидное дерево объектов. Т.е. даже если среди 38 тыс строк вы таки найдете нужную, то там все равно надо будет просмотреть предыдущие 20 тыс строк, чтобы таки понять, в какие переменные нужный вам объект вложен. А потом найти методы, чтобы дернуть данные из этих переменных, ибо они напрямую недоступны, причем половина данных получается через спец функции типа ->getName(), ->getId() и т.п., а половина через глобальный метод ->getField("..."), причем они не взаимозаменяемые и надо использовать правильную функцию, а то атата
Новый d7 — это пример того, что разработку нельзя поручать джуниорам. Потому что они ее угробят, причем быстро.k0rinf
30.10.2019 17:21Вы можете предложить способ работы со вложенными коллекциями проще? На сколько я помню ORM позволяет строить запросы с JOIN. На мой взгляд работа с коллекциями куда лучше чем работа с массивами. Я правильно вас понял, Битрикс плохой потому что в print_r печатает вам 1.6 мб логов?
Дайте пример про ->getName(), ->getId() и про ->getField("...").
Fahrain
30.10.2019 17:45Гм. Проблема — не в коллекциях. Проблема в конкретной реализации именно в битриксе. И — в отсутствии документации и стандартизации.
Вот смотрите, в старом ядре я тупо дергал функцию CSaleOrder::GetList и получал внятный простой массив с почти всеми нужными данными. Свойства заказа я мог дозапросить через CSaleOrderPropsValue::GetList и перебрав их циклом получить так же простые понятные массивы. Там даже думать не нужно было, ты находишь функцию, дальше print_r и уже понятно где какие данные.
Сейчас ты сначала тратишь время чтобы понять какую функцию вообще дергать, чтобы получить нужные данные. Потом оказывается, что начинать надо с какой-то коллекции, но чтобы ее получить, надо совершить еще с десяток запросов к другим коллекциям, чтобы таки получить вложенное дерево из десятка уровней, где в конце цепочки наконец-то окажется нужная тебе коллекция.
Вот у меня просто вопрос — нафига? Причем замечу, что вот эти все танцы вприсядку — они нужны для простейших базовых вещей, не для какой-то там экзотики. Вот, посмотрите код «простейшего» оформления заказа на d7. И сравните эту портянку со старым api. Зато теперь модно-молодежно и на классах! Ага.
Дайте пример про ->getName(), ->getId() и про ->getField("...").
Заголовок спойлера... $order = $event->getParameter("ENTITY"); $propertyCollection = $order->getPropertyCollection(); foreach ($propertyCollection as $property) { if($property->getField('CODE') == "FLINK") { $property->setValue($flink); break; } } $event->addResult( new \Bitrix\Main\EventResult( \Bitrix\Main\EventResult::SUCCESS, $order ) );Vasek18
30.10.2019 23:53Меня постоянно спасают статьи некоего мистера Cappuccino. Например, https://mrcappuccino.ru/blog/post/work-with-order-bitrix-d7
По сути единственная вменяемая документацияSergik_DS Автор
31.10.2019 01:05Да, около года назад помогла его статья по созданию заказа. Отражены не все нюансы, но основные моменты достаточно полно показаны.
Fahrain
31.10.2019 04:05Я делал оформление заказов со скидками, товарами в комплекте, наборами и скидками на отдельные части товаров корзины. Это — адский ад само по себе, но в реализации на d7 — у меня просто нет слов, что бы без мата описать весь процесс программирования. Ну и бонусом там оказалось, что в d7 выпилили ид товара в корзине и имея на руках список товаров в корзине, не получалось добраться до соответствующей записи в инфоблоке, так как ид отсутствовал (а в более старом апи — был). Вроде бы уже вернули, но осадок у меня остался :)
Ну и бонусом тогда еще и баг нашел при применении скидки к товару из комплекта, который лежит в корзине.
Я это всё к тому, что примеры с этого сайта, конечно, полезные — но буквально только в самом начале, так как в большинстве случаев требуется что-то более сложное, а оно вообще нигде не описано и даже при поиске текстов ошибок не находится ничего… Вот тогда-то и становится прям весело.Sergik_DS Автор
31.10.2019 13:48Я согласен. У меня была задача, чтобы пользователь мог купить товар в один клик (форма в 3и поля и перенаправление на шлюз банка). Для такого сценария этот сайт помог (банально ответил на вопрос — какие классы использовать и как). НО с коллекциями все равно пришлось посидеть (в итоге — обертка для создания заказа ~ 250 — 300 строк), как и с онлайн-кассами (тоже моменты были).
yurievyuri
31.10.2019 10:43А еще отлично спасает PHPstorm который проиндексировал /bitrix/*.*
Fahrain
31.10.2019 14:30Ага, главное вспомнить, как быстро он потом проект загружает на старте…
А еще весело, когда к тебе принесли сайт, написанный во времена 11го битрикса десять лет назад, который все эти десять лет дорабатывался разными программистами случайным образом и в текущий момент он больше напоминает пирамиду из костылей, склеенную изолентой, которая стоит на полуразложившемся битриксе (причем отдельные талантливые программисты в коде ядра тоже поковырялись). И всё это доступно строго по фтп или вообще к файлам добраться можно только через встроенный файл-менеджер битрикса.yurievyuri
31.10.2019 14:32Согласен, бывает всякое, но разве такого не может быть на любом другом проекте с любым другим движком?
Fahrain
31.10.2019 14:36Может. Но суть в том, что в «устаревшем» битриксе правки можно вносить и отлаживать буквально на коленке, а в «новом-молодежном» без полноценной IDE делать вообще нечего.
Ну и про главное я уже писал выше: объемы кода. Почему на оформление заказа в «устаревшем» битриксе надо 30 строк, а в крутом «новом» — 300? Это что же у нас за такие крутые улучшения-то? Все — буквально вообще все! — стремятся сократить объемы кода и только битрикс радостно бежит в обратную сторонуyurievyuri
31.10.2019 14:38Битрикс побежал в сторону Битрикс24, все остальное им мало интересно, имхо.
Понятно, что выдерживать конкуренцию, как обычная CMS, они в ближайшем будущем врятли смогут.Fahrain
31.10.2019 14:49+1Мне кажется, что они выгнали всех программистов, наняли пару студентов, а все остальные позиции там заняли маркетологи. Ничем иным столь большую маркетинговую активность я объяснить не могу — письма от битрикса приходят чуть ли не по несколько штук в неделю. Причем если несколько лет назад они были относительно редкими и там рассказывали о том, как они улучшили платформу, то сейчас там о том «как создать сайт с нуля», «как настроить скидки» и всякое такое, т.е. про то, чем большинство покупателей заниматься не будут точно, так как есть программисты — а они уже это всё знают.
При этом за последние 3 года не было ни одного существенного обновления компонентов — кроме оформления заказа, код которого сделан так же через жопу, как и d7, и с трудом подлежит хоть какой-то модификации. И это при том, что это чуть ли не самый часто изменяемый компонент — у меня не было ни одного клиента, который не хотел бы там что-нибудь подправить. Но вот если раньше можно было тупо в php вывести нужное поле, то сейчас надо его сначала в json запихнуть, потом обработать в js (на чистом js, с вкраплениями плоходокументированного jquery-аналога от битрикса!), потом еще кучу разных телодвижений — и всё это уже традиционно без документации и хоть каких-то способов отладки.
Ну и как пример еще, напомню, что код компонента iblock.vote остаётся неизменным как минимум с 2011 года и уже тогда он был устаревшим. Видимо, он был сделан настолько хорошо, что является эталоном и не требует улучшений, ага:)
Битрикс24, это, несомненно, полезная вещь — но без самого сайта на битриксе ее ценность уже не столь велика — ведь есть тонны иных платформ, которые делают всё то же самое, есть из чего выбрать. И вот сейчас разработчики битрикса просто рубят те корни, из которых растет всё дерево.yurievyuri
31.10.2019 14:51Я в основном работаю с CRM частью и хочу заметить код там разрастается с огромной скоростью. Но это ладно.
На что свитчнуться сейчас?Fahrain
31.10.2019 14:54Я до сих пор не знаю. Я попробовал yii — но оно ничем не лучше, чем d7, те же грабли, вид сбоку. Прыжки вокруг node.js меня тоже как-то не очень прельщают, wordpress — это извращение, а другие популярные cms написаны чужими для хищников…
Я достаточно хорошо знаю c# — думаю попробовать в сторону asp.net потыкаться. Заодно и возможность на запад программировать появится.yurievyuri
31.10.2019 14:56Эх))) Тогда надо изучать то, что востребовано будет в EU в ближайшие годы, пожалуй
Fahrain
31.10.2019 15:01Ну вот потому и asp.net. Там хотя бы нормальные инструменты отладки есть, в отличие от php. Учитывая тенденции в php всё теперь писать на классах с активным использованием наследования и других фич ООП — с текущими возможностями редакторов под php это всё выглядит извращенной формой мазохизма, имхо.
И xdebug тут ничем не помошник. Достаточно хотя бы того, что ни один редактор не умеет показывать рядом с кодом браузер с динамически обновляющейся страницей (в процессе редактирования кода), если я редактирую одни файлы, а в браузере надо смотреть совершенно иной урл. А так работают ВСЕ cms с шаблонами, поголовно.
datacase
31.10.2019 18:04Спасибо, что присоединились к дискуссии на тему «Как нам помочь им обустроить Битрикс». Я думаю только широкое общественное мнение может сподвигнуть данную контору на перемены к лучшему. Сами они по косвенным признакам забыли про сверхзадачу — в первую очередь делать удобные и полезные программные продукты, а уже потом заработать на этом денег.
Fahrain
31.10.2019 18:28Да тут, кажется, уже поздно. Если уже даже ДНС перешел с битрикса на yii…
Sergik_DS Автор
01.11.2019 00:43Возможно шансы еще есть, но действовать им нужно уже сейчас и кардинально. Выпускать релизы ради конференций и красивых слов — путь в никуда. Мы можем не видеть сложных зависимостей (все таки, скорее всего они есть), но выплевывать очередную сырую версию — просто поставить галочку.
Про создание заказа на старом ядре, сказать ничего не могу — не работал. Но считаю, что новая реализация должна быть в чем-то лучше старой (удобство использования, функциональные возможности и т.п.). А не усложнять работу и делать простое сложным. Смысла в этом нет — это работа ради работы.
Обратная совместимость, баги и отсутствие актуальности — это гири, которые привязаны к ногам утопающего. Отказ от первого: облегчит разработку, освободит часы программистов, сократит количество файлов. Не хотите отказываться — сделайте обертку нового, но это новое нужно сначала правильно и в полном объеме сделать. 2?е и 3?е дают обращение в ТП, что также рабочие часы сотрудников (как минимум), потенциально способных работать над продуктом. Статья по теме ТП — zhurov.me/blog/about-bitrix-support.html, если это так… Еще можно выкинуть готовые компоненты, когда последний раз пользовался — не помню.
Пару слов про ООП — ничего страшного не вижу, но решения должны проектироваться (а не просто — “с сегодняшнего дня мы пишем классы”, как это возможно было в Битриксе) и не использоваться там где это ненужно. Короче говоря, классы — это не зло, просто есть великое множество разновидностей методологии (многие могут быть ошибочными и неудачными, время покажет).
Такое, мое сугубо, личное мнение.Fahrain
01.11.2019 01:22Тут вопрос в том, что все эти классы и новое ядро вообще никому не было нужно. Ну да, некоторые ныли, что «использовать массивы и глобальные переменные — зло!», но по факту, это вот прям совершенно никому не мешало работать с продуктом, ни программистам, ни менеджерам.
Фактически, новое ядро пытается решить проблему, которой нет и не было. Причем делает это самым отвратительным из возможных способов. И все это при том, что в продукте накопилось просто огромнейшее количество проблем, которые не решаются в принципе (а последние 2 года и подавно — мы же пилим новое ядро, терпите!):
- полностью неюзабельный со стороны программистов код шаблона оформления заказа — вы просто представьте себе 300 кб «классического» js-кода без комментариев — в котором надо найти и что-то поменять. Это ж жесть!
- Кстати, в теории у нас новый компонент заказа теперь на классах и есть возможность написать свой класс, чтобы подменить в нем отдельные методы. По факту — возможности этой нет, т.к. неизвестно, как это можно реализовать, документации нет, есть только отдельные невнятные отсылки, что типа да, теперь можно
- до сих пор скидки не умеют быть отрицательными, а наценки — кастрированы и не обладают даже 10% функционала скидок
- последние обновления админки сделали работу со скидками совершенно неочевидной, т.к. интерфейс всячески старается направить тебя в пошаговый мастер, при том, что там нет даже половины функционала от «старого» редактора параметров скидок
- функционал рассылок не обновлялся с момента первой реализации, при том, что пользоваться им нормально невозможно ни через админку, ни программным путем (который еще и не документирован — до сих пор!). Например, через интерфейс можно добавить связку ФИО-емейл в списки рассылок, а загрузить ее из csv файла — нельзя. Да и много там такого же — начали делать и бросили
- Я за почти десять лет видел ровно один сайт с форумом, реализованным на битриксе.
- соцсети в битриксе — мертвы
- сильно поломанный обмен заказами, особенно в случае, если у нас старый сайт, который всё это время допиливали и обновляли. И 1с, которую невозможно обновить из-за доработок. И тут-то у нас столько танцев с бубном, что куча сайтов так и остались на старых версиях битрикса, потому что на новых обмен просто не работает
- после перехода на новую версию магазина — где-то после 16.5-ой, если я правильно помню, сломали механизм замены страницы заказа в админке на кастомную. Причем сама страница теперь на аяксе и даже через события, вызываемые после генерации всей страницы подменить на ней данные на свои практически невозможно. Ну или как минимум настолько трудоемко, что смысла в этом нет
- как писать кастомные страницы под админку не документировано до сих пор! С момента рождения продукта!!! Фактически все решения в маркетплейсе, где есть свои страницы в той или иной степени нарушают основные принципы битрикса
- и да, решения в маркетплейсе никто не модерирует, не проверяет и не тестирует. Все! Буквально 100% шаблонов, с какими я сталкивался из маркетплейса — содержат в себе говнокод. Причем не просто говнокод, а им даже индусы могут позавидовать! (например, на главной странице каталога вывести дерево разделов запросами в базу внутри 4х уровней циклов — это прям нормальное рядовое решение, массовое)
- компоненты и их шаблоны по большей части не обновлялись очень давно. В основном правится только то, что имеет отношение к админке, а то, что используется в публичной части — это или древнее или просто жесть. Кроме того, коли уж у нас тут ООП и все такое — так почему, например, шаблон списка товаров каталога содержит все возможные условия проверки всех вариантов галочек? Там только блок, который выводит цену товара занимает по 2 экрана кода! Это нельзя было вынести в отдельные файлы?
- уже года 4 как гугл активно напирает на то, что «надо оптимизировать картинки, ребята!». И — где? Всеми картинками рулит ядро битрикса, ресайзом и сжатием рулит оно же — где оптимизации?? Или хотя бы способ подсунуть туда правильный оптимизатор в конец цепочки обработки?
- А еще есть местоположения, которые с самого момента своего появления были неудобны, работали криво, медленно и не давали обновить список, потому что все заказы ссылаются на ид города, а он меняется после обновлений. Сейчас туда тоже понапихали аякса и в целом стало еще «лучше»: я недавно пытался загрузить полный список городов всех стран, так я не смог — половина стран вообще не содержит городов, а при попытке загрузить вторую половину выпадает ошибка «не удалось загрузить», после чего таблица местоположений в базе портится и лечится только удалением всего и загрузкой заново
… и там еще много такого же рода проблем, причем замечу — по большей части они не имеют отношения к тому, на чем сделано ядро — на функциях или на классах с наследованием.
А сейчас у нас к уже привычным проблемам добавляются грабли с новым ядром, написанным левой пяткой в лучших традициях индусских кодеров.datacase
01.11.2019 12:15+1По злосчастному пункту 13 мне в другой статье посоветовали модуль по оптимизации картинок, проверил тут, отличное качество и степень сжатия. Хотелось бы конечно на платформе это счастье, но лучше уж за дополнительную плату, чем вообще никак.
datacase
01.11.2019 03:22Я в 38 годов решил, что хочу стать программистом и сейчас им работаю. Так что меняться никогда не поздно.
vvm13
О, посхалочки. Франкинштейн. Таких слов я не читал ещё.