markimax

А ну понятное дело! А сейчас какая текущая?

Руслан - loader стандартный, мы уже об этом говорили. Единственное что он делает подгружает хук, который. ... запускает стандартные модули, но пересчитывает результаты. Так делается везде и в presto и ,magento. Кто не понимает - могу обьяснить. ( __call) Может суть была в той "опечатанной" версии, где была закомментрированна нужная строка. Chenom0r какая версия модуля стоит? И seo pro модуль не подменяет, а модульный работает после seo pro и обрабатывает только record/blog и record/record

А где вы покупали? На какой e-mail? Только в ЛС А то бывали случаи что покупали на пиратских сайтах

Ну во первых скачайте последнюю версию и установите - там каптча совершенно переделана, насчет HTTP_USER_AGENT - вставлю проверку И посмотрите папку font для каптчи- может не все переписали

url ? ..../?rss=2.0

Да, однозначно. Причем так делают все и google и все нагруженные проекты, к этому значит уже привыкли, а если привыкли и "знают" - значит так и надо сделать

ocTeam ;) А не хотите ввести сиcтему хуков в ocStore на базе __call Чтобы было все стандартизовано. В папку залили хук и он следит за методами моделей, библиотек, переопределения контроллеров и т.п.

Да - только "последней" не будет

В принципе я фикс уже почти написал хуками. Считает только для пагинации, осталось только окно ввести в ocStore для пагинации (LIMIT в запрос и через jquery убирать с пагинации "последнюю страницу)), чтобы перебирались не все ряды товаров в категории (вдруг их там более 1000), а только дозволенные окном Вообще не мешало бы в ocStore ввести подключение хуков и систему хуков, как я реализовал в своем модуле

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

Не - это уже будет привязка к конкретному полю e-mail. ;( Если так делать многие начнут просить галочки для полей например "логин VK" и т.п. Или вы имеете ввиду к любому полю т.е. галочка "обязательное" и вторая настройка - для зарегистрированных - " не обязательное"

Да кеширование не выход, если стандартное - оно не долго живет, надо подключать свою систему кеширования Вообще система кеширования OC очень слабенькая

Да, надо сделать в ocStore - что-то типа настройки пагинации для нагруженных проектов там всего-то LIMIT в запрос добавить на определенное окно, т.е. если количество выводимых товаров 20 и окно на 5 страниц, то LIMIT 100, тогда при 30 товаров все будет ОК - покажет только нужное количество страниц - 2, а если больше то 1 2 3 4 5 ... Надо только шаблон пагинации подправить

Во! Надо сделать настройку - показывать поле в "выводе" (вкл/выкл) - логично. Т.е. тогда поле будет видно только админу Спасибо за наводку!

Да подсчет количества - это всегда г...е дело. Количество надо кешировать или как делают по другому - делают окно, например Limit и типа пагинация 1 2 3..... если много товаров или 1 2 если 2 страницы влезло в окно, некоторые просто делают кнопку дальше а окно делают на 2 страницы Тогда всё очень быстро летает на нагруженных проектах. Посмотрите как у youtube например https://www.youtube.com/results?search_query=%D0%BC%D1%83%D0%B7%D1%8B%D0%BA%D0%B0&sm=3 Там "окно" - 7 страниц, т.е. если в пагинации убрать "последнюю" то запросто можно использовать окно в пагинации если не использовать подсчет количества в категориях то на нагруженных проектах всё будет летать

Это сколько товаров в БД и в этой категории? rows - Количество рядов, которые MySQL необходимо проверить, для обработки запроса.

Из модели catalog/product public function getTotalProducts

Вот EXPLAIN getTotalProducts()

Не выход запрос все равно будет перебирать всю таблицу товаров (ну вот такой он сложный), а представьте их там порядка 10`000 - ... :cry:

Это "якори" для того чтобы виджеты на одной странице не "переругались" и не перепутались. Представьте как бы выглядел код например если на одной странице кнопки "Вопрос в тех поддержку" и "Заказать обратный звонок" с одинаковым кодом и классами (а js код привязан к некоторым классам, и как быть? Под каждый виджет свой шаблон, тогда и делать JS надо под каждый шаблон, и разрастается шаблон, а так, с префиксом, все унифицировано и JS загружается отдельным файлом один раз - снижая нагрузку на сервер, так как следующий раз берется из кеша. ;) Поэтому и бы введен префикс который строиться на основе данных виджета и "соли" Смотри в сторону шаблона переменная $prefix

https://opencartforum.com/topic/30184-ocstore-%D1%82%D0%BE%D1%80%D0%BC%D0%BE%D0%B7%D0%B8%D1%82-%D0%BF%D1%80%D0%B8-%D0%B2%D1%8B%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%BD%D0%BE%D0%BC-%D0%BF%D0%BE%D0%B4%D1%81%D1%87%D0%B5%D1%82%D0%B5-%D1%82%D0%BE%D0%B2%D0%B0%D1%80%D0%BE%D0%B2/ И я считаю нельзя использовать в модели catalog/product - getProducts SELECT SQL_CALC_FOUND_ROWS можно прозевать и наступить на грабли при большом количестве товаров

Есть еще настройка в самой записи Это виджет - как бы общие настройки, а к конкретным записям можно сделать свои настройки основные, сделано так чтобы можно было разделять в одном виджете для разных записей возможность комментирования

Там не только в категориях считает, но считает и подсчет в подкатегориях 196 строка product/category.php foreach ($results as $result) { $data = array( 'filter_category_id' => $result['category_id'], 'filter_sub_category' => true ); $product_total = $this->model_catalog_product->getTotalProducts($data); Зачем? Если выключен подсчет А для пагинации идет код следом $this->data['products'] = array(); $data = array( 'filter_category_id' => $category_id, 'filter_filter' => $filter, 'sort' => $sort, 'order' => $order, 'start' => ($page - 1) * $limit, 'limit' => $limit ); $results = $this->model_catalog_product->getProducts($data); //Вызов метода getFoundProducts должен проводится сразу же после getProducts //только тогда он выдает правильное значения количества товаров $product_total = $this->model_catalog_product->getFoundProducts();

Да, в подкатегориях то зачем считать, если выключен подсчет категорий? Представь тот сложный запрос на 10`000 товаров - я проверял - ложит сайт сразу