Последние сообщения

Вероятность блокировки конкретно Вашего VPN, размещенного за границей, далеко не нулевая (у нас любят блокировать целыми сегментами), равно как и возможные проблемы на РУ-хостинге с серверами в Европе (пример дата-центра Яндекса в Финляндии, если не ошибаюсь, довольно показателен, пусть это и не хостинг). Есть и вероятность, что DO или другая компания решит, что им просто не нужны клиенты из РФ и разорвет договора. На всякий случай напомню, текущая ситуация определенно подпадает под определение форс-мажора.

Боюсь, что сейчас выбор правильного решения сродни игре в лотерею, все варианты могут обернуться потерей доступа и соответственно денег.

То есть как понял вместо вариаций используется привязка аналогов/сопутствующих товаров к основной карточке.

— Каждая модификация — отдельный товар (например, «Футболка (синяя, XL)» и «Футболка (черная, M)» — это две разные карточки).

— Связь через артикулы или ID (например, в поле «Сопутствующие товары» или через ручное/API-сопоставление).

Все верно понял? 

Руслан Козырев

Да Вы все верно поняли, можно отключить вариации в настройках товаров (если возможно) или просто не использовать этот функционал.

Создавать товары по отдельности, но с одинаковыми:

— Названием (с уточнением параметра, например, «Футболка [Черная, XL]»).

— Группировочным артикулом (например, основной артикул + постфикс _XL, _BLACK).

— Связать их через «Сопутствующие товары» или через ручное сопоставление.

— Настроить выгрузку так, чтобы маркетплейсы воспринимали их как модификации (например, через общий «Групповой идентификатор» в Ozon или «Родительский артикул» в WB).

Плюсы такого подхода

— Проще выгружать и обновлять (каждый товар — отдельная строка в CSV/XLSX).

— Гибкость — можно легко добавить новый цвет/размер без переделки всей вариативной карточки.

— Совместимость с Ozon/WB, где такой формат используется как стандартный. 

То есть как понял вместо вариаций используется привязка аналогов/сопутствующих товаров к основной карточке.

— Каждая модификация — отдельный товар (например, «Футболка (синяя, XL)» и «Футболка (черная, M)» — это две разные карточки).

— Связь через артикулы или ID (например, в поле «Сопутствующие товары» или через ручное/API-сопоставление).

Все верно понял? 

Нет вариации останутся и все ваши вариативные товары тоже, просто расшириться функционал и вы сами сможете выбирать как добавлять и с чем работать дальше. 

Спасибо за ответ Артем, так вариации пропадут в таком случае или нет? 

Так что думаете, стоит ли уходить от вариаций, читал где-то на форуме что в новом обновлении такое будет реализовано, стоит ли вообще отказываться от вариаций и вообще насколько это повлияет на уже добавленные, вариативные товары? 

Северсталь

Ну тут вопрос очень спорный, не всем нужно уйти от вариаций, тут слишком много моментов чтоб так однозначно заявить что вариаций не нужны и нужны только сопутствующие товары. В ближайших обновлениях все верно ожидается данная функция но она будет внедрена без ущерба вариациям, а просто как дополнение т.е. проще говоря в карточке товара появиться новая, дополнительная функция в которой можно будет добавить сопутствующие товары. Это позволит решить задачу гибко и вы уже сами будете выбирать что использовать вариации или сопутствующие товары. 

Так что думаете, стоит ли уходить от вариаций, читал где-то на форуме что в новом обновлении такое будет реализовано, стоит ли вообще отказываться от вариаций и вообще насколько это повлияет на уже добавленные, вариативные товары? 

Проблема вариативных товаров

— Вариативные товары (например, разные цвета, размеры) могут усложнять выгрузку (импорт/экспорт) из-за особенностей структуры данных.

— Платформы, такие как Ozon и Wildberries, используют другой подход — привязку аналогов/сопутствующих товаров к основной карточке.

Решение: отказ от вариаций в пользу сопутствующих товаров

Вместо создания сложных вариативных карточек, товары добавляются как отдельные позиции, но связываются между собой (например, один товар — одна модификация).

Это делает выгрузку проще и гибче, так как:

— Нет проблем с обработкой вариаций в CSV/XLSX-файлах.

— Легче добавлять новые модификации без перестройки всей структуры.

— Упрощается синхронизация с маркетплейсами.

Техническая реализация в DST Marketplace

— Можно настроить ассоциации товаров (например, через артикулы или ID).

— Можно отключить стандартные вариации и перевести товары в плоский список.

— Возможные API-методы или CSV-шаблоны для такой выгрузки.

Преимущества подхода

— Упрощение работы с каталогом (меньше ошибок при загрузке).

— Гибкость (можно легко добавлять новые характеристики без пересоздания вариаций).

— Совместимость с маркетплейсами, которые лучше работают с «плоскими» товарами.

