nogocuHoBuk

Дело в том, что order_id передается в GET, а остальные параметры в POST Т.е. нужно отправить POST запрос по адресу: /index.php?route=api/order/history&order_id={order_id} с параметрами:

Да тут же без разницы, на самом деле. Мне удобней юзать $('#modal-window').modal('show'); либо data-toggle="modal" data-target="#modal-window" на кнопку из бутстраповского JS. Функционал то уже в коробке. А так да, дело привычки, согласен.

Вообще не важно количество измененных букв в смене домена. Это уже абсолютно другой домен. Помимо стандартных операций по смене домена: Нужно будет пройтись в личке по авторам модулей и запросить у них сменить домен. Некоторые модули и шаблоны просто не заведутся на новом домене требуя купить лицензию. Потому, лучше найти человека разбирающегося в вопросе. Думаю в ЛК накидают предложений...

Помимо @Media бутстрап отвечает за модалки, например. Никогда не задавался этим вопросом. В принципе если пишете шаблон самостоятельно и под себя - почему нет. Глушите на здоровье. ЗЫ. Игры тоже можно создавать с нуля (с написания движка) и многие так делали (и делают), но в последнее время всё больше и больше разработчиков переходят на Unreal Engine. Зачем? Чтобы не изобретать велосипед а сосредоточиться на других вещах, куда более важных.

как? Это вариант из коробки. Он может не работать только в одном случае - где-то что-то поломатое

не знаю как у большинства, но меня абстрактные значения не убеждают никогда. Все СМС, Вайбер рассылки, email и прочее прочее, в которых указано вероятность получения сферического коня в вакууме без конкретики я игнорирую подсознательно. Даже если в тексте "Вы накопили 200 баллов" - НЕ привлекает. Но как только я получаю что-то персональное с таким текстом: "Здравствуйте, Евгений. Вам начислен бонус в размере 100 грн, которые Вы можете потратить в нашем магазине" - тут же иду сверяться. И такую СМС я не потеряю Т.е. в голове происходит сравнение. Если мне прислали "Бонус" или "просто абстрактные зайдите и проверьте" - это не с чем сравнить. Нет точки опоры. А вот явные 100 грн я уже могу сравнивать. Это то, чем я пользуюсь каждый день (гривнами). И я понимаю есть смысл дергаться на эту сумму или нет. И если смысл есть - оооо. Я ни письмо, ни мыло, ни сообщение в вайбере не потеряю Иногда до смешного. Прилетает от Розетки - Вы накопили 100 грн: Тут же пошел на Розетку и набрал какого-то "го**на" на 500 грн. Зачем, спрашивается? Да просто потому, что 100 грн скидки было

Сразу чуть не так прочитал Ваше сообщение Да. у ТСа нет таблиц oc_manufacturer_description и oc_manufacturer_to_layout. У него опенкарт.

Как минимум 4 запроса: DELETE FROM `oc_manufacturer` WHERE `manufacturer_id` NOT IN (SELECT DISTINCT `manufacturer_id` FROM `oc_product`); DELETE FROM `oc_manufacturer_description` WHERE `manufacturer_id` NOT IN (SELECT DISTINCT `manufacturer_id` FROM `oc_product`); DELETE FROM `oc_manufacturer_to_layout` WHERE `manufacturer_id` NOT IN (SELECT DISTINCT `manufacturer_id` FROM `oc_product`); DELETE FROM `oc_manufacturer_to_store` WHERE `manufacturer_id` NOT IN (SELECT DISTINCT `manufacturer_id` FROM `oc_product`); Выполнять по очереди непосредственно в phpmyadmin Суть запросов - удали из таблицы все записи, у который производитель не найден в таблице товаров И вот эта подстрока: SELECT DISTINCT `manufacturer_id` FROM `oc_product` - как раз выборка всех уникальных производителей.

Это ж айфрейм. Чисто HTML внедрение. Подобным скриптам вообще фиолетово какая у Вас CMS, на чём она написана, кем админится etc. Включите оператора, чтобы воспроизвести ошибку. Возможно в консоли будет что-то важное.

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

Не нужно Вам никаких "кликов по кнопке" У вас проблема в неправильном параметре фильтра - конкретно в диаметре шин.

Сама ошибка говорит о том, что при добавлении в таблицу oc_category_description информации о категории "Религиозная" для языка 1 (скорее всего русский) произошла ошибка - попытка записать запись с ключом "PRIMARY", который уже существует. Т.е. запись в этой таблице с category_id = '17' и language_id = '1' (а именно они являются ключом) уже существует: Ковырялись в БД и удаляли категории вручную из таблицы oc_category? А хвосты остались... А даже если не ковырялись Вы - то какое-то из расширений, а они у Вас стоят, судя по тому, что практически все файлы лежат в /modification/ Так что какого-то "общего" решения не будет. Произойти могло что угодно. Нужно смотреть код, смотреть в БД и исправлять.

