OtezVikentiy

Насчет готового решения не могу подсказать, но в принципе можно сделать на уровне БД запросом. INSERT INTO oc_product_to_download (product_id, download_id) VALUES (11,12); Соответственно подменяете идентификаторы на нужные и префикс таблицы меняете на свой. И всё будет работать.

Ну вообще конечно интересная задачка. А документация и финансы под это дело имеются? )))

Было бы неплохо хотя бы какие-то вводные дать... Что за модуль, хотя бы какой функционал. Может он уже написан и вам просто ссылку дадут на него.

Не очень понятно. Вы это хотите сделать в меню или в хлебных крошках? Или....

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

Если у вас древовидное тяжелое меню и по товарам надо делать дополнительные выгрузки - есть вариант сделать рефакторинг архитектуры БД например и не страдать 20+ запросами в БД. ))) Меню и товары - в 99% случаев это по большей степени статика, которая меняется, ну окей... пусть будет даже если 2-3 раза в день, но никак не 100 раз в минуту например. Соответственно в случае, если у вас действительно все прям настолько сложно, что нужно делать овермного запросов на стоковой БД и все это большое и тяжелое - сделайте 2 отдельные таблицы где будете хранить нужные данные в нужном виде и делайте вместо 20-30 запросов - 2 запроса... ))) И обновляйте эти таблицы по триггеру. Да, у нас получается оверхэд по хранению данных и получается, что надо следить за консистентностью, но за то у нас вместо 30 запросов - 2. Это конечно возможно не идеальное решение, но проблему точно решает.

Ну вот собственно Yoda уже ответил. Оптимизация - это комплексный подход и довольно не быстрый процесс. Собственно ищите опытного разработчика, который готов будет этим заняться. ))) Сказать что вот поставь модуль такой-то или удали кусочек там-то - тут так не получится. Это сидеть, смотреть, разбирать, профилировать код, оптимизировать запросы к БД, смотреть на обращения к серверу, всю цепочку от начала и до конца. Кропотливый процесс.

Ну собственно надо смотреть в модуль интеграции с PayPal... Конкретное место вам скажет либо автор модуля либо самостоятельно ковыряться либо нанимать разработчика стороннего, который будет сидеть и ковырять.

Да в принципе можно, только насколько я слышал (не уверен) SEO может постарадть от этого и типа лучше делать на поддоменах или в разных директориях. Чтобы все индексировалось в нужных регионах.

Это не запросы к базе данных - это запросы к серверу. Это вообще не одно и то же

Ну вообще 310 отдельных запросов в БД для одной страницы даже с учетом меню - это очень много. Отсюда и удивление такое. Потому что ну выгрузить товары например для 10 блоков... ну это 10 запросов... Собрать меню например ну еще 5 запросов... Ну допустим еще 5-7 запросов набросим... Итого 22 запроса в БД отдельных - и то это многовато и можно оптимизировать в несколько раз в идеальных условиях. Но как бы... еще 280 запросов - это вообще куда? Вот отсюда и удивление, потому что это реально слишком много и абсолютно точно это не нормально. Да, в опенкарте не идеальная архитектура БД, но не настолько, что 300+ запросов с 1 страницы в БД.

Ну собственно надо код профилировать сидеть. Либо объединять запросы либо как-то группировать, но это все вручную и сильно трудозатратно. Скорее всего там просто установлено модулей 100500 штук, которые каждый делает свой запрос на выгрузку плюс-минус одних и тех же данных. Потому что в движке из коробки нет даже 20 запросов к БД... Про 310 я уже вообще молчу... Кстати, а как вы поняли что там 310 запросов в БД? Может там 310 запросов к бэкэнду на выполнение каких-то скриптов? Или прям реально 310 запросов именно в БД происходит с 1 страницы?

Ну я ж написал, что надо синтаксис поправить возможно. Я мог ошибиться с синтаксисом. Может быть переменные по-другому называются. Я просто принцип рассказал. Дальше уже надо пробовать, менять смотреть... ))) Готового решения я вам вряд ли напишу прям с ходу )))

Да тут проблема конкретно с интеграцией с paypal, а не со скидкой. Если у вас скидка считается корректно, но в платежную систему уходит не та сумма - это однозначно проблема интеграции. Другой модуль скидок тут не поможет с 99% вероятностью.

Можно конечно, но это прям больно... Возможно в этом случае даже лучше с нуля все сделать...

В самом твиге есть переменные по синтаксису примерно так: {{ product_name }} Соответственно вот эти переменные вам необходимо подставить в скрипт чтобы было примерно так: <button type="button" class="TINKOFF_BTN_YELLOW" onclick="tinkoff.createDemo({ shopId: 'SHOP_ID', showcaseId: 'SHOWCASE_ID', demoFlow: 'sms', items: [ {name: '{{ product_name }}', price: {{ product_price }}, quantity: {{ quantity }}} ], promoCode: 'default', sum: {{ product_price }} })" ></button> Ну типа такого. По синтаксису мог ошибиться в чем-то - надо поправить по месту, но принцип примерно такой.

А откуда у вас вообще ТАКОЕ количество запросов с 1 страницы то? Это прям ад какой-то... о_О Что там столько запрашивается? Вот как раз из-за доп ПО у вас и есть 310 запросов... Вам как раз нужна ручная оптимизация, а не доп ПО. 310 запросов с 1 страницы - это прям овермного. Даже 20-30 это многовато... Что там за страница то такая?

Если соответствующие языковые пакеты есть и настроены поддомены под разные языки - то можно.

Если бэкапа кода и базы нет ( в любом виде ) - то как бы всё... приехали...

Всё зависит от того где вы эту кнопку располагаете. В зависимости от контроллера - в твиг передаются переменные, которые можно заложить в эту кнопку. Если это на странице товара - то там одна логика, если это корзина - то другая. На некоторых страницах данных для этого может вообще не быть.

Тут нужно копать в интеграцию с PayPal. Смотреть что пробрасывается в АПИ PayPal. Видимо туда пробрасывается стоимость без скидки.

Калькулятор расчета чего? Какого сайта?

К сожалению под 1.5 планов по адаптации нету. Уж слишком старая версия движка. Даже не уверен, что оно там взлетит без лютейших костылей (которые ставить не хочется). Поэтому... Соглашусь вот с этим...

Так у вас проблема то не с браузером, а с самой экселькой... Даже не столько самим документом, а сколько с самим софтом microsoft excel... Это сам эксель каким-то образом видимо валидирует сертификаты сайта и не известно насколько вообще валидна его валидация. Так что не парьтесь по этому поводу. Вы это на стороне сайта вряд ли как-то поправите. Либо если этот вопрос прям горит и вы несете значительные потери из-за excel... Ну тогда надо разбираться как Microsoft Excel валидирует сертификаты сайтов и соответственно покупать тот SSL сертификат, который удовлетворяет Excel... Но это выглядит как какая-то дичь на самом деле...

А сама ссылка в Excel вообще как сформирована на http или https происходит переход первичный?