Drake777

Опять же смотря как и что реализовывать, мне попадались проекты, которые в конечном итоге проще было сделать на 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= можно также добавить группировку не по вариантам, а по ид товара. Тогда все будет как проиндексировано.

можно попробовать включить отображение ошибок через ini_set('display_errors', 1);

отвечать или нет - дело сугубо ваше. Но если уж вам и Нокстеру не особо нравится Симпла в том виде как она есть, то логично предположить, что есть некий другой движок который нравится. Но этой темы вы почему-то избегаете. Лично мне было бы интересно посмотреть не только на ваше творение на гитхабе, тем более, что там реализовано далеко не все из запланированного вами же, но и уже проверенный на практике готовый движок.

похоже, что я не так понял проблему. Ранее у контент-менеджера была похожая проблема, это ее решило.

Давинчи, в отличие от слившегося Noxter-a, довольно понятно разъяснил, что он хочет от симплы. Что считает обязательным юнит тесты и т.д При этом так и не ответил на вопрос какой движок считает максимально приближенным к идеалу. a13x же вполне придерживается концепции симплы. Псевдо MVC логика + комментарии в коде. Если в движке это допустимо, то странно требовать разработчиков на нем другого подхода. Если же не нравится движок, то как минимум странно сидеть на его форуме. Да и сама по себе дискуссия довольно странная, нежели интересная. Денис уже года 2, если не бол

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

никак. Есть речь о небольшом магазине, то такие гарантии как правило и не нужны, достаточно внимательности при разработке. Полноценное тестирование стоит денег. А небольшие магазины далеко не всегда готовы их платить. Даже с учетом того, что потеря работоспособности будет стоить дороже.

что подразумевается под масштабированием? если добавить кеширование, нормальные фильтры, города на поддоменах, различные отчеты по продажам, формирование закупок, складской и фин.учет, rest api - это уже масштабирование? опять же речь о масштабировании функционала или самого проекта? понятно, что для условного wildberries симпла не подойдет, но для проекта даже на 100 тыс товаров - вполне. И тогда какой движок на ваш взгляд привлекателен для разработчиков? Спрашиваю без сарказма/иронии, на самом деле интересно. Noxter заявил про болячки и слился. Вы тоже сказали про ограниченно