Мне идея выпускать раз в месяц нравится, точнее мы если и будем так делать то привяжемся к неделям, т.е. раз в 4 недели.
Вопрос к другим пользователям, Насколько будет устраивать такой подход к релизам (релиз каждые 4 недели)?
Все таки предсказуемость снимает часть проблем - когда точно знаешь что вот через 3 недели будет релиз.
Лучшее - враг хорошего. Если есть необходимость, нужно выпускать раз в 4 недели, но не чаще. Это и так 13 обновлений в год. С другой стороны - можно выпускать отдельно обновления, отдельно сервис-паки, т.к. по отдельности раз в 8 недель.
Можно следовать следующему примеру. Есть глобальная версия, сейчас 4-я, ее смена должна характеризовать действительно серьезные изменения (мажорные). Раз в 2 года.
Есть минорные версии, сейчас 4.6, тут уже глобальные правки багов, оптимизация кода и улучшение стабильности, изменения в API других разработчиков, расширение локального функционала, изменение законодательства и пр. Тут квартально или раз в полугодие.
Третий уровень, это уже Service Pаck, сейчас 4.6.3. - Тут бакфиксы и мелкая оптимизация.
Если у меня будет версия, например 4.6.3, и все работает нормально, то все SP до 4.7., я могу пропустить, а потом накатить накопительный пакет с 4.6.4 ... 4.6.n внутри, который войдет в 4.7.
Меньше трогаешь, когда работает, работает лучше и стабильнее.
Причем любые критические баги должны обновляться на любых версиях даже, если нет подписки на обновления.
Установка чистая. В разделе "Редактирование способа оплаты :Выставить счет" вкладка "Настроить" указал все данные (инн, кпп и т.д. и т.п.) нажал сохранить. После сохранения при повторном заходе получилось следующее (во вкладке настройка все пропало) http://s1.radikale.ru/uploads/2017/11/3/750110357131089cef58abb5e31740f3-full.png
Кэш чистил. пробовал разные браузеры, разные компьютеры. В чем может быть дело? Спасибо.
А при обновлении с 4.6.2 на 4.6.3 вижу вот такую картину https://prnt.sc/h5803g И обновление не идет.
Вопрос решил через службу поддержки CS-Cart.
Скорее всего, была проблема с настройками SMTP сервера на странице Настройки > Электронная почта. Я выбрала вариант С помощью PHP mail на этой странице и успешно обновила Ваш магазин. Пожалуйста, проверьте
Приносим извинения за ошибку. Специалист тех. поддержки нашел уже исправленные баги вызывающие схожие проблемы, но как оказалось проблемы из вашего обращения с ними не связаны. Задачи по описанными вами проблемам в работе. Подробнее ответили в вашем тикете в Help desk.
Какая разница, раз в неделю или раз в месяц. Если баги не правятся даже раз в месяц не вводятся.
Мной были обнаружены два бага в работе с вариациями. Я написал в сапорт.
1. ID: #101700308
2. ID: #101707138
Мне ответили, что это баг и в след. обновлении все будет исправлено. Ждал обновления, дождался, обновился. И баги как были так и остались.
Теперь мне пишут что решение по данным багам еще нет, как только проблема будет решена, мы вам сообщим.
Как то это не профессионально... Прошу дать ответ. Ждать еще 1-2 месяца обновления нет желания.
Если вкратце, то проблема в следующем.
1. Пропадают вкладки товара при выборе вариации какой то.
2. Не меняются характеристики вариации во вкладке товара "Похожие товары"
Мне идея выпускать раз в месяц нравится, точнее мы если и будем так делать то привяжемся к неделям, т.е. раз в 4 недели.
Вопрос к другим пользователям, Насколько будет устраивать такой подход к релизам (релиз каждые 4 недели)?
Все таки предсказуемость снимает часть проблем - когда точно знаешь что вот через 3 недели будет релиз.
Очень устраивает.
По версиям релизов пожелание...
Плановые, 4х недельные релизы обозначать спец.признаком. Называть их сервис-паками, например 4.6.3 SP1, 4.6.3 SP2 и т.д.
Или еще один разряд добавить в версию, например 4.6.3.1, 4.6.3.2 и т.п. Или спец.разделитель, например 4.6.3_1, 4.6.3_2 и т.п.
Чтобы не задохнуться в плановых версиях. Отличать их от концептуальных..
1) Если товар имеет опции, но не сгенерированны вариации, то он числится как "нет в наличии".
2) Если у товара с вариациями стоит не "не отслеживать кол-во", а у вариации стоит кол-во к примеру "1 шт", то больше чем одна штука в корзину положить нельзя"
Ну и самое печальное - при создании новой опции, вариации необходимо сгенерировать по новой, а все существующие стираются. ЭТО полная ФИГНЯ, БРЕД, ХРЕНЬ...!!! Как можно предусмотреть появление новых вариаций у товара? Например производитель выпускает к товару новый размер, так что теперь стереть все вариации и сгенерировать по новой, по новой добавить фото и характеристики, а если таких вариаций у товара 23 шт, то это все превращается в пустую трату времени и денег!
По версиям релизов пожелание...
Плановые, 4х недельные релизы обозначать спец.признаком. Называть их сервис-паками, например 4.6.3 SP1, 4.6.3 SP2 и т.д.
Или еще один разряд добавить в версию, например 4.6.3.1, 4.6.3.2 и т.п. Или спец.разделитель, например 4.6.3_1, 4.6.3_2 и т.п.
Чтобы не задохнуться в плановых версиях. Отличать их от концептуальных..
Мы используем семантическое версионирование.
версия их трех цифр: A.B.C
C - патч релиз, это багофиксы
B - минорный релиз, это новые фишки но с поддержкой обратной совместимости
A - мажорный релиз, новые фишки и сломанная обратная совместимость. (т.е. модули работать не будут, либо все либо частично)
1) Если товар имеет опции, но не сгенерированны вариации, то он числится как "нет в наличии".
2) Если у товара с вариациями стоит не "не отслеживать кол-во", а у вариации стоит кол-во к примеру "1 шт", то больше чем одна штука в корзину положить нельзя"
Ну и самое печальное - при создании новой опции, вариации необходимо сгенерировать по новой, а все существующие стираются. ЭТО полная ФИГНЯ, БРЕД, ХРЕНЬ...!!! Как можно предусмотреть появление новых вариаций у товара? Например производитель выпускает к товару новый размер, так что теперь стереть все вариации и сгенерировать по новой, по новой добавить фото и характеристики, а если таких вариаций у товара 23 шт, то это все превращается в пустую трату времени и денег!
Отсутствие возможности управлять вариациями мы поправим в скором времени. Спасибо за комментарий.
По возможности давайте обходится без капслока и жирного шрифта и придерживаться более конструктивного формата.
А зачем вы создали настраиваемый товар без вариаций?
Я думал что мне нужен товар с вариациями, но потом я понял, что мне подойдет больше товар лишь с опциями, так как вариаций не много. И получается след.
1. Надо создать товар по новому, (затраты времени)
2. Надо через базу данных убивать уже присвоенный url, чтобы новый товар создать под таким же именем. А это затраты времени, лишний раз лезть в базу данных и другое.
Поэтому хотелось бы, чтобы настраиваемый товар также работал как простой, только с опциями.
Я думал что мне нужен товар с вариациями, но потом я понял, что мне подойдет больше товар лишь с опциями, так как вариаций не много. И получается след.
1. Надо создать товар по новому, (затраты времени)
2. Надо через базу данных убивать уже присвоенный url, чтобы новый товар создать под таким же именем. А это затраты времени, лишний раз лезть в базу данных и другое.
Поэтому хотелось бы, чтобы настраиваемый товар также работал как простой, только с опциями.
Я если честно запутался в вашем сообщении.
- вне зависимости от количества комбинации или вариации - они используются просто для разных ситуации. Если у вас у каждого набора опции свое количество, картинки то вам скорее всего нужны вариации.
Т.е. вариации отлично подходят например для продажи одежды (разных размеров и цветов)
А комбинации отлично подходят например для букетов цветов.
Надо через базу данных убивать уже присвоенный url
ни у комбинации ни у вариации нет своего URL.
1. Надо создать товар по новому, (затраты времени)
если речь идет про вариации, то в предыдущем сообщении ответил, что с ближайшее время добавим возможность.
Так вот неудобняк. Необходимо создавать по новому этот товар, так как цена не тянется на основании опций.
1. Надо через базу данных убивать уже присвоенный url
Я имею ввиду не опции и не вариации, а сам товар. Так как урл будет создаваться с приставкой "-ru"
Тоесть, логично, если и в настраиваемом товаре можно формировать цену на основе "опций". Не комбинаций, а просто опций. Как в простом товаре.
Понял вас,
Что касается, URL
В этом направлении не думаю что нужно что то делать. Это разовая операция, когда вы только определяетесь какой тип товара вам нужен и изучаете логику работу. После того как вы поняли что вам не нужны вариации их нужно удалить и тогда URL освободится.
Что касается цены в вариациях, то изменять цену модифаерами можно, но только не от тех опций на основе которых создана вариация. Это логично но я не рекомендую это использовать, так как это приведет к сложностям например при import/export. Это одна из важных фишек вариаций - возможность задавать финальную цену для все вариации.
В этом направлении не думаю что нужно что то делать. Это разовая операция, когда вы только определяетесь какой тип товара вам нужен и изучаете логику работу. После того как вы поняли что вам не нужны вариации их нужно удалить и тогда URL освободится.
Что касается цены в вариациях, то изменять цену модифаерами можно, но только не от тех опций на основе которых создана вариация. Это логично но я не рекомендую это использовать, так как это приведет к сложностям например при import/export. Это одна из важных фишек вариаций - возможность задавать финальную цену для все вариации.
Вопрос в том, почему в єтом товаре не формируется цена модификаторами, как в простом товаре?
Вы возможно ответите, что данный товар этого не предполагает, но как по мне, если это сделать не проблематично, то данный товар также должен уметь формировать цену модификаторами..
