Drake777

еще и с Екб публика)

либо новую сущность (на основе категорий или брендов), либо через тип категорий.

{if $product->name|strstr:"Телефон"}<div class="sticker">Стикер</div>{/if}

да ничего не мешает. Можно делать. Другое дело, что спроса на них особого нет. А самому предлагать желания нет

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

Опенкарт медленней симплы. А так да, количество новеньких на симпле снизилось. В этом году всего 1 человек новый писал А Окей же вроде бесплатным стал, почему он теряет позиции? Недавно крайне удивился, когда в России предложили проект на Okay, хотя разрабы всех из России далеко и надолго послали. Но для Украины, то норм по-моему. Или у вас другое мнение?

задача ведь другая "чтобы товар на сайте исчезал (неактивный), но при прямом заходе отдавал 200" в ProductView убираем проверку на видимость и все.

ProductView.php

в import.tpl в js еще надо определение brand_id в ajax вы дописали brand_id: brand_id, а что это такое похоже не определили выше

если у вас уже работает с ?discounted=1, то возможно будет достаточно добавить правило в .htaccess

конечно, можно. Можно практически все сделать. Надо понимать как это должно работать логически, тогда можно будет оценивать проект и сравнивать подобный проект с интеграцией и абоненткой за другие CRM. Везде свои плюсы и минусы

а как правильно загружать такое количество фоток?

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

А не проще сделать на основе той же симплы некую общую админку, куда будут все заказы улетать? А при смене статусов будут обновляться на сайтах с которых прилетели Т.е схема следующая: - клиент сделал заказ на сайте1. заказ остался на сайте1 и продублировался в "simpla-crm-сайте" - менеджер обновил статус в в "simpla-crm-сайте". Данные обновились на сайте1 ... дублируем на N сайтов. Правда для того, чтобы остатки вести придется связки товаров делать, не знаю насколько это будет реально в вашем случае. Но в целом схема рабочая. А диалоги действ

интегрировал сайты с bitrix24 и retail crm. По ссылке вариант рабочий, но повозиться все равно придется. Да и потом допиливать надо будет, тк запросы появляются в процессе эксплуатации. Понятие "добротно" очень абстрактное. Нужна конкретика: какие данные куда и в какой момент передавать. Но по деньгам в любом случае дешево не получится, тысяч от 15 минимум. Официальные партнеры того же retail crm года два назад озвучивали ценники в 30-50-80 тыс рублей в зависимости от пафосности фирмы и базового функционала.

вопрос ради доколебаться? если очень хочется, то можно и print, но в обоих случаях желаемый результат будет один. Скорость выполнения в обоих случаях будет одинаковая

print_r($this->db->placehold("query text")); где query text - текст запроса

Опять же смотря как и что реализовывать, мне попадались проекты, которые в конечном итоге проще было сделать на 2 разных базах. Поэтому и прикидываю объем правок исходя из личного опыта изменений. Видимо у вас другой опыт, когда изменений было минимум. По кастомизации - обычно на начальном этапе хотелок минимум, а потом всплывают в большом количестве. Дизайн нужен разный, способы оплаты/доставки могут отличаться вплоть до разных юр.лиц внутри одной компании, свои категории, доступы к заказам для разных менеджеров на разных сайтах и т.д

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

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

в самом простом варианте правим CartView на сайтах-донорах и в момент создания заказа отправляем курлом данные на сайт-реципиент. В зависимости от данных можем проставлять заказам метки (с какого сайта пришел заказ) можно это делать непосредственно в момент заказа, можно по крону раз в период Но есть ряд нюансов: товары одинаковые или разные? если одинаковые - можно ли сопоставить по ид, артикулу или названию? надо ли менять количество на магазине куда попадают заказы или достаточно информации о заказе, а остатки будут на других магазинах?

Можно еще на вотсап настроить. Либо через официальное апи (там все сложно и долго), либо через неофициальное, например https://chat-api.com/ru/ под неофициальное есть готовое решение

судя по всему нужны подкатегории? если да, то так: {foreach $category->subcategories as $c} {if $c->visible} <li> {if $c->image}<img src="{$config->categories_images_dir}{$c->image}" alt="{$c->name|escape}">{/if} <a {if $category->id == $c->id}class="selected"{/if} href="catalog/{$c->url}" data-category="{$c->id}">{$c->name|escape}</a> </li>

есть вариант сделать по следующей схеме: 1) один из магазинов будет "донором товаров". Либо можно в качестве донора товаров вообще отдельный домен использовать. на доноре допиливаем постраничную выгрузку товаров в json (постраничная имеет смысл, если товаров в дальнейшем будет много), либо делаем на одной странице, если товаров мало также даем возможность выбирать на какие сайты отдавать товары (чекбоксами в карточке товара в админке) 2) делаем отдельно выгрузку цен и остатков. Отдельно - для ускорения обмена, чтобы не гонять лишние данные. Добавление новых товаров на

Если вы хотите, чтобы каждый вариант товара индексировался, то имеет смысл попробовать их сделать разными товарами. Когда варианты внутри одного товара, то они обычно не индексируются Для турбо проще всего сделать отдельный фид, скопировав yandex.php и назвав его иначе. Далее в этом файле уберите ?variant= можно также добавить группировку не по вариантам, а по ид товара. Тогда все будет как проиндексировано.