- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Чем же именно он неудачный там?
Например, возникают проблемы при необходимости внедрить многоязычность. Например, косяки с торговыми предложениями. Например, неудобно работать со свойствами при большом количестве разнородных категорий. Дальше лень вспоминать, но когда начинаешь работать, то постоянно натыкаешься то на одно, то на другое. Для информационников - да, Битрикс удобен. А вот для интернет-магазина - только для небольшого.
Например, возникают проблемы при необходимости внедрить многоязычность.
Не понимаю в чем тут проблема? Можно подробнее? Перевод темплейта в лэнг файлах, а перевод данных в БД реализовать можно 1001 способом, любым который может быть в любой другой CMS.
Например, косяки с торговыми предложениями
Какие с ними проблемы? Это просто доп инфоблок
Например, неудобно работать со свойствами при большом количестве разнородных категорий.
А это какое отношение имеет к модулю интернет магазина? И подскажите где для вас эталонно это реализовано? У меня проект есть на >600к номенклатуры разнородной, я не видел в целом где удобно было бы работать с таким количеством номенклатуры и свойствами. В целом битрикс позволяет настроить свойства для категорий. Но тут я больше сторонник внедрения PIM
ага ага, карточка товара состоит из 50 файлов, которые разбросаны по разным папкам, очень удобная cms
Битрикс гибкая система и зависит от "накуренности" разработчиков, чем они "дешевле", тем больший писец будет внутри, но обычно карточка товара состоит из страницыц где размещен компонент, у компонента есть файл бизнес логики, файл шаблона и еще возможно файл скриптов и стилей для фронта.
если нет программиста (кодера) 1с битрикс это самая ужасная платформа для интернет магазина
Справедливо для любой CMS, просто битрикс это фреймворк на стероидах, а значит там намного проще выстрелить себе в ногу. Но у этой медали есть вторая сторона, давайте в рунете поищем какие нибудь большие еком проекты какой нибудь другой CMS? При наличии битрикс разработчика, да еще и толкового, можно очень быстро и относительно дешево запустить достаточно большой и функциональный интернет магазин.
еще поверх этой шляпы придумал многосайтовость чтоб обычные юзеры вообще с ума сошли
А такой миф я вообще впервые слышу. Многосайтовость у битрикса достаточно удачно как по мне сделана
перевод данных в БД реализовать можно 1001 способом
Возможно, Но что означает "перевод данных в БД"? Где это реализовано в Битриксе? Так-то я могу и на фреймворке слепить ИМ, мне для этого и Битрикс не нужен.
Какие с ними проблемы? Это просто доп инфоблок
Проблемы при работе. Именно, что это другой инфоблок. Например, при выводе листинга товаров в разделах.
А это какое отношение имеет к модулю интернет магазина?
А такое, что если продаёшь телевизоры, велосипеды и унитазы, то у каждой категории свои свойства, и избавиться от лишних - никак, только если несколько каталогов лепить, но там уже костыли начинаются.
Возможно, Но что означает "перевод данных в БД"? Где это реализовано в Битриксе? Так-то я могу и на фреймворке слепить ИМ, мне для этого и Битрикс не нужен.
Я не очень понимаю что подразумевается где это сделано? Это надо самому сделать, а где это сделано по другому? В опенкарте где просто поле дублируется под разные языки? Ну так в битриксе можно свойств наклепать которые будут заканчиваться на язык и в коде подставлять поле которое заканчивается на выбранный язык. Можно поступить более радикально и использовать другой инфоблок под другой язык, можно свой функционал запилить и искать там перевод. Вопрос в том что битрикс не ограничивает тебя в решении, как удобно так и делай, хоть через гугл транслейт пропускай.
Проблемы при работе. Именно, что это другой инфоблок. Например, при выводе листинга товаров в разделах.
Так в чем проблема выводить? Зачем вообще выводить торговые предложения? Ведь ТП по сути вариант одного и того же товара, который различается свойством от которого зависит цена, зачем ТП выводить отдельно в листинге?
А такое, что если продаёшь телевизоры, велосипеды и унитазы, то у каждой категории свои свойства, и избавиться от лишних - никак, только если несколько каталогов лепить, но там уже костыли начинаются.
Мы же про это говорим правильно? https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=42&LESSON_ID=5124
битрикс не ограничивает тебя в решении
Именно, не ограничивает. Если использовать его как фреймворк. Но фреймворк я могу использовать и другой, здесь же мы говорим про стандартные решения, реализованные в Битриксе, и эта реализация довольно неудобна.
Зачем вообще выводить торговые предложения? Ведь ТП по сути вариант одного и того же товара, который различается свойством от которого зависит цена, зачем ТП выводить отдельно в листинге?
Вот представь себе, есть такие требования у заказчиков, чтобы выводились отдельно карточки товаров с хромированным покрытием, без покрытия, чёрные, белые, серо-буро-малиновые, и чтобы всё это сортировалось по цене.
Мы же про это говорим правильно?
Да, про это. Вопрос в том, что в базе данных же всё равно эти 100500 свойств хранятся, просто не показываются пользователю? Или не так? Я про производительность в данном случае пишу, потому что наблюдаю тормоза при выводе товаров и грешу на лишние свойства.
Да, про это. Вопрос в том, что в базе данных же всё равно эти 100500 свойств хранятся, просто не показываются пользователю? Или не так? Я про производительность в данном случае пишу, потому что наблюдаю тормоза при выводе товаров и грешу на лишние свойства.
Ну у битрикса есть 2 способа хранения свойств инфоблока, либо в общей таблице, тогда их может быть сколько угодно, но надо обязательно при выборках указывать какие поля достаем, потому что иначе там будет джойнов ровно столько сколько и полей, это специфика EAV паттерна и CMS которые позволяют из админки клепать поля объектам все этим страдают. То есть прям важное условия указывать поля которые выбираешь, а это уже от разработчика зависит, а не от CMS.
Либо второй способ это хранить все поля в отдельной таблице, тогда для 1 товара будет одна строка, а каждое свойство колонкой, тут производительность максимальная, так как все выбирается одним запросом, но у такого подхода есть ряд других минусов, основное это количество колонок в БД ограничено и если таблица очень большая, то добавление поля это alter table который на большой таблице может подзависнуть на приличное количество времени.
Но это все не проблемы битрикса, эти проблемы возникнут у любой CMS или самописа, они архитектурные, решать их можно шардами, но это сложная тема и из коробки её сложно предоставить и шарды теряют транзакционность и короче с такими штуками я сталкивался там, где работают кучка архитекторов и не один десяток разработчиков, но там любая CMS будет злом и все такие проекты в срочном порядки переписываются на микросервисы.
Именно, не ограничивает. Если использовать его как фреймворк. Но фреймворк я могу использовать и другой, здесь же мы говорим про стандартные решения, реализованные в Битриксе, и эта реализация довольно неудобна.
Я честно признаюсь не делал мультиязычность на битриксе, поэтому не представляю что там в стандартных средствах, я знаю что там есть языки, есть языковые настройки, есть модуль локализации. Если мне понадобится что то локализовывать я знаю что в битриксе такие инструменты есть, но окей будем считать что где то есть удобнее, я с этим точно спорить не буду.
Вот представь себе, есть такие требования у заказчиков, чтобы выводились отдельно карточки товаров с хромированным покрытием, без покрытия, чёрные, белые, серо-буро-малиновые, и чтобы всё это сортировалось по цене.
Я же правильно понимаю, хочется один родительский товар где заполнены общие характеристики, а выводить хочется все цвета отдельно? Есть примеры удачных решений в других CMS? Мы пробовали так делать с ТП битрикса, выводили чисто ТП, но там гемор получается с разделами товаров и прочего, проще это сделать без ТП, один раз реализовать условное наследование чтоб при сохранении от родителя подтягивались свойства, а при изменении родителя в дочерних всех перезаписывались, но сделать на простых товарах. Но может у вас есть удачное решение?
Но может у вас есть удачное решение?
Нет, я это так и не добил до конца. Сделали какой-то компромиссный вариант. Пробовал выводить отдельно торговые предложения, но там проблемы с пагинацией и с этими всякими умными поисками и фильтрами. А делать всё простыми товарами - как-то не по феншую. По-хорошему, надо свой компонент мастерить, но у заказчика столько денег нету.