100napb

можно. левое меню в админке: дизайн - схемы - выбрать схему\макет "продукт" - присвоить нужному экземпляру модуля "рекомендуемых товаров" то или иное положение внутри схемы\макета - сохранить.

Стандартный контроллер карточки товара формирует вот такой массив сопутствующих товаров Пример вызова в контроллере карточки товара: $this->model_catalog_product->getProductRelated($this->request->get['product_id']); в шаблоне к списку связанных товаров можно обратиться через переменную-массив $products. Если таковая определена - то перебирать в цикле и выводить как Вам хочется.

Здравствуйте! Ответил Вам в личные сообщения. Скорее всего, пропустили какой-нибудь этап установки. Не переживайте - все будет работать, т.к. там все просто

Вы правы. Если сервер БД на попытку коннекта отвечает "отказано в доступе", то либо не в ту дверь стучимся, либо не те реквизиты доступа. Только топикстартер знает, на каком порту у него висит СУБД с базой опенкарта и пользователем, и какой порт правильный. Не исключено что у ТС несколько экземпляров mysql поднято и работает: пользователя создал в одном месте, а авторизоваться пытается в другом... и на 3306 порту ошибка, да )

У меня isp5 Если не ошибаюсь, isp поднимает альтернативные версии MySQL / MariaDB через докер и на нестандартном порту: 3307, 3308 и так далее. Может быть все ещё банальнее и в конфигах Опенкарта просто некорректный порт..

Не соврать бы, раз 10 проверял, даже менял версии MSQL. Создавал по новой. как вариант: пользователь БД для опенкарта не создан для хоста localhost, а только для 127.0.0.1 при ручном создании пользователя БД (запросом через консоль) забыли выполнить FLUSH PRIVILEGES; проверить легко:

Кому-то должны, кому-то нет... Нет жедания сводить все до кухонного разговора. Это не проблема в широком смысле слова. Есть как минимум несколько способов решить эту задачу. Как пруф - огромное количество ИМ на ОС с внущающим кол-ов товаров, которые не тормозят. Верно. Должно работать очень быстро. Хотя бы потому, что джоин таблиц из запроса в стартовом посте происходит по первичным ключам. Убедитесь, для начала, что mysql в состоянии разместить все индексы баз данных в ОЗУ, а не производит их чтение с диска при выполнении запросов. Гуглите key_buffer_size, если Ваши таблички на myisam или innodb_buffer_pool_size, если имеют движок innodb. В первом случае все индексы всех myisam-таблиц БД должны помещаться в key_buffer_size; во втором, как вариант, можно можно установить значение = размеру всех данных и индексов в иннодб таблицах вместе взятых.

Согласен. Но только если речь идет о какой-нибудь аналитике. Иной раз даже несколько минут - это очень быстро. Но в вэбе это много даже для суммы всех запросов к базе, необходимых для генерации страницы. А Вы терпеливый. Сколько товаров в Вашем ИМ ? Сколько максимум товаров внутри одной категории? У Вас виртуальный (общий) хостинг или выделенный сервер? Можно. Кусочек опенкартовской прелести в том, что переделать код под себя относительно просто. Но, забегая вперед, Ваше решение едва ли более универсальное и более гибкое, как мне кажется: хуже подходит для кэширования; более длительные блокировки строк\таблиц базы при одном долгом селекте, потенциально, могут создавать неприятные последствия. Впрочем, конкретно у Вас оно может быть и лучше - просто имейте ввиду. Простота решения (выкл и готово), слабый хостинг (более производительный ведь дороже), плохо настроенный сервер БД (а разве его настраивать можно?), нежелание или неумение кэшировать то, что прям просится... неудивительно, что это самый популярный совет.

стандартный фильтр товаров в опенкарте такого не умеет. Его можно кастомизировать, конечно, это не сложно, но потребуется добавлять новые пользовательские элементы в форму\представление (вьюху), редактировать контроллер и модель для странички с фильтром товаров в админке. Например, можно добавить галочку типа "товар отсутствует в иных категориях, кроме выбранной" и научить опенкарт работать с этой галочкой. В паре слов инструкцию не возьмусь написать, пожалуй. Если Вам нужно разого что-то с этими товарами сделать или просто найти\посмотреть, то нет ничего проще:

Мы смотрим с Вами на проблему ТС с разных точек зрения, и только -> спрятал в спойлер.

