Baco

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

какое кол-во "включенных" товаров на сайте ? (общее)

отключить счетчики (кол-во товаров) в категориях\подкатегориях.

По первому вопросу, оптимальное решение тут или тут.

По 2-му, то из всех, мне известных, только этот работает без глюков.

Хотя можно и этот рассмотреть.

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

На Вашем месте, я бы задал вопрос по другому: "Какие есть готовые модули у сообщества опенкарт, которые подходят для платёжных шлюзов банков в РФ, а именно: 1. Название банка, 2. Название банка 2, 3...."

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

Если нужно простое решение по обновлению цен под производителя, то проще всего сделать контроллер, модель и въю-файл, где:

1. В файле модели будут 2-ве функции:

а) Выборка товара по производителю

б) Апдейт поля price таблицы product с учетом указанной наценки

2. Контроллер с проверкой ПОСТ запроса на изменение (1б) и ГЕТ на выборку по производителю (1а)

3. TPL (въю-файл) будет иметь фактически 2 поля:

а) select в котором будет перечень для выбора производителя (критерий для обновления)

б) input type text - поле, где вводиться значение для наценки

в) кнопка, нажатием на которую данные отправляются в БД (обновляются)

Примерно такой алгоритм, если же имелось в виду готовое решение, то ув. товарищ Einshtein указал направление.

P.S. Как расписывал логику, было добавлено сообщение, поэтому, Ваш выбор - так же правильный.

Мдасс... печалька, если "пациент" с Крыма, теперь ответит по строгости РФ... Это тебе не Украина с законами непонятными... Возмездие приближается...

Таких "фрилансеров" я б сам отлавливал и обрекал, так как нормальным спецам после их "пряморукости" приходиться долго исправлять всё или после таких, приходит клиент и пишет: "Развели меня и денег нет, а сделать надо..." 

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

Тогда прописываете ДНС для нового домена в регистратора, согласно данным Вашего хоста, а на хосте - припарковываете новый домен, в большинстве случаев, хостинг автоматически создает каталоги по новому домену среди файловой структуры сервера, вот туда и выгружать всё содержимое папки upload чистого дистрибутива.

Панель управления хостингом дает возможность припарковать домен ? 

P.S. Если вопрос для Вас сложный, напишите в ЛС.

Здравствуйте, Вы хотите создать 2-й магазин, независимо от первого или с какой то привязкой (мультимагазин) ? 

Найти и обректи... Законно тут долго и утомительно...

Может там в студии - всего навсего один спец - универсал сидит, а может в штате - практикант-верстальщик, неведомо, но я, например, по таким вопросам так же слабоват и по вёрстке, подключаю к проекту доп. специалиста, именно того, кто хорошо это делает, а если надо и СЕО специалиста... считаю, что каждый должен делать свою часть проекта, так как сколько не встречал профи, универсалов не бывает, есть либо всего но понемногу, либо где то глубоко, а в остальном - поверхностно.

Как базис использовано брокарт, сайт миленький но простенький, а в чем собственно "фе" ? Бывало я "ужасы" по вашем понятиям делал ещё хуже, но... если клиент так хочет, то как говориться, "Желание клиента - закон..."

ОНО не отключается, это логический процесс оформления заказа, если не надо определённых пунктов - лезьте в код, комментируйте не нужные шаги, оптимизируйте запросы при создании заказа минуя временные процессы от захода на оформление и нажатием "подтвердить"...

Долго объяснять логику, но суть такова, при оформлении (переходе на страницу оформления) из сессийных данных формируеться пустышка, если нажато в конце кнопку "подтвердить" - меняется статус, если пройден успешный этап оплаты - меняется статус, если облом на каком то шаге, висит пустышка. Всё сделанно для того, что б уберечь от действительных заказов и фиктивных.

А кеширование тут при чем ??? ставьте себе проверку времени в таблице, в которую заносяться 2-ва параметра:

1. ИД выведенного товара

2. Последняя дата

и после функции:

getRandomProduct()

сразу апдейтите поля в таблице с датой на : date('Y-m-d', time() + 60)

ну и продакт ИД сразу туда вносите...

условие же проверки примерно такого плана:

if(date('Y-m-d', time()) >$result['date_in_table']) {

getRandomProduct()

UPDATE YOU DATA

}

как то так алгоритм построить...

Дружище, тут форум по опенкарту, вордпресс малёха по другому адресу...

Как то так...

ага, или пишет, ошибка в 312 строке и полный листинг кода... называется, что "пальцем в массив..."

и добавить поле для ввода кол-ва...

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

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

P.S. В самом начале беседы с заказчиком, акцентирую специализацию на кодинге и отказе от выполнения работ по верстке, наполнению и т.д. никак не связанных с функционалом.

Оговорился, "после работы"... Путеводителем, либо гугл либо форум пусть выступает, я в таком случае говорю, что 15 \ час и можем рассусоливать хоть до Пасхи...