Действительно, подход DST Platform к системе обновлений существенно отличается от большинства популярных CMS и других систем. Давайте рассмотрим, в чём заключается эта разница и почему такой подход может быть более эффективным.

В системах вроде 1C-Bitrix, WordPress или CS-Cart используется единый механизм автоматического обновления, который часто приводит к проблемам. Когда система автоматически обновляет все компоненты, включая те, которые были модифицированы под конкретные задачи бизнеса, это может вызвать:

— Потерю важных пользовательских доработок

— Конфликты между стандартными и модифицированными файлами

— Сбои в работе системы после обновления

— Необходимость повторного внесения изменений

Подход DST Platform предлагает более продуманное решение

Разделение на два типа обновлений позволяет минимизировать риски и обеспечить безопасность системы. Автоматическое обновление ядра системы не затрагивает пользовательские модификации, что гарантирует стабильность работы. При этом ручное обновление остальных компонентов даёт возможность:

— Контролировать процесс внесения изменений

— Сохранять важные доработки

— Тестировать новые версии перед внедрением

— Избегать критических ошибок

Такой подход имеет ряд существенных преимуществ

Во-первых, он обеспечивает баланс между удобством использования и безопасностью системы. Разработчики и администраторы получают полный контроль над процессом обновления тех компонентов, которые были изменены под конкретные задачи.

Во-вторых, разделение обновлений позволяет

— Сохранять целостность пользовательских доработок

— Избегать непредвиденных сбоев

— Обеспечивать стабильную работу системы

— Контролировать процесс внедрения новых функций

Сравнение с другими системами показывает, что подход DST Platform более продуман и ориентирован на потребности бизнеса. В то время как популярные CMS часто предлагают универсальный механизм автоматического обновления, который может привести к потере важных изменений, DST Platform предлагает:

— Гибкость в управлении процессом обновления

— Безопасность пользовательских доработок

— Возможность плавного перехода на новые версии

— Контроль над критическими изменениями

В заключение можно сказать, что подход DST Platform к системе обновлений является более профессиональным и надёжным. Он учитывает специфику работы с модифицированными системами и позволяет избежать типичных проблем, с которыми сталкиваются пользователи других платформ при автоматическом обновлении.

Такой подход особенно важен для бизнес-решений, где стабильность и сохранность пользовательских доработок имеют первостепенное значение.

Действительно, подход DST Platform к системе обновлений существенно отличается от большинства популярных CMS и других систем. Давайте рассмотрим, в чём заключается эта разница и почему такой подход может быть более эффективным.

В системах вроде 1C-Bitrix, WordPress или CS-Cart используется единый механизм автоматического обновления, который часто приводит к проблемам. Когда система автоматически обновляет все компоненты, включая те, которые были модифицированы под конкретные задачи бизнеса, это может вызвать:

— Потерю важных пользовательских доработок

— Конфликты между стандартными и модифицированными файлами

— Сбои в работе системы после обновления

— Необходимость повторного внесения изменений

Подход DST Platform предлагает более продуманное решение

Разделение на два типа обновлений позволяет минимизировать риски и обеспечить безопасность системы. Автоматическое обновление ядра системы не затрагивает пользовательские модификации, что гарантирует стабильность работы. При этом ручное обновление остальных компонентов даёт возможность:

— Контролировать процесс внесения изменений

— Сохранять важные доработки

— Тестировать новые версии перед внедрением

— Избегать критических ошибок

Такой подход имеет ряд существенных преимуществ

Во-первых, он обеспечивает баланс между удобством использования и безопасностью системы. Разработчики и администраторы получают полный контроль над процессом обновления тех компонентов, которые были изменены под конкретные задачи.

Во-вторых, разделение обновлений позволяет:

— Сохранять целостность пользовательских доработок

— Избегать непредвиденных сбоев

— Обеспечивать стабильную работу системы

— Контролировать процесс внедрения новых функций

Сравнение с другими системами показывает, что подход DST Platform более продуман и ориентирован на потребности бизнеса. В то время как популярные CMS часто предлагают универсальный механизм автоматического обновления, который может привести к потере важных изменений, DST Platform предлагает:

— Гибкость в управлении процессом обновления

— Безопасность пользовательских доработок

— Возможность плавного перехода на новые версии

— Контроль над критическими изменениями

В заключение можно сказать, что подход DST Platform к системе обновлений является более профессиональным и надёжным. Он учитывает специфику работы с модифицированными системами и позволяет избежать типичных проблем, с которыми сталкиваются пользователи других платформ при автоматическом обновлении.

Такой подход особенно важен для бизнес-решений, где стабильность и сохранность пользовательских доработок имеют первостепенное значение.