Нет нужды оптимизировать каждый из приведенных выше запросов. Стоит сфокусировать внимание на самых "тяжелых", которые создают ту самую нагрузку, из-за которой хостер, в общем-то, и выписывает Вам ая-яй-ку. Их вроде как всего три штуки. Один из самых примитивных и одновременно эффективных способов оптимизации запросов - создание правильных индексов. Тестируйте до и после индексов профилируя запросы через explain. Запрос 1 и 3, использует одну и ту же таблицу, что нам только на руку. Можно попробовать создать индекс... блин *сморщился* по текстовому полю.. но попробовать все-равно стоит: по полю path. Можно поиграться с длиной индекса. Ради эксперимента, можно установить вплоть до 100. 2. В таблице product_image должен быть индекс по полю product_id по-умолчанию, из коробки. А есть ли такой же индекс в таблице product_image_by_option ? Это ведь, скорее всего, кастомная таблица от какого-то модуля. Значит шансы отсутствующего индекса велики. что касается периодичности всплексов нагрузки... лучше Вас Ваш же проект никто не знает... как вариант, какой-нибудь импорт товаров настроен, парсинг, или какое-нибудь задание по крону. В том же мегафильтре перестроение внутренних табличек должно срабатывать при массовом изменении товаров. Если это не внутренняя нагрузка, источником которой являетесь Вы сами, то смотрите access логи веб-сервера

ух, что есть. Спасибо!

Наткнулся на описание любопытного сервиса. Вдруг кто-нибудь из авторов платежных модулей решит использовать сей функционал? Выглядит крайне дружелюбно и полезно. https://habr.com/ru/post/453672/ https://cardinfo.online/

по существу и очень кратко. Wix, как и другие так называемые конструкторы, являются, по своей сути, облачным SaaS решением (Software as a Service). Погуглите, что это, для чуточку более глубокого понимая сути. У такого подхода есть ряд реальных преимуществ для владельца, бОльшая часть из которых так или иначе связана с относительной простотой запуска проекта и низких трудозатрат. Иными словами - серьезная ставка сделана на тех потребителей, которые не хотят сколько-нибудь заморачиваться. И это работает. То есть, спрос однозначно есть. Однако, скорее рано, чем поздно, Вы столкнетесь с пониманием того факта, что, по сути, используя облачные решения, Вы тупо арендуете (а-ля доступ по подписке) набор тех или иных программных решений, функциональных блоков. И реальной возможности глубоко кастомизировать \ редактировать тот или иной функционал у Вас попросту нет. Вам не принадлежит ничего. Ни строчки кода из внутренних механизмов не доступны Вам не то что для редактирования - даже для просмотра. Не будет у Вас индивидуального подхода и не сможете Вы реализовать сколько-нибудь уникальных решений \ хотелок. В то же самое время, опенкарт, как открытая cms-ка с открытым же исходным кодом позволяет Вам буквально все. При наличии компетенций и желания, конечно ж: разнообразные модули, расширения, дополнения, глубокая кастомизация и ... короче, Вы не ограничены практически ничем, если сравнивать с облаком. Однако, вместе с тем у Вас теперь есть обязательства и выбор: какой хостинг использовать, какое окружение, версию пхп, модули и масса других вопросов. Короче говоря, хотите маленький шаблонный магазинчик с минимальной сложностью, "что бы было", и с относительно низкими стартовыми вложениями (именно стартовыми; посчитайте аренду\подписку за год и сравните - иллюзия выгоды растает на глазах) - юзайте конструкторы. Если же у Вас есть требования к более-менее серьезной индивидуализации проекта и запросы к сколько-нибудь уникальному (не шаблонному) функционалу - используйте полноценные CMS. Тот же опенкарт. P.S.: даже само словосочетание "конструктор сайтов" несет в себе верный сакральный смысл. Конструктор. набор блоков. кубиков. И если в комплекте конструктора завод\изготовитель положил только 3 колеса, то хрен Вы когда сможете собрать из этого конструктора что-то похожее на 2х-осевой грузовик -только 3х-колесный велосипедик. Мама смотри, я сделалЬ

Можете попробовать "выловить" проблему самостоятельно, например через дебаггер запросов, с помощью которого Вы найдите либо избыточное кол-во запросов со страницы к базе в целом, либо просто парочку шибко долгих, которые и дают задержку. Если дело не в запросах к базе или их кол-ве, то дебажьте \ засекайте время отдельно взятых контроллеров (поиск "microtime" по форуму или гуглу в помощь) Кроме прочего и выше озвученного, пристального внимания заслуживают: - модули случайных товаров - главное меню. Вдруг у Вас там уйма лишней информации: например, "случайно" запрашиваются \выводятся все производители (может быть отображена только их часть а остальные просто будут скрыты\не влезут); или считаются какие-то кол-ва... нелишне проверить html-код менюшки на предмет совершенно лишних узлов - какой-нибудь инстраграм в футере. на некоторых шаблонах "из коробки" этот модуль реализован шибко криво и стабильно дает 10с+ задержки - и еще вагон и целая тележка различных модулей или кусков кода... можно попробовать методом исключения: отключать по очереди все, что отключается и проверять, ушла ли проблема все это, разумеется, если мы говорим о задержке во времени получения html-кода странички (ttfb). Если же речь идет о полной загрузке страницы\работе js-скриптов, то это совсем другая история...