Именно за ним наши сотрудники сделят больше всего (т.к. это новые, непросмотренные обращения).
Когда по багу отвечаем, мы переносим сообщение в нужный подраздел (“Исправленные баги”, “Недостаточно информации”, и т.п.)
В “Исправленные баги” тема попадает после того, как:
Сотрудник поддержки воспроизвёл проблему у себя.
Разработчик проблему исправил.
Тестировщик убедился, что проблема раньше была, а теперь нет.
Исправление попало в одну из будущих версий.
Иногда бывают ситуации, что старую, уже исправленную проблему находят спустя какое-то время в новой версии (т.к. система сложная, и много друг на друга завязано).
Но тогда лучше не воскрешать старую тему, а создать новую. Почему так:
Сотрудники поддержки быстрее увидят тему.
В самой теме не будет путаницы, для какой версии и какой проблемы дали diff-файл.
Ещё кое-какие организационные причины.
Понимаю, звучит как бюрократия Но подходы “Один баг в одной теме” и “Не возвращаться в старые темы, а создавать новые” очень хорошо себя зарекомендовали для баг-репортов.
И даже не открывая тест думаю cs-cart не догадались сделать кнопку конвертировать блок в новый, ведь это очень сложно (нет) в итоге люди сейчас будут мучаться тыкаясь Х тысячи проектов = сотни человека часов, а надо то было всего сделать пару функций.
Спасибо, что оцениваете умственные способности команды CS-Cart, и что мы догадались сделать, а что нет. Это очень конструктивно, важно для текущего обсуждения, хорошо аргументирует вашу позицию и ни капельки не нарушает правила форума (которые мы вам не раз скидывали).
А если серьёзно, то общение в таком тоне на форуме неприемлемо. Надеюсь, абзац выше показал, почему. Но пост я удалять не стал, так как там был резонный вопрос (пусть и сформулированный в недопустимой форме).
Никому мучаться не придётся. Когда мы занимались SMARTY-блоками, то продумывали разные варианты. Был вариант и нажатием кнопки переконвертировать один блок, и при апгрейде все блоки разом. Но в итоге они оказались плохими.
Поясню всю логику принятия решения:
Главное правило, которым руководствовались: “После апгрейда у пользователей ничего сломаться не должно”. Поэтому старые SMARTY-блоки остались, и весь код в них работает без каких-либо дополнительных ограничений.
Если сделать кнопку “Конвертировать блок в новый”, то какой-то код из блока может сломаться.
Если сделать кнопку конвертировать все блоки, то может сломаться “что-то и где-то” — т.е. любой SMARTY-блок в любом месте.
Менять код в старых SMARTY-блоках нужно, только если он вдруг перестал работать из-за каких-то других изменений в CS-Cart. Эта ситуация встречается реже, кнопка тут проблему пользователя всё равно не решит, а ещё есть риск, что код придётся пересматривать (т.к. какие-то функции могут быть недоступны).
Большинство людей с проблемами вообще не столкнутся. А тем, кто столкнётся, не обязательно менять все блоки в своём магазине — возможно, проблема в одном блоке из десятка. Но тогда код в этом блоке придётся менять в любом случае.
Принцип всё тот же: “После обновления пройдитесь по магазину и посмотрите, всё ли работает”. Если всё работает, то и менять никакие блоки пока особого смысла нет.
Потестил мультивендор новую панель. Из багов это только то, что на первых секундах загрузки страницы видны пустые колонки по 3 штуки в ряд а интерфейс пока не до конца соответсвует 1-ой картинке которая сзади или я неверно понял замысел:
то есть блоки аналитики нельзя расположить справа от тех 3—4 блоков гайда для продавца как на 1-ой (они зафиксированы внизу и на широких мониторах пустота по бокам как на 2-ой).
В целом ок но лично мне кажется логично будет если эти 3—4 блока будут уже в свернутом варианте в аккордеоне после того как продавец выполнил какие-то минимальные действия обновления в соответственных разделах то есть например: добавил как минимум лого, добавил товар, добавил метод оплаты соответственно блоку. Для начальной версии проще для разработки будет если блок видео и шагов сделать в аккордеоне по умолчанию раскрытым, но если продавец его свернет вручную то это состояние запоминается в куки и/или в его сессии / БД чтобы на будущее не раздражало.
Мы начали картинки показывать ещё на раннем этапе разработки. У нас было два разных макета. На тот момент ещё не решили, какой оставим.
В итоге остановились на том макете, где сначала идёт целиком секция онбординга, а потом уже аналитика.
Идея с секцией онбординга (“Setup guide” на картинке) такая:
Каждый маркетплейс может настроить её под себя — добавить блоки, отредактировать тексты. Для этого надо из админки через меню профиля в правом верхнем углу зайти от лица любого продавца. В нижней панели тогда появится возможность переключиться на редактирование.
У новых продавцов в аналитике пока нет никакой информации. Поэтому они в первую очередь видят онбординг. И могут скрывать его отдельные пункты вручную, когда их сделают (через многоточие справа сверху).
Когда продавец скроет все шаги, то весь раздел пропадёт и не будет отвлекать от работы с маркетплейсом и аналитикой. Т.е. цель тут была двоякая:
Чтобы продавцы знали, что им нужно сделать — для этого сделали “Setup guide”
Чтобы продавцы это сделали — поэтому “Setup guide” развёрнут и не пропадает, пока продавец не пометит шаг как сделанный.
скрывается где-то 300 пикселей таблицы справа, даже если дисплей очень широкий хотя все остальные лайауты используют всю ширину экрана. Я думаю имеет смысл привести в единый стиль и эту среднюю колонку (Full Width)
Поиск странно работает. В результатах отображается товар где не упоминается ни слова про “Casio” (заголовок / содержимое)
Спасибо! Навскидку выглядит как баг беты 4.16.1. Изучим, и если баг, то постараемся до релиза исправить.
Эта проблема скорее для баг-трекера. Напрямую с 4.16.1 она не связана. Такое же поведение я заметил и в старой версии. Тоже посмотрим, но приоритет у неё будет ниже.
Посмотрели. Поведение действительно такое же, как было раньше. Быстрый поиск умеет искать не только товары, но и страницы, заказы и пользователей (актуально для админки). Также он ориентируется не только на товары, но и на их артикулы, ключевые слова, упоминания в описани, и т.п.
Почему абсурд? ПОСЛЕ обновления возможно юзать 8.1.x а не ДО или ВО ВРЕМЯ обновления. Знак “<” это означает “меньше чем” (например 8.0.27) — в данном случае 8.1.9 > 8.1.0 и по этому выдает ошибку
Меня это радует. Логи ошибок / deprecated нотайсов PHP смотрели? Тестировали функционал отправки емэйлов?
То что у вас CS Cart запускается без явных визуальных ошибок — это еще не означает полную поддержку PHP 8.1. Когда официально задекларируют совместимость — вот тогда будет говорить
@valerios Напишите нам в Help desk. Ребята помогут пропустить проверку версии PHP при обновлении.
Выкладывать инструкцию на форуме не буду, т.к. это не безопасный и не рекомендуемый сценарий обновления.
Basic PHP 8.1 support added; however, it is not yet the recommended PHP version.
Стесняюсь спросить — не рекомендуется потому не тестировали весь функционал или потому что большинство сторонних модулей для CS Cart еще не адаптированы под 8.1?