Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 40
Интересное чтиво, спасибо!
И снова — причём тут 1С?
«1С» и «Битрикс» = «1C-Битрикс» — компания (партнерство в равных долях), под которой выпускается продукт «Управление сайтом». Это с юридической точки зрения. Больше никакой связи, с продуктами «1С» (бухгалтерия, предприятие и т.п.), эта статья не имеет. А в названии, разделено просто по причине нежелания дублировать «Битрикс».
Потому что два сапога пара (ну или одного поля ягодицы).
Если дать здесь ссылку на недавнюю статью человека типа «как я работал в 1С», то многое за этот Битрикс становится понятно.
Если дать здесь ссылку на недавнюю статью человека типа «как я работал в 1С», то многое за этот Битрикс становится понятно.
Почему бы компании не выкинуть Битрикс первой версии и не написать новый с нуля, используя какой нибудь фреймворк? Например Yii.
Это бы дало огромный буст. Да и сейчас модно поддерживать OpenSource решения.
Это бы дало огромный буст. Да и сейчас модно поддерживать OpenSource решения.
Это же равносильно смерти. Выбросить рабочий продукт, и начать писать новый. В чем бизнес плюсы? Придется поддерживать и старую и новую версию на Yii.
Для них очень важна совместимость версий. Активная лицензия позволяет получать все последние обновления. Вы можете поставить Битрикс 9 версии, и обновится до последней и при этом все должно остаться рабочим.
Для них очень важна совместимость версий. Активная лицензия позволяет получать все последние обновления. Вы можете поставить Битрикс 9 версии, и обновится до последней и при этом все должно остаться рабочим.
Как будто бы таких попыток никто не делал. Нет. Буста не даёт это вообще. Бесплатных хороших решений без скрытой монетизации нет.
или vue (которое просто содержится в библиотеке BX без каких либо явных причин и надстроек )
Причина в конфликте версий. Битрикс может использовать в своих компонентах Vue одной версии, а вы можете захотеть использовать Vue другой версии. И разные версии Vue могут между собой конфликтовать.
Да, все так. Как-то даже уже привыкли.
А какие альтернативы, кто подскажет?
А какие альтернативы, кто подскажет?
$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 — это пример того, что разработку нельзя поручать джуниорам. Потому что они ее угробят, причем быстро.
Вы можете предложить способ работы со вложенными коллекциями проще? На сколько я помню ORM позволяет строить запросы с JOIN. На мой взгляд работа с коллекциями куда лучше чем работа с массивами. Я правильно вас понял, Битрикс плохой потому что в print_r печатает вам 1.6 мб логов?
Дайте пример про ->getName(), ->getId() и про ->getField("...").
Дайте пример про ->getName(), ->getId() и про ->getField("...").
ответил тут, почему-то в отдельную ветку ответ ушел
Гм. Проблема — не в коллекциях. Проблема в конкретной реализации именно в битриксе. И — в отсутствии документации и стандартизации.
Вот смотрите, в старом ядре я тупо дергал функцию CSaleOrder::GetList и получал внятный простой массив с почти всеми нужными данными. Свойства заказа я мог дозапросить через CSaleOrderPropsValue::GetList и перебрав их циклом получить так же простые понятные массивы. Там даже думать не нужно было, ты находишь функцию, дальше print_r и уже понятно где какие данные.
Сейчас ты сначала тратишь время чтобы понять какую функцию вообще дергать, чтобы получить нужные данные. Потом оказывается, что начинать надо с какой-то коллекции, но чтобы ее получить, надо совершить еще с десяток запросов к другим коллекциям, чтобы таки получить вложенное дерево из десятка уровней, где в конце цепочки наконец-то окажется нужная тебе коллекция.
Вот у меня просто вопрос — нафига? Причем замечу, что вот эти все танцы вприсядку — они нужны для простейших базовых вещей, не для какой-то там экзотики. Вот, посмотрите код «простейшего» оформления заказа на d7. И сравните эту портянку со старым api. Зато теперь модно-молодежно и на классах! Ага.
Замечу, что вот это вот всё только ради того, чтобы в заказ положить ОДНО значение в свойство заказа. И да, в самой коллекции заказа используются для того же самого отдельные методы. А такого типа коллекций в новом апи — огромное количество. И все они используют свой, уникальный подход к наименованию функций, способу наполнению данными и перебора элементов.
В старом апи всё это можно было сделать вообще в один вызов функции с правильным массивом.
И да, вы не правильно поняли, проблема не в том, что «Битрикс плохой потому что в print_r печатает вам 1.6 мб логов», а в том, что у вас есть только два пути: или вы изучаете 1.6 мб логов, или лезете в исходный код модулей битрикса и изучаете там портянку из десятка взаимоувязанных классов без единого полезного комментария, при полностью отсутствующей документации и примерах.
Вся та работа с заказами, которую я на старом апи делал за 10-20 минут, сейчас занимает несколько полноценных дней ковыряния, гуглежа и отладки с втыканием логирования в файлы модулей битрикса, т.к. иначе понять как добраться до нужных данных просто невозможно.
И вот именно это и есть будущая смерть продукта. Потому что желающих делать вот это вот всё в сотни раз меньше тех, кто делает print_r.
Вот смотрите, в старом ядре я тупо дергал функцию 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
)
);
Замечу, что вот это вот всё только ради того, чтобы в заказ положить ОДНО значение в свойство заказа. И да, в самой коллекции заказа используются для того же самого отдельные методы. А такого типа коллекций в новом апи — огромное количество. И все они используют свой, уникальный подход к наименованию функций, способу наполнению данными и перебора элементов.
В старом апи всё это можно было сделать вообще в один вызов функции с правильным массивом.
И да, вы не правильно поняли, проблема не в том, что «Битрикс плохой потому что в print_r печатает вам 1.6 мб логов», а в том, что у вас есть только два пути: или вы изучаете 1.6 мб логов, или лезете в исходный код модулей битрикса и изучаете там портянку из десятка взаимоувязанных классов без единого полезного комментария, при полностью отсутствующей документации и примерах.
Вся та работа с заказами, которую я на старом апи делал за 10-20 минут, сейчас занимает несколько полноценных дней ковыряния, гуглежа и отладки с втыканием логирования в файлы модулей битрикса, т.к. иначе понять как добраться до нужных данных просто невозможно.
И вот именно это и есть будущая смерть продукта. Потому что желающих делать вот это вот всё в сотни раз меньше тех, кто делает print_r.
Меня постоянно спасают статьи некоего мистера Cappuccino. Например, https://mrcappuccino.ru/blog/post/work-with-order-bitrix-d7
По сути единственная вменяемая документация
Да, около года назад помогла его статья по созданию заказа. Отражены не все нюансы, но основные моменты достаточно полно показаны.
Я делал оформление заказов со скидками, товарами в комплекте, наборами и скидками на отдельные части товаров корзины. Это — адский ад само по себе, но в реализации на d7 — у меня просто нет слов, что бы без мата описать весь процесс программирования. Ну и бонусом там оказалось, что в d7 выпилили ид товара в корзине и имея на руках список товаров в корзине, не получалось добраться до соответствующей записи в инфоблоке, так как ид отсутствовал (а в более старом апи — был). Вроде бы уже вернули, но осадок у меня остался :)
Ну и бонусом тогда еще и баг нашел при применении скидки к товару из комплекта, который лежит в корзине.
Я это всё к тому, что примеры с этого сайта, конечно, полезные — но буквально только в самом начале, так как в большинстве случаев требуется что-то более сложное, а оно вообще нигде не описано и даже при поиске текстов ошибок не находится ничего… Вот тогда-то и становится прям весело.
Ну и бонусом тогда еще и баг нашел при применении скидки к товару из комплекта, который лежит в корзине.
Я это всё к тому, что примеры с этого сайта, конечно, полезные — но буквально только в самом начале, так как в большинстве случаев требуется что-то более сложное, а оно вообще нигде не описано и даже при поиске текстов ошибок не находится ничего… Вот тогда-то и становится прям весело.
Я согласен. У меня была задача, чтобы пользователь мог купить товар в один клик (форма в 3и поля и перенаправление на шлюз банка). Для такого сценария этот сайт помог (банально ответил на вопрос — какие классы использовать и как). НО с коллекциями все равно пришлось посидеть (в итоге — обертка для создания заказа ~ 250 — 300 строк), как и с онлайн-кассами (тоже моменты были).
А еще отлично спасает PHPstorm который проиндексировал /bitrix/*.*
Ага, главное вспомнить, как быстро он потом проект загружает на старте…
А еще весело, когда к тебе принесли сайт, написанный во времена 11го битрикса десять лет назад, который все эти десять лет дорабатывался разными программистами случайным образом и в текущий момент он больше напоминает пирамиду из костылей, склеенную изолентой, которая стоит на полуразложившемся битриксе (причем отдельные талантливые программисты в коде ядра тоже поковырялись). И всё это доступно строго по фтп или вообще к файлам добраться можно только через встроенный файл-менеджер битрикса.
А еще весело, когда к тебе принесли сайт, написанный во времена 11го битрикса десять лет назад, который все эти десять лет дорабатывался разными программистами случайным образом и в текущий момент он больше напоминает пирамиду из костылей, склеенную изолентой, которая стоит на полуразложившемся битриксе (причем отдельные талантливые программисты в коде ядра тоже поковырялись). И всё это доступно строго по фтп или вообще к файлам добраться можно только через встроенный файл-менеджер битрикса.
Согласен, бывает всякое, но разве такого не может быть на любом другом проекте с любым другим движком?
Может. Но суть в том, что в «устаревшем» битриксе правки можно вносить и отлаживать буквально на коленке, а в «новом-молодежном» без полноценной IDE делать вообще нечего.
Ну и про главное я уже писал выше: объемы кода. Почему на оформление заказа в «устаревшем» битриксе надо 30 строк, а в крутом «новом» — 300? Это что же у нас за такие крутые улучшения-то? Все — буквально вообще все! — стремятся сократить объемы кода и только битрикс радостно бежит в обратную сторону
Ну и про главное я уже писал выше: объемы кода. Почему на оформление заказа в «устаревшем» битриксе надо 30 строк, а в крутом «новом» — 300? Это что же у нас за такие крутые улучшения-то? Все — буквально вообще все! — стремятся сократить объемы кода и только битрикс радостно бежит в обратную сторону
Битрикс побежал в сторону Битрикс24, все остальное им мало интересно, имхо.
Понятно, что выдерживать конкуренцию, как обычная CMS, они в ближайшем будущем врятли смогут.
Понятно, что выдерживать конкуренцию, как обычная CMS, они в ближайшем будущем врятли смогут.
Мне кажется, что они выгнали всех программистов, наняли пару студентов, а все остальные позиции там заняли маркетологи. Ничем иным столь большую маркетинговую активность я объяснить не могу — письма от битрикса приходят чуть ли не по несколько штук в неделю. Причем если несколько лет назад они были относительно редкими и там рассказывали о том, как они улучшили платформу, то сейчас там о том «как создать сайт с нуля», «как настроить скидки» и всякое такое, т.е. про то, чем большинство покупателей заниматься не будут точно, так как есть программисты — а они уже это всё знают.
При этом за последние 3 года не было ни одного существенного обновления компонентов — кроме оформления заказа, код которого сделан так же через жопу, как и d7, и с трудом подлежит хоть какой-то модификации. И это при том, что это чуть ли не самый часто изменяемый компонент — у меня не было ни одного клиента, который не хотел бы там что-нибудь подправить. Но вот если раньше можно было тупо в php вывести нужное поле, то сейчас надо его сначала в json запихнуть, потом обработать в js (на чистом js, с вкраплениями плоходокументированного jquery-аналога от битрикса!), потом еще кучу разных телодвижений — и всё это уже традиционно без документации и хоть каких-то способов отладки.
Ну и как пример еще, напомню, что код компонента iblock.vote остаётся неизменным как минимум с 2011 года и уже тогда он был устаревшим. Видимо, он был сделан настолько хорошо, что является эталоном и не требует улучшений, ага:)
Битрикс24, это, несомненно, полезная вещь — но без самого сайта на битриксе ее ценность уже не столь велика — ведь есть тонны иных платформ, которые делают всё то же самое, есть из чего выбрать. И вот сейчас разработчики битрикса просто рубят те корни, из которых растет всё дерево.
При этом за последние 3 года не было ни одного существенного обновления компонентов — кроме оформления заказа, код которого сделан так же через жопу, как и d7, и с трудом подлежит хоть какой-то модификации. И это при том, что это чуть ли не самый часто изменяемый компонент — у меня не было ни одного клиента, который не хотел бы там что-нибудь подправить. Но вот если раньше можно было тупо в php вывести нужное поле, то сейчас надо его сначала в json запихнуть, потом обработать в js (на чистом js, с вкраплениями плоходокументированного jquery-аналога от битрикса!), потом еще кучу разных телодвижений — и всё это уже традиционно без документации и хоть каких-то способов отладки.
Ну и как пример еще, напомню, что код компонента iblock.vote остаётся неизменным как минимум с 2011 года и уже тогда он был устаревшим. Видимо, он был сделан настолько хорошо, что является эталоном и не требует улучшений, ага:)
Битрикс24, это, несомненно, полезная вещь — но без самого сайта на битриксе ее ценность уже не столь велика — ведь есть тонны иных платформ, которые делают всё то же самое, есть из чего выбрать. И вот сейчас разработчики битрикса просто рубят те корни, из которых растет всё дерево.
Я в основном работаю с CRM частью и хочу заметить код там разрастается с огромной скоростью. Но это ладно.
На что свитчнуться сейчас?
На что свитчнуться сейчас?
Я до сих пор не знаю. Я попробовал yii — но оно ничем не лучше, чем d7, те же грабли, вид сбоку. Прыжки вокруг node.js меня тоже как-то не очень прельщают, wordpress — это извращение, а другие популярные cms написаны чужими для хищников…
Я достаточно хорошо знаю c# — думаю попробовать в сторону asp.net потыкаться. Заодно и возможность на запад программировать появится.
Я достаточно хорошо знаю c# — думаю попробовать в сторону asp.net потыкаться. Заодно и возможность на запад программировать появится.
Эх))) Тогда надо изучать то, что востребовано будет в EU в ближайшие годы, пожалуй
Ну вот потому и asp.net. Там хотя бы нормальные инструменты отладки есть, в отличие от php. Учитывая тенденции в php всё теперь писать на классах с активным использованием наследования и других фич ООП — с текущими возможностями редакторов под php это всё выглядит извращенной формой мазохизма, имхо.
И xdebug тут ничем не помошник. Достаточно хотя бы того, что ни один редактор не умеет показывать рядом с кодом браузер с динамически обновляющейся страницей (в процессе редактирования кода), если я редактирую одни файлы, а в браузере надо смотреть совершенно иной урл. А так работают ВСЕ cms с шаблонами, поголовно.
И xdebug тут ничем не помошник. Достаточно хотя бы того, что ни один редактор не умеет показывать рядом с кодом браузер с динамически обновляющейся страницей (в процессе редактирования кода), если я редактирую одни файлы, а в браузере надо смотреть совершенно иной урл. А так работают ВСЕ cms с шаблонами, поголовно.
Спасибо, что присоединились к дискуссии на тему «Как нам помочь им обустроить Битрикс». Я думаю только широкое общественное мнение может сподвигнуть данную контору на перемены к лучшему. Сами они по косвенным признакам забыли про сверхзадачу — в первую очередь делать удобные и полезные программные продукты, а уже потом заработать на этом денег.
Да тут, кажется, уже поздно. Если уже даже ДНС перешел с битрикса на yii…
Возможно шансы еще есть, но действовать им нужно уже сейчас и кардинально. Выпускать релизы ради конференций и красивых слов — путь в никуда. Мы можем не видеть сложных зависимостей (все таки, скорее всего они есть), но выплевывать очередную сырую версию — просто поставить галочку.
Про создание заказа на старом ядре, сказать ничего не могу — не работал. Но считаю, что новая реализация должна быть в чем-то лучше старой (удобство использования, функциональные возможности и т.п.). А не усложнять работу и делать простое сложным. Смысла в этом нет — это работа ради работы.
Обратная совместимость, баги и отсутствие актуальности — это гири, которые привязаны к ногам утопающего. Отказ от первого: облегчит разработку, освободит часы программистов, сократит количество файлов. Не хотите отказываться — сделайте обертку нового, но это новое нужно сначала правильно и в полном объеме сделать. 2‐е и 3‐е дают обращение в ТП, что также рабочие часы сотрудников (как минимум), потенциально способных работать над продуктом. Статья по теме ТП — zhurov.me/blog/about-bitrix-support.html, если это так… Еще можно выкинуть готовые компоненты, когда последний раз пользовался — не помню.
Пару слов про ООП — ничего страшного не вижу, но решения должны проектироваться (а не просто — “с сегодняшнего дня мы пишем классы”, как это возможно было в Битриксе) и не использоваться там где это ненужно. Короче говоря, классы — это не зло, просто есть великое множество разновидностей методологии (многие могут быть ошибочными и неудачными, время покажет).
Такое, мое сугубо, личное мнение.
Про создание заказа на старом ядре, сказать ничего не могу — не работал. Но считаю, что новая реализация должна быть в чем-то лучше старой (удобство использования, функциональные возможности и т.п.). А не усложнять работу и делать простое сложным. Смысла в этом нет — это работа ради работы.
Обратная совместимость, баги и отсутствие актуальности — это гири, которые привязаны к ногам утопающего. Отказ от первого: облегчит разработку, освободит часы программистов, сократит количество файлов. Не хотите отказываться — сделайте обертку нового, но это новое нужно сначала правильно и в полном объеме сделать. 2‐е и 3‐е дают обращение в ТП, что также рабочие часы сотрудников (как минимум), потенциально способных работать над продуктом. Статья по теме ТП — zhurov.me/blog/about-bitrix-support.html, если это так… Еще можно выкинуть готовые компоненты, когда последний раз пользовался — не помню.
Пару слов про ООП — ничего страшного не вижу, но решения должны проектироваться (а не просто — “с сегодняшнего дня мы пишем классы”, как это возможно было в Битриксе) и не использоваться там где это ненужно. Короче говоря, классы — это не зло, просто есть великое множество разновидностей методологии (многие могут быть ошибочными и неудачными, время покажет).
Такое, мое сугубо, личное мнение.
Тут вопрос в том, что все эти классы и новое ядро вообще никому не было нужно. Ну да, некоторые ныли, что «использовать массивы и глобальные переменные — зло!», но по факту, это вот прям совершенно никому не мешало работать с продуктом, ни программистам, ни менеджерам.
Фактически, новое ядро пытается решить проблему, которой нет и не было. Причем делает это самым отвратительным из возможных способов. И все это при том, что в продукте накопилось просто огромнейшее количество проблем, которые не решаются в принципе (а последние 2 года и подавно — мы же пилим новое ядро, терпите!):
… и там еще много такого же рода проблем, причем замечу — по большей части они не имеют отношения к тому, на чем сделано ядро — на функциях или на классах с наследованием.
А сейчас у нас к уже привычным проблемам добавляются грабли с новым ядром, написанным левой пяткой в лучших традициях индусских кодеров.
Фактически, новое ядро пытается решить проблему, которой нет и не было. Причем делает это самым отвратительным из возможных способов. И все это при том, что в продукте накопилось просто огромнейшее количество проблем, которые не решаются в принципе (а последние 2 года и подавно — мы же пилим новое ядро, терпите!):
- полностью неюзабельный со стороны программистов код шаблона оформления заказа — вы просто представьте себе 300 кб «классического» js-кода без комментариев — в котором надо найти и что-то поменять. Это ж жесть!
- Кстати, в теории у нас новый компонент заказа теперь на классах и есть возможность написать свой класс, чтобы подменить в нем отдельные методы. По факту — возможности этой нет, т.к. неизвестно, как это можно реализовать, документации нет, есть только отдельные невнятные отсылки, что типа да, теперь можно
- до сих пор скидки не умеют быть отрицательными, а наценки — кастрированы и не обладают даже 10% функционала скидок
- последние обновления админки сделали работу со скидками совершенно неочевидной, т.к. интерфейс всячески старается направить тебя в пошаговый мастер, при том, что там нет даже половины функционала от «старого» редактора параметров скидок
- функционал рассылок не обновлялся с момента первой реализации, при том, что пользоваться им нормально невозможно ни через админку, ни программным путем (который еще и не документирован — до сих пор!). Например, через интерфейс можно добавить связку ФИО-емейл в списки рассылок, а загрузить ее из csv файла — нельзя. Да и много там такого же — начали делать и бросили
- Я за почти десять лет видел ровно один сайт с форумом, реализованным на битриксе.
- соцсети в битриксе — мертвы
- сильно поломанный обмен заказами, особенно в случае, если у нас старый сайт, который всё это время допиливали и обновляли. И 1с, которую невозможно обновить из-за доработок. И тут-то у нас столько танцев с бубном, что куча сайтов так и остались на старых версиях битрикса, потому что на новых обмен просто не работает
- после перехода на новую версию магазина — где-то после 16.5-ой, если я правильно помню, сломали механизм замены страницы заказа в админке на кастомную. Причем сама страница теперь на аяксе и даже через события, вызываемые после генерации всей страницы подменить на ней данные на свои практически невозможно. Ну или как минимум настолько трудоемко, что смысла в этом нет
- как писать кастомные страницы под админку не документировано до сих пор! С момента рождения продукта!!! Фактически все решения в маркетплейсе, где есть свои страницы в той или иной степени нарушают основные принципы битрикса
- и да, решения в маркетплейсе никто не модерирует, не проверяет и не тестирует. Все! Буквально 100% шаблонов, с какими я сталкивался из маркетплейса — содержат в себе говнокод. Причем не просто говнокод, а им даже индусы могут позавидовать! (например, на главной странице каталога вывести дерево разделов запросами в базу внутри 4х уровней циклов — это прям нормальное рядовое решение, массовое)
- компоненты и их шаблоны по большей части не обновлялись очень давно. В основном правится только то, что имеет отношение к админке, а то, что используется в публичной части — это или древнее или просто жесть. Кроме того, коли уж у нас тут ООП и все такое — так почему, например, шаблон списка товаров каталога содержит все возможные условия проверки всех вариантов галочек? Там только блок, который выводит цену товара занимает по 2 экрана кода! Это нельзя было вынести в отдельные файлы?
- уже года 4 как гугл активно напирает на то, что «надо оптимизировать картинки, ребята!». И — где? Всеми картинками рулит ядро битрикса, ресайзом и сжатием рулит оно же — где оптимизации?? Или хотя бы способ подсунуть туда правильный оптимизатор в конец цепочки обработки?
- А еще есть местоположения, которые с самого момента своего появления были неудобны, работали криво, медленно и не давали обновить список, потому что все заказы ссылаются на ид города, а он меняется после обновлений. Сейчас туда тоже понапихали аякса и в целом стало еще «лучше»: я недавно пытался загрузить полный список городов всех стран, так я не смог — половина стран вообще не содержит городов, а при попытке загрузить вторую половину выпадает ошибка «не удалось загрузить», после чего таблица местоположений в базе портится и лечится только удалением всего и загрузкой заново
… и там еще много такого же рода проблем, причем замечу — по большей части они не имеют отношения к тому, на чем сделано ядро — на функциях или на классах с наследованием.
А сейчас у нас к уже привычным проблемам добавляются грабли с новым ядром, написанным левой пяткой в лучших традициях индусских кодеров.
По злосчастному пункту 13 мне в другой статье посоветовали модуль по оптимизации картинок, проверил тут, отличное качество и степень сжатия. Хотелось бы конечно на платформе это счастье, но лучше уж за дополнительную плату, чем вообще никак.
Я в 38 годов решил, что хочу стать программистом и сейчас им работаю. Так что меняться никогда не поздно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
За что, Битрикс? Или сказочный мир 1С