Из своего опыта могу сказать что система обновлений в DST Platform демонстрирует точно гибкий подход, который выгодно отличается от традиционных CMS. В том же WordPress или Битриксе автоматические обновления — это палка о двух концах: с одной стороны, они закрывают уязвимости и добавляют новые функции, но с другой — могут «затереть» кастомные изменения, что приводит к неработоспособности сайта. DST Platform избегает этой проблемы за счёт разделения процессов: автоматически обновляется только ядро, а всё остальное — модули, шаблоны, правки — требует ручного подтверждения. Это даёт разработчику полный контроль над тем, какие изменения попадают в проект и когда.

Такой подход особенно актуален для сложных и высоконагруженных проектов, где каждая правка имеет значение. В OpenCart или CS-Cart, например, после обновления часто приходится заново вносить изменения в шаблоны или исправлять конфликты модулей. В DST Platform этого можно избежать, так как система не навязывает автоматических изменений без ведома администратора. Конечно, это означает, что разработчик должен следить за обновлениями и вручную их применять, но зато риски сломать рабочую версию сводятся к минимуму. В целом, такой подход кажется более надёжным и ориентированным на профессиональное использование, где стабильность важнее скорости внедрения нововведений.

Подход DST Platform к обновлениям выглядит продуманным и безопасным, особенно на фоне таких CMS, как Битрикс, WordPress или OpenCart, где автоматические обновления часто приводят к проблемам из-за перезаписи кастомизированных файлов. В этих системах разработчики вынуждены либо отключать автоматические обновления, либо вручную дорабатывать систему после каждого обновления, что создаёт дополнительные риски. DST Platform решает эту проблему за счёт разделения обновлений: ядро обновляется автоматически, обеспечивая безопасность и актуальность базового функционала, а все остальные изменения (модули, шаблоны, кастомные правки) применяются вручную. Это даёт контроль над процессом и минимизирует риск конфликтов.

Такой подход особенно важен для коммерческих проектов, где стабильность системы критична. В WordPress, например, после автоматического обновления плагина или ядра могут «сломаться» ключевые функции сайта, и администратору приходится экстренно искать причину. В DST Platform подобные ситуации исключены, так как все изменения вносятся осознанно. Конечно, это требует больше внимания со стороны разработчика, но зато гарантирует, что никакие важные правки не будут потеряны. В целом, такой баланс между автоматизацией и ручным управлением кажется оптимальным для профессиональной разработки.

Я понял это конечно удобнее и безопасней получается, просто в других системах есть только один тип обновлений, например в том же Битриксе, WordPress или CS Cart

Олег Сытиков

Ну им не выгодно устанавливать в ручном, безопасном режиме, проще продать сказав что у вас будет все работать на автомате и все обновления тоже будут автоматическими, при этом автоматические обновления затирают важные (кастомизированные) файлы в системе что приводит к дальнейшим ошибкам и багам, так что тут все сделано грамотно, это и сделало наш выбор в пользу DST Platform 

Я понял это конечно удобнее и безопасней получается, просто в других системах есть только один тип обновлений, например в том же Битриксе, WordPress или CS Cart

Здравствуйте! Ваш вопрос действительно логичен и понятен с точки зрения удобства использования. Давайте разберем, почему автоматическая установка масштабных обновлений невозможна и небезопасна.

Представьте, что вы приобрели базовое решение и адаптировали его под свои уникальные бизнес-процессы. Ваши разработчики создали специальные модули, доработали существующие функции, внесли изменения в код для оптимизации работы именно вашей системы.

Когда выходит масштабное обновление, оно затрагивает фундаментальные компоненты платформы. Автоматическая установка могла бы привести к тому, что измененные вами файлы были бы перезаписаны стандартными версиями, и все ваши доработки просто перестали бы работать.

Это похоже на ситуацию, когда вы заказываете костюм у портного по индивидуальной мерке. Если кто-то придет и заменит ваши подогнанные детали на стандартные, костюм перестанет сидеть идеально. То же самое происходит и с программным обеспечением.

Ручная установка масштабных обновлений позволяет:

Профессиональным разработчикам тщательно проверить, как новые компоненты будут взаимодействовать с вашими изменениями. Они могут:

Сохранить важные доработки

Скорректировать конфликтующие части

Протестировать систему после обновления

Убедиться в корректной работе всех функций

Дополнительные затраты на установку масштабных обновлений оправданы, поскольку:

Гарантируют сохранность ваших уникальных разработок

Обеспечивают стабильную работу системы после обновления

Позволяют избежать критических ошибок

Сохраняют целостность бизнес-процессов

Автоматическая установка в данном случае могла бы привести к серьезным последствиям:

Потере важных данных

Сбою в работе ключевых функций

Необходимости срочного восстановления системы

Значительным финансовым потерям

Поэтому, несмотря на кажущуюся привлекательность автоматической установки всех типов обновлений, существующий подход является наиболее безопасным и надежным способом поддержания вашей системы в актуальном состоянии без риска потери функциональности.

Мы всегда стремимся найти баланс между удобством использования и безопасностью работы системы, и текущий механизм обновления является результатом многолетнего опыта и множества практических кейсов.