Drake777

в 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>