Большую часть Вам уже подсказали, но с БД есть один нюанс. Если, например, в описании товаров Вы добавляли изображения и в качестве src указывали полный путь (https://oldsite.ru/images/image.png) вместо относительного (/images/image.png) то при переезде на новый домен путь к картинкам будет вести на старый сайт. При корректно настроенном редиректе оно даже будет работать, по идее, но такого рода "ловушки" лучше сразу исправлять либо при смене домена, внося изменения в БД, либо правкой описаний товаров. Тут уж как Вам сподручнее.

С точки зрения SEO, конечно, ничего хорошего, но реальность имеет на этот счет другое мнение. 90% всех интернет магазинов имеют так или иначе на 95% схожее описание товаров. А те 10% "уникальных" магазинов либо не имеют описания вовсе, либо в поле описание написан текст, интересный исключительно роботам гуглояндекса, а для человека это просто набор слов и словосочетаний... Очень сложно написать уникальное описание для ручки, например. От этого и исходите.

Если я правильно понял задачу. В модели /catalog/model/catalog/product.php создаете функцию: public function file_get_contents_curl($url) { $ch = curl_init(); curl_setopt($ch, CURLOPT_AUTOREFERER, TRUE); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_FOLLOWLOCATION, TRUE); $data = curl_exec($ch); curl_close($ch); return $data; } Создавая свои html'ки обзывайте их по product_id, т.е. 12456.html Ну и в контроллере /catalog/controller/product/product.php вместо $data['description'] = (ну или куда там нужно вставить) пишете: $data['description'] = html_entity_decode($this->model_catalog_product->file_get_contents_curl('{Папка, в которой у Вас html лежат}'.$product_id.'.html'), ENT_QUOTES, 'UTF-8'); Тем самым записывая в description товара, передаваемый шаблонизатору tpl содержимое нужно Вам файла... Ну либо по условию (это уже не проблема, думаю, переделать) Можно и код ответа проверять в file_get_contents_curl. Если 404 - возвращаем null, а в контроллере проверка на null, чтобы либо менять оригинальный дескрипшин, либо оставлять оригинальный

на онклик - compare.remove(product_id) В вашем случае, наверно, на onChange. Зависит от реализации. В любом случае: добавление compare.add(product_id) удаление compare.remove(product_id) PS. Хотя, возможно, remove это уже у меня какой-то кастомный скрипт Есть ещё один стопроцентный вариант - "тыкнуться" на index.php?route=product/compare&remove={product_id}

ну так-то да. смысл есть "Меньше знаешь - крепче спишь"(С) Согласен Посыпаю голову пеплом!

верно. ведь изначальный вопрос возник у ТС, как я понял, из-за опаски "за***ать" базу (админку). а подобная реализация этому не способствует... ну да такое.

Вот серьезно. Не хотел обидеть... Но @ashap прав же. ТС написал, чтобоится, что у него админка будет "за**ана" "временными" заказами. Это изначальная его проблема. Решение - его конкретной проблемы - понять зачем модуль оплаты пишет в историю и переводит заказ из потерянного в рабочий. Ваше ж решение основано на том, что "так пиши не в ордер, а в нью_ордер". А разница в чём? Причем изначально это Вами (хотя я могу заблуждаться) даже не предполагалось. Просто хранить номер заказа в сессии... Вот я и отписался с фразой - "это не решение, а костыль"... Всё, удаляюсь из темы чтоб не флудить...

Я и передаю будущий. Вы правда не понимаете? Сейчас создано 99. Следующий 100. Я передаю платежной системе, что следующий 100. А Вы создаете заказ, которыцй нужно создать СРАЗУ. А аутоинкремент - 100. Понимаете? И создавая заказ (ВАШ) он будет с номером 100. Вас ничего не смущает?

При чём тут сессия и кука? Я офомрляю заказ. Следующий 100. Акей. Запомнили, Но в этот момент Вы оформляете заказ который НУЖНО создать сразу, ибо у него наложеный платеж (это к вопросу о том, какой способ оплаты). И заказ создается. Какой у него будет номер? И что потом делать "Платежной системе, когда она вернет колбек, что заказ номер 100 "оплачен"? Как всё это разруливать?

Отличное решение. А подскажите, как оно будет работать если на сайте заказ оформляют больше чем 2 человека одновременно? Причем с разными способами оплаты.

Суть в том, что все без исключения платежные системы для генерации платежной формы требуют order_id. Повторюсь - все без исключения. Прежде, чем передать данные в эквайринг - заказ должен быть создан, т.е создаваться они будут в любом случае и отключить эту возможность не получится... Но чаще всего модули платежной системы не используют addOrderHistory(), т.е. заказ содается со статусом 0 (в админке такие заказы можно найти отфильтровав по "потерянный заказ"). Если Ваш платежный модуль создает заказ с другим статусом - нужно внести изменения именно в модуль, чтобы заказу не присваивался статус. И да, вопрос актуальный (если действительно нужна помощь) А так же какой именно модуль используете.

А встроенный функционал не подходит? Итог на сайте будет таким: Поклацать "переключатель" можете тут: https://shop.webdd.in.ua/ipod-classic.html

Глянул на сайт донор ещё раз. Там 100 позиций товаров. В 80 примерно не более 20-30 "перелинковок) и только в нитках их около 600.... Так что фраза про имеет право на жизнь... Но, опять же, нужно чтобы ТС хоть ЧТО_ТО написал в теме. А то гадаем на кофейной гуще