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

Что касается серверов — на DO — на один сервер 1 тб трансфер, имейте это ввиду. Что касается русских проектов с серверами зарубежом — тоже работают отлично. В poiskvps все есть. Цена вопроса для личного VPN на 10-15 человек — рублей 200-300.

Для личного использования (если вы не в Китае), подойдет любой протокол VPN, советую Outline поставить. Самый простой вариант.

Вопрос сложности оплаты опустим. А вот это зря. Сейчас многим приходится отказываться от неплохих вариантов только потому что невозможно их оплатить.

Здесь ответ заключается в ответе на вопрос — что Вы будете делать, если DO в одностороннем порядке расторгнет договор, сказав что-нибудь типа того, что недавно сказал TeamViewer? (а ответ на этот вопрос зависит от того, зачем Вам в основном VPN. Раньше цель была одна — ходить на сервера, забаненные РКН. В нынешние чудные времена появилась вторая — ходить на сервера, которые сами не пускают IP из РФ/РБ)

Вот в зависимости от того, зачем Вам VPN — и ответ на вопрос. Если основная цель — первая, то конечно брать в DO. Если вторая — то лучше у российского хостера. 

Для обхода блокировок со стороны сервисов, Qt, например, российских хостинг с серверами за границей может не подойти. Были прецеденты. Так что, если есть возможность оплатить зарубежный хостинг — надо брать зарубежный

Вероятность блокировки конкретно Вашего 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 подобные ситуации исключены, так как все изменения вносятся осознанно. Конечно, это требует больше внимания со стороны разработчика, но зато гарантирует, что никакие важные правки не будут потеряны. В целом, такой баланс между автоматизацией и ручным управлением кажется оптимальным для профессиональной разработки.