- 00:32 – сняли ограничение на количество характеристик при импорте;
- 01:19 – доработали Яндекс.Доставку;
- 01:49 – добавили возможность вставлять блоки с товарами в страницы;
- 04:21 – сделали выбор категорий удобнее;
- 07:00 – добавили новые фишки для вариаций товаров;
- 15:56 – доработали новую страницу оформления заказа (простой чекаут);
- 20:09 – нюансы обновления до версии 4.10.1;
- 22:20 – улучшения CS-Cart для маркетплейсов (Multi-Vendor);
- 23:27 – над чем работаем сейчас.
5 лайков
С блоками в тексте - отлично, главное теперь не откладывать, и оформить плагином для редактора кнопочкой в панель для вставки шаблона и выбора нужного блока из списка (тут мне припоминается давнишний разговор о приведении в порядок самого списка блоков, а то там сейчас полная неразбериха)
Про выбор категорий - с коммандом - вставляется выбранная при этом категория, или плюс все выбранные до этого без комманда?
Плюс все выбранные до этого.
1 лайк
Ожидал увидеть нечто иное. А как вложить сниппет карточки товара в статье, в текст, не плодя при этом миллион ненужных блоков в макетах?
Там, кстати, куча серьезных недоработок сильно ограничивающих применение этого модуля. По учету веса и объема товаров(его по сути нет), по учету дополнительных наценок, по выводу элементов на странице чекаута… да много чего не хватает. Причем, судя по коду и комментариям в нем часть функционала в какой-то момент хотели реализовать, но почему-то не доделали. Модуль нуждается в серьезной доработке.
А когда мультисклад будет?
1 лайк
вопрос количества блоков серьезный. Так как при такой схеме надо сначала создать блок, узнать его код, вспомнить шаблон, вставить в него этот код. Каждый такой блок будет использоваться ТОЛЬКО ОДИН РАЗ (нет, можно конечно сколько угодно, но все-таки использование такого блока будет однократное) - потому что невозможно определить разное содержимое блока непосредственно на странице его использования. Далее - удалили код из описания - блок остался. Удалили страницу или товар с таким блоком в описании - блок остался. Его конечно можно теперь использовать в описании другого товара, но вот беда: как определить блок, который нигде не используется? Как результат - список блоков будет обрастать хвостами в геометрической прогрессии.
Надо что-то придумывать с блоками… как в них разобраться…
3 лайка
Подумал, как это всё копирайтеру передать, что статьи писать будет… Да никак. Еще и шаблон для этого блока делать надо самостоятельно. Функционал можно считать просто отсутствующим, текущее решение - не решение, а какой-то нелепый не работающий костыль.
2 лайка
Надо выносить товары к статье в отдельный тред) механика всем юзерам предельно понятна, вопрос в реализации со стороны разработчиков.
Это должно быть максимально просто и завязано на product_id=***, напихал 3-6 product_id=807 в определенной обертке (div не див, я не шибко силен в коде) - получил результат @imac @yakulakov
А в будущем как сказал @alex_vp нужно так же из редактора статей по кнопке получить список товаров, отметить товары или категорию целиком и что бы она легко вставлялась в статью
2 лайка
Да, тут думается надо выделить такие блоки в отдельную ветку. Например, по кнопке в редакторе всплывает все то же стандартное окно создания блока, блок настраивается по виду и заполнению, и по сохранении в редактор вставляется код для его отображения, а сам блок в базе например помечается как виртуальный, то есть он есть, но в списке блоков не отображается. В окне редактора такой блок тоже должен как-то обозначаться, чтобы его можно было выбрать и повторным кликом ко кнопке убрать этот блок из текста и удалить из базы (чтобы база не разрасталась хвостами неиспользуемыми)
1 лайк
Что понравилось что есть управление блоками на клиентской части - это удобно.
Также согласен с тем что поля профиля для чекаута и поля профиля для клиента должны быть одни, чтобы управлять ими из одного места, также если возможно нужно в дальнейшем доработать чтобы для разных способов доставки можно было указывать какие поля не выводить - не только адрес.
Хорошо что теперь есть управление главной вариацией - это упростит работу с ними.
Что касается изображений и характеристик для вариаций я думаю вы опять бросаете себе грабли под ноги делая выбор или / или
Так как группы товаров в одном магазине могут различаться и может быть такая ситуация что для одних товаров нужны картинки и характеристики свои, а для других нет и поэтому правильно было бы сделать, чтобы в настройках категорий либо отдельных товаров можно было выбирать эти параметры для настройки, также как у вас реализованы например вкладки - для всех товаров включены, но в определенном товаре можно выключить, идеально было бы чтобы возможно было выключать и для товара, и категории.
Также только сегодня обратил внимание, что в чекауте все выглядит как-то одинаково, что поле для ввода данных, что кнопка выбора, и если много вариантов доставки и оплаты то это не очень смотрится в плане понимания. На мой взгляд нужно в дальнейшем в плане дизайна отделить одно от другого либо формой, либо толщиной линий, либо объемом, согласен что это вопрос больше к доработке, но все же многие будут использовать базовый дизайн.
Также радует что вы начали работу над блогом, я считаю это очень важный элемент в интернет-магазине и что касается добавления думаю нужно разработать несколько типовых блоков для вставки в статью с возможностью выбора внутри блока определеных товаров. Например блок один товар с возможностью выбора внутри блока определенного товара для отображения в статье
блок группа товаров (новинки, акция, со скидками, категория, подкатегория) либо просто список выбранных для отображения товаров и потом в статью просто добавлять этот блок а чтобы не было путаницы о которой говорит @alex_vp присваивать блоку имя статьи и чтобы если удаляется статья блок/и автоматически удалялся вместе с ней. Также в блоге не хватает разделов и категорий для статей а не просто списка статей.
Ждем от вас также мультисклад, полнофункционального модуля для CRM RetailCRM 1С и изменений в личном кабинете покупателя, развития в функционале акций и скидок, отзывов с возможностью ответа и добавления фото и видео.
3 лайка
Полностью поддерживаю. Эти настройки сейчас вынесены на слишком глобальный уровень - уровень настройки модуля.
2 лайка
Поддерживаю. Я, к примеру, хотел бы предложить покупателю выбор времени и даты доставки при курьерской доставке по Москве. Но эти поля нужно скрывать для всех остальных способов доставки.
2 лайка
@imac , вопрос как раз по радиаторам))) У меня в магазине отопление и в нем не только радиаторы. Если для радиаторов можно задать одно фото для всех размеров, то например у полотенцесушителей одно фото ну никак не подойдет на высоту 50 см и 180 см, как вы понимаете разница огромная. На форуме мы кажется обсуждали возможность наследования картинок для каждого товара индивидуально, а не глобально. Потому что нынешняя реализация это скорее “вот вам и отстаньте от нас” или для “магазина одного товара”, а для мультитоваров подразумевает очередные костыли.
По товарным блокам в статье:
Что бы не городить огромное количество блоков в макете, которые потом будут выводиться в статье, правильнее будет сделать это через отдельную вкладку на странице редактирования статьи (возможно реализовать отдельным модулем).
На этой вкладке создается набор из товаров, которому присваивается свой id. По идее можно не ограничиваться только одним набором, а дать возможность создавать несколько, чтобы потом выводить их в статье в разных местах.
В тексте статьи втавлять шорткод с id набора, который будет на фронтенде выводить блок с выбраными товарами. + если делать отдельным модулем, можно будет свои стили прописывать для отображения этих блоков.
1 лайк
Да, и еще, по блокам в редакторе. Хорошо бы иметь возможность автособирать товары в такой блок по тегам, в наличии/все, количество товаров в блоке. Потому что та же статья в блоге - она навечно, а товары имеют свойство заканчиваться, а новые товары - появляться. Поэтому при заполнении вручную через какое то время товарный блок в статье или в описании будет заполнен отсутствующими товарами. А при массовом использовании такого функционала отследить такие вещи невозможно. Но можно выбрать товары, проставить тэги определенноименованные, а в блоке поставить отбор по этому тэгу. Ну или скрытую характеристику какую…
4 лайка
Хорошие предложения. Но пока хотя бы начать с того, чтобы в код текстового поля можно было бы вставлять что-то типа {product.id=123} для вывода в это место предопределенного div с названием, фотографией и ценой товара.
1 лайк
напомню еще раз, или мы тут по вашему бред пишем?
Привет, рад что вставка блоков с товарами вызвала такую активность. Сначала поясню почему приняли такое решение потом немного отвечу на комментарии.
Мы выбрали использование блоков, так как это основный инструмент в CS-Cart для отображения любых объектов. На базе блоков работает все: товары, категории, страницы и прочее. Создание еще одной сущности значительно урежет функциональность вставки товаров а так же усложнит жизнь владельцам магазинов и разработчикам.
Вот плюсы которые дает использование блоков:
- врапер для продуктов (колонки, строки, отображение кнопок “добавить в корзину”, многое другое)
- дополнительные стили (есть интерфейс для добавления своих стилей, без необходимости плодить свои smarty шаблоны, как то через код навешивать классы)
- потенциальный механизм импорта (у нас есть импорт/экспорт layouts который может использоваться для переноса, сохранения таких блоков)
- актуальный контент (Использование всех стандартных списков продуктов таких как bestselling, popular и т.д. если вы выключите находящийся в блоке то он не будет отображаться, в противном случае клиент при переходе по ссылке получит 404 и штраф от Google/Yandex прилетит)
Комментарии
Миллион ненужных блоков нужен, потому что это стандарт того как мы выводим любой контент на витрину
Это больше к вопросу об удобстве работы с блоками на макетах. Мы уже столкнулись с этой проблемой на чекауте. Название блоков плохо-читаемое, есть сложности с выбором существующих блоков.
Т.е. это проблема управления блоками, а не проблема того что продукты не должны вставляться в страницы через блоки.
Опять же вопрос к интерфейсу управления блоками. Но! повторюсь еще раз, это вовсе не повод создавать еще одну сущность схожую с блоками, но по факту выполняющую те же задачи.
Я обещал сделать протип . Я его сделал. Видимо вам такая реализация не подходит, спасибо за обратную связь. Почему именно так сделали - я отписал в начале сообщения.
Нельзя так делать, потому что появятся вопросы, как сделать товары списком, как добавить кнопку купить и прочее - для всего этого и созданы блоки и успешно эту задачу решают испокон веков. Просто представьте что мы веведем товары в красной рамки, с маленькими иконками товаров, у вас тема своя - и какой вам от этого отображения товаров смысл, если он всю визуальную составляющую сайта ломает. А чтобы отображаться так же как в теме - нужны блоки. Опять же вопрос расширения - захотите вы как то по особому выводить эти продукты - пишется один темлпейт и все работает.
Планов по улучшения блога нет. Есть только одна конкретная фишка - вставка товаров
Потенциально да, но это ведет к проблемам. Например у нас на деталке товарв можно создать блок с товарами в котором руками добавить нужные, которые будут отображаться только у данного товара. Этих данных нигде нет, и нельзя их экспортировать, только полный бекап магазина. К тому же нет возможности посмотреть все товары которые у вас используются на разных деталках товара, а это может потребоваться так как товары устаревают, снимаются с производства, заканчиваются на складе и т.д. Поэтому я считаю что лучше если будет централизованный механизм управления всем этим добром.
Это вы уже будет использовать сущетсвующий функионал bestsellting, recently added, распродажа, категории, и прочее либо допиливать модули который по каким то критериям будут автоматически отбирать товары. Моя задача дать инструмент, который потенциально можно расширить.
1 лайк
А возможно так сделать, чтобы в коде текстового поля писать что-то типа {unit=xx | product=yy} и вставлялся блок хх, в котором отображается товар yy?
А зачем?
Если будет вставка обычно блока в котором указаны эти продукты?
Чтобы товары не в блок засовывать, а использовать многократно один и тот же блок, но с разными товарами. Чтобы пользоваться можно было. Иначе слишком сложно получается.
1 лайк