Пишу в Как улучшить… , так как вы не хотите соглашаться с тем, что баг отсутствия логики - это еще более страшный баг, чем перепутанный плюс с минусом в программном коде.
Обновление модулей…
Вот у нас есть раздел Модули - Управление модулями. Что он делает? На что он способен? Установить модуль, удалить модуль. А, ну да, долгими стараниями научили обновлять языковые переменные из var/lang. И то, если ты понимаешь, как включить режим разработчика.
Мне надо обновить 15 модулей.
Так вот если архив модуля сделан по правилам, то все, что касается design/thems/responsive - в архиве лежит в var/thems_repository, и хоть убейся ты, но без удаления модуля, со всеми настройками, созданными блоками, прикрепленными файлами итд - не выйдет нормально обновить полностью модуль. Сделаешь ли ты просто накат файлов из архива на сайт, или через установку модуля из пакета без удаления - файлы в design/thems/responsive останутся ОТ ПРЕДЫДУЩЕЙ ВЕРСИИ модуля, в то время как все остальные файлы - ОТ ОБНОВЛЕННОЙ.
Сейчас кто как извращается для того, чтобы обновить модуль. Кто-то идет в addon.xml установленной версии модуля и комментирует инструкции удаления записей из БД, а в устанавливаемой новой версии - комментирует пересоздание таблиц.
Кто-то бэкапит затрагиваемые таблицы и потом восстанавливает их.
Кто-то еще как извращается через одно всем известное место.
Я еще никогда вас этого не спрашивал, но… ВЫ ЭТО СЕРЬЕЗНО?
Я понимаю, что сторонние модули это вообще не ваша дело, типа это не нашего поля ягода, вы с ними разбирайтесь…
Вот только ядро должно регулировать и жестко устанавливать происходящие в нем процессы, а не позволять сторонним разработкам вести себя как угодно.
Или может вы подскажете простой способ обновления модуля без потери наработанных данных и настроек, на запоминание которых и заведение обратно в базу потратиться нехилое количество времени?
Честно, нигде такого обновления модулей не встречал.
Полностью поддерживаю. Просто убивают рекомендации по обновлению в стиле “просто удалите и установите заново”. Это издевательство! В полях от этого модуля в БД зачастую лежат СОТНИ человекочасов работ. И никогда не знаешь, удаляет конкретный модуль за собой поля или нет. При этом нельзя просто перенести наработки с тестовой версии на боевую, когда изменения хранятся во множестве макетов, настройках блоках, настройках самого модуля и произвольных местах, где данный модуль применяется к каким-то изменяемым им объектам.
Такая же беда и приходится очень осторожно быть с этою бедою. Каждое обновление - печаль.
@imac, @ikoshkin, @cs-cart_team, за вечер тема набрала 10 лайков, думаю, это показатель того, что вопрос, поднятый в теме, беспокоит многих. Ситуация же, когда наступает пора обновлять что-либо, ты с опаской делаешь каждый шаг, как по минному полю, и по завершении, если ВРОДЕ все нормально работает - делаешь громкий УФФФ облегчения - вот не дадут мне соврать - знакома почти всем (счастливы те, кто живет на чистом немодифицированном респонсиве без сторонних тем и модулей).
Теперь отступим от лирики. Я наверное все-таки зря не запостил тему в баг-трекер. Давайте разберем ситуацию. У меня есть установленный модуль. А также у меня есть пакет этого модуля в новой версии. Я иду в модули - управление модулями. Жму плюс, выбираю этот пакет, жму Загрузить и установить. CS-Cart его загружает и устанавливает.
То есть, по логике, он должен УСТАНОВИТЬ НОВУЮ ВЕРСИЮ. А по факту - ТОЛЬКО ЗАГРУЖАЕТ файлы из пакета по своим местам. В результате имеет место та самая ситуация, когда часть файлов от новой версии, потому что они были перезаписаны из загруженного пакета (из директории app), а часть из design - от старой версии , потому что процедуры установки и расстановки файлов из thems_repository - не было.
Если я могу произвести это действие, и оно приводит к подобной “анархии” - это баг однозначно.
Я понимаю, что между версиями модуля могут произойти изменения как в файлах модуля (не только добавиться новые, но и удалиться предыдущие), так и в таблицах БД - измениться структура таблиц модуля, или добавленные поля в другие таблицы. Ну так волевым решением - обязуйте разработчиков модулей включать в пакеты файлы миграций, при отсутствии которых ядро будет просто отклонять установку.
Запустите систему уведомлений о новых версиях модулей, разработчики сами будут рады к ней подключиться, чтобы не копить в пакетах миграции со всех предыдущих версий, а только от последней к текущей.
Вообщем, пора уже с этим что-то решать, как вы думаете?
Поддерживаю автора темы! Уже зубы сводит проблема обновления модулей. 
Еще дополнение, что происходит в Управлении модулями
Удаление модуля - НЕ УДАЛЯЕТ файлы шаблонов модуля из design/thems/responsive которые были помещены туда из thems_repository
то есть я решил на тестовой - давай попробую удалить модуль, а после этого уже установить - посмотрю сколько времени у меня займет перезабить вручную снова все данные, начну хотя бы, примерно потери оценю.
И что вижу?
тут вроде бы вообще комментарии излишни, да? Захотел сделать по правильному, удалил модуль, и только потом снова его установил. И в итоге получил такие коллизии в шаблонах
Я не пользователь юнитемы, но форум читаю, и насколько были правы АБ, когда в своих инструкциях писали именно про ФИЗИЧЕСКОЕ УДАЛЕНИЕ файлов старых версий из файловой системы, когда шуруешь по папкам магазина и вручную вычищаешь всю предыдущую установку модуля.
Это обязательно, удалять папки, иначе файлы старой версии попадают в новую инсталляцию (мы мучились с поддержкой таких вопросов, пользователи не читают инструкций)
Но с новыми версиями (да, это ад, мы два месяца все переделываем) перешли на обновления через Центр обновлений самого CS-Cart, теперь не будет таких проблем у пользователей и проблемы, собственно, там нет никакой использовать прямые обновления (мы даже темы теперь обновляем через эти процедуры).
То есть, на сегодня весь инструментарий для разработчика есть в платформе для того, чтобы обеспечить комфортную жизнь пользователю (вопрос желания разработчика и его ресурсов, так как собрать обновление это не то, что поправить код и отдать его пользователю в новой сборке - это в несколько раз ответственнее и больше по ресурсам).
Да, с вашими обновлениями теперь просто радость работать, есть пока пара ваших модулей, уже прочувствовал, вы молодцы однозначно!
Вот тут детально написано как нужно обновлять модули, способ не то чтобы “простой” но правильный FAQ: Как отдавать обновления модулей через Центр обновлений — Документация docs.cs-cart.ru 4.18.x
Разработчиков будем постепенно перетаскивать на правильную систему обновлений. AB молодцы и уже переехали.
Надо понимать что просто так никто не будет внедрять новые более сложные процессы за просто так. Т.е. либо цена будет выше, либо должен быть аргумент почему это должно быть сделано. Аргумент “удобство пользователей” работает не всегда, до тех пор пока продажи не падают. В плане аргумента мы активно работаем над маркетплейсом - в планах запуск продаж модулей через него.
Вы дали ссылку на “FAQ: Как отдавать обновления модулей через Центр обновлений” - это для разработчиков
Хотя сейчас ваш клиент, чтобы смог обновить модули - должен быть в достаточной мере разработчиком.
Вы из написанного много упустили.
Вы сейчас расписываетесь в том, что не можете взять на себя централизованное управление, влиять на партнеров и устанавливать свои правила? От этого зависит лояльность ваших пользователей, и подобные мытарства из-за того, что авторизованные вами разработчики не желают работать по вашим правилам - отнюдь не работает на вашу карму.
Я легко переключусь с вами на официальной язык, но пользы от этого никому не будет.
Я нигде не написал что не можем, я написал вам про текущие положение дел, и что мы планируем делать чтобы его улучшить.
Вот только ядро должно регулировать и жестко устанавливать происходящие в нем процессы, а не позволять сторонним разработкам вести себя как угодно.
Вы дали ссылку на “FAQ: Как отдавать обновления модулей через Центр обновлений” - это для разработчиков
Вы противоречите себе.
Я как пользователь, полагаю, что Вы дали мне ссылку на то, как мне, как пользователю, надо не то чтобы “просто”, но правильно обновить магазин. О чем я собственно в первом посте попросил.
Далее я вам показал, что даже Удаление модуля - не работает до конца - это вы пропустили.
Я надеялся на конструктивный разговор, а Вы снова встаете в позу…
Вы еще в ноябре хотели подумать, но было не до того.
И стоит наверное обратить внимание на количество лайков темы - это реально говорит о том, что ваши пользователи - мучаются каждый раз когда подходит пора что-то обновлять.
Давайте конструктивно.
Процесс миграции но новую систему трудоемкий, так как завязан на внешних разработчиков, поэтому быстро такое не делается. В качестве результата на текущий момент вы можете видеть изменения в формате распространения у AlexBranding.
Мы работаем в этом направлении.
Что касается удаления модулей и проблемы с удалением всех файлов, недавно на нее наткнулись, пришла обратная связь от разработчиков. Исправим в 4.11. В 4.10.3 к сожалению включить не можем, неизвестно пользовался ли кот то этим багом как фиче или нет.
Уже хорошая новость!
Со стороны разработчиков модулей странно было бы пользоваться этим как фичей. А вот допустим что-то вроде “Удалить модуль без удаления данных”, когда затрагивается именно удаление из файловой системы и оставляются на месте данные наработанные с модулем - уже было бы подспорьем при том же обновлении модулей.
А сейчас происходит как раз наоборот - удаляем модуль - удаляются данные из БД, а вот файлы - нет.
Мультисклад? 
Ну почему для разработчиков? Пользователь, зная, что есть удобный механизм обновления модулей, который описан по этой ссылке, может у каждого разработчика интересоваться перед покупкой, поддерживает ли модуль такой механизм обновления.
Хорошо бы в пользовательскую часть документации о модулях добавить информацию о том, что модули обновляются по-разному и надо изучить этот вопрос перед покупкой модуля.
Было бы здорово, если бы в маркетплейсе добавили опцию поиска, чтобы клиенты могли такие модули найти, а нам был смысл переходить на эту систему. Мы убили много времени на перевод одного модуля на эту систему обновлений, это стоит денег разработчиков. Разработчиков тоже надо заинтересовать в этом, чтобы росло качество решений, так как сейчас там действительно куча откровенно кривых поделок.
Абсолютно согласен, если разработчикам будет бонус хотя бы в виде такого выделения из общей массы - уже какой-никакой стимул. Потому что мне, как в данном случае пользователю, понятно, если разработчик пошел на такие затраты, что внедрил эту систему - во первых - это повышает его статус и серьезность его работы в моих глазах, а во-вторых - дает понять, что настолько вложившись, завтра модуль не окажется заброшенным и необновляемым, так как работа должна окупиться (опять кстати же - в наколенную поделку так вкладываться не будут, посему - фактор доверия).
Хочу отметить, что по инструкции должен быть сервер лицензирования (либо свой либо использовать маркетплэйс). Но на маркете можно раздавать только обновления бесплатных модулей. Если модуль платный то нужно разработать и внедрить еще свой сервер лицензирования. Так что только подготовкой обновлений не обойтись. Поднимал вопрос на счет реализации на маркете покупки и раздачи обновлений для платных модулей - как всегда сроки не известны. Может сейчас, когда уже выпущены оформление заказа и вариации, приоритет маркета станет немного выше…
Вот полностью соглашусь. Допустим я разработчик. Разрабатываю модули для разных движков (на одном не проживешь понятно). Пусть я даже хороший разработчик. Где ищут клиенты платформ модули? Правильно, на соответствующих страницах сайтов платформ (маркетплейсах итп). Так я же ХОРОШИЙ разработчик, мне бы программировать и программировать, да размещать свои работы, общаться с клиентами и осуществлять обновления и поддержку. Кстати, через тот же интерфейс маркетплейса. А меня заставляют делать сайт, настраивать какие-то сервера, еще что-то… Оно мне надо? Конечно, я буду здесь выкладывать в том виде в каком можно чтобы без заморочек, а запретят и не дадут альтернативы - уйду туда где всё давным-давно и просто организовано.
Так что надеемся, надеемся, тем более что вроде как и мультисклад уже готовы выпустить, обещались…