CMS для интернет-магазина

Например, возникают проблемы при необходимости внедрить многоязычность. Например, косяки с торговыми предложениями. Например, неудобно работать со свойствами при большом количестве разнородных категорий. Дальше лень вспоминать, но когда начинаешь работать, то постоянно натыкаешься то на одно, то на другое.  Для информационников - да, Битрикс удобен. А вот для интернет-магазина - только для небольшого.

Не понимаю в чем тут проблема? Можно подробнее? Перевод темплейта в лэнг файлах, а перевод данных в БД реализовать можно 1001 способом, любым который может быть в любой другой CMS.

Какие с ними проблемы? Это просто доп инфоблок

А это какое отношение имеет  к модулю интернет магазина? И подскажите где для вас эталонно это реализовано? У меня проект есть на >600к номенклатуры разнородной, я не видел в  целом где удобно было бы работать с таким количеством номенклатуры и свойствами. В целом битрикс позволяет настроить свойства для категорий. Но тут я больше сторонник внедрения PIM

Битрикс гибкая система и зависит от "накуренности" разработчиков, чем они "дешевле", тем больший писец будет внутри, но обычно карточка товара состоит из страницыц где размещен компонент, у компонента есть файл бизнес логики, файл шаблона и еще возможно файл скриптов и стилей для фронта.

Справедливо для любой CMS, просто битрикс это фреймворк на стероидах, а значит там намного проще выстрелить себе в ногу. Но у этой медали есть вторая сторона, давайте в рунете поищем какие нибудь большие еком проекты какой нибудь другой CMS? При наличии битрикс разработчика, да еще и толкового, можно очень быстро и относительно дешево запустить достаточно большой и функциональный интернет магазин.

А такой миф я вообще впервые слышу. Многосайтовость у битрикса достаточно удачно как по мне сделана

Возможно, Но что означает "перевод данных в БД"? Где это реализовано в Битриксе? Так-то я могу и на фреймворке слепить ИМ, мне для этого и Битрикс не нужен.

Проблемы при работе. Именно, что это другой инфоблок. Например, при выводе листинга товаров в разделах.

А такое, что если продаёшь телевизоры, велосипеды и унитазы, то у каждой категории свои свойства, и избавиться от лишних  - никак, только если несколько каталогов лепить, но там уже костыли начинаются.

Я не очень понимаю что подразумевается где это сделано? Это надо самому сделать, а где это сделано по другому? В опенкарте где просто поле дублируется под разные языки? Ну так в битриксе можно свойств наклепать которые будут заканчиваться на язык и в коде подставлять поле которое заканчивается на выбранный язык. Можно поступить более радикально и использовать другой инфоблок под другой язык, можно свой функционал запилить и искать там перевод. Вопрос в том что битрикс не ограничивает тебя в решении, как удобно так и делай, хоть через гугл транслейт пропускай.

Так в чем проблема выводить? Зачем вообще выводить торговые предложения? Ведь ТП по сути вариант одного и того же товара, который различается свойством от которого зависит цена, зачем ТП выводить отдельно в листинге?

Мы же про это говорим правильно? https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=42&LESSON_ID=5124

Именно, не ограничивает. Если использовать его как фреймворк. Но фреймворк я могу использовать и другой, здесь же мы говорим про стандартные решения, реализованные в Битриксе, и эта реализация довольно неудобна.

Вот представь себе, есть такие требования у заказчиков, чтобы выводились отдельно карточки товаров с хромированным покрытием, без покрытия, чёрные, белые, серо-буро-малиновые, и чтобы всё это сортировалось по цене.

Да, про это. Вопрос в том, что в базе данных же всё равно эти 100500 свойств хранятся, просто не показываются пользователю? Или не так? Я про производительность в данном случае пишу, потому что наблюдаю тормоза при выводе товаров и грешу на лишние свойства.

Ну у битрикса есть 2 способа хранения свойств  инфоблока, либо в общей таблице, тогда их может быть сколько угодно, но надо обязательно при выборках указывать какие поля достаем, потому что иначе там будет джойнов ровно столько сколько и полей, это специфика EAV паттерна и CMS которые позволяют из админки клепать поля объектам все этим страдают. То есть прям важное условия указывать поля которые выбираешь, а это уже от разработчика зависит, а не от CMS.

Либо второй способ это хранить все поля в отдельной таблице, тогда для 1 товара будет одна строка, а каждое свойство колонкой, тут производительность максимальная, так как все выбирается одним запросом, но у такого подхода есть ряд других минусов, основное это количество колонок в БД ограничено и если таблица очень большая, то добавление поля это alter table который на большой таблице может подзависнуть на приличное количество времени.

Но это все не проблемы битрикса, эти проблемы возникнут у любой CMS или самописа, они архитектурные, решать их можно шардами, но это сложная тема и из коробки её сложно предоставить и шарды теряют транзакционность и короче с такими штуками я сталкивался там, где работают кучка архитекторов и не один десяток разработчиков, но там любая CMS будет злом и все такие проекты в срочном порядки переписываются на микросервисы.

Я честно признаюсь не делал мультиязычность на битриксе, поэтому не представляю что там в стандартных средствах, я знаю что там есть языки, есть языковые настройки, есть модуль локализации. Если мне понадобится что то локализовывать я знаю что в битриксе такие инструменты есть, но окей будем считать что где то есть удобнее, я с этим точно спорить не буду.

Я же правильно понимаю, хочется один родительский товар где заполнены общие характеристики, а выводить хочется все цвета отдельно? Есть примеры удачных решений в других CMS? Мы пробовали так делать с ТП битрикса, выводили чисто ТП, но там гемор получается с разделами товаров и прочего, проще это сделать без ТП, один раз реализовать условное наследование чтоб при сохранении от родителя подтягивались свойства, а при изменении родителя в дочерних всех перезаписывались, но сделать на простых товарах. Но может у вас есть удачное решение?

Нет, я это так и не добил до конца. Сделали какой-то компромиссный вариант. Пробовал выводить отдельно торговые предложения, но там проблемы с пагинацией и с этими всякими умными поисками и фильтрами. А делать всё простыми товарами - как-то не по феншую. По-хорошему, надо свой компонент мастерить, но у заказчика столько денег нету.