AndreyJ

Приветствую. На странице акции товары ползут вниз. Посмотреть можно тут. https://unitheme.net/ab-demo-promotion-its-black-friday-all-month-long-with-new-deals-each-week./ Дайте фикс, пожалуйста.

Дорогие разработчики. Не пытаюсь вас заспамить. Лишь пробую ускорить Карт. В меру своих познаний. Все эти предложения тестировались Клавдией на девкопии сайта по нескольку раз и с кучей допзапросов. Поэтому надеюсь, что ее выводы таки верны. Прошу вас перепроверить и внедрить. Спасибо. Extended Metadata — запрос диапазона цен выполняется всегда, даже когда не нужен (когда переменные с ценами НЕ используются в метатегах) Файл: app/addons/ab__extended_metadata/func.php (две правки: стр. ~205 и ~114) Почему это проблема: хук fn_ab__extended_metadata_get_products безусловно выполняет SELECT MIN/MAX(prices.price) (проход по тысячам строк) на каждой странице с JOIN цен — даже когда плейсхолдеры [min_price]/[max_price] в meta-шаблонах не используются (а это большинство магазинов). Причём meta генерируются на каждом запросе (хуки dispatch_before_display и ab__sf_category_preparing_data_post не кешируются) — то есть запрос идёт постоянно, а его результат чаще всего просто выбрасывается. Решение — ленивое вычисление: считать только когда плейсхолдер реально найден в финальной строке meta. В get_products сохранять параметры выборки (только для основного листинга), а сам запрос с кешем — в блоке type === 'price' функции fn_ab__emd_replace_placeholders: // get_products: $current_dispatch = Registry::get('runtime.controller').'.'.Registry::get('runtime.mode'); if (!empty($params['dispatch']) && $params['dispatch'] === $current_dispatch && in_array($params['dispatch'], $allowed_dispatches)) { Registry::set('runtime.ab__emd_price_query', ['join'=>$join, 'condition'=>$condition]); } // replace_placeholders, блок 'price': $search_obj = Tygh::$app['view']->getTemplateVars('search'); if (!isset($search_obj['ab__min_price']) && ($pq = Registry::get('runtime.ab__emd_price_query'))) { $key = 'ab__emd_price_range_'.md5($pq['join'].$pq['condition']); Registry::registerCache(['ab__extended_metadata',$key], ['product_prices','products','ult_product_prices'], Registry::cacheLevel('user'), true); $range = Registry::get($key); if (!is_array($range)) { $range = db_get_row('SELECT MIN(prices.price) as ab__min_price, MAX(prices.price) as ab__max_price FROM ?:products as products ?p WHERE prices.price > 0 ?p', $pq['join'], $pq['condition']); Registry::set($key, $range); } Tygh::$app['view']->assign('search', array_merge((array)$search_obj, (array)$range)); } Почему так: заранее определить «нужен ли запрос» нельзя — плейсхолдер может быть в трёх источниках (настройки/индивидуальные meta/паттерны). А в момент замены строка уже финальная — это единственное надёжное место. Ключ кеша включает выборку (для SEO-страниц учитывает фильтр и категорию). Эффект: на страницах без плейсхолдеров цены запрос исчезает полностью; с ними — один раз + кеш.

Дорогие разработчики. Не пытаюсь вас заспамить. Лишь пробую ускорить Карт. В меру своих познаний. Все эти предложения тестировались Клавдией на девкопии сайта по нескольку раз и с кучей допзапросов. Поэтому надеюсь, что ее выводы таки верны. Прошу вас перепроверить и внедрить. Спасибо. Файл: app/addons/ab__seo_filters/Tygh/ABSF.php — _get_hash_combos_condition (стр. 178) Почему это проблема: при генерации SEO-фильтр страницы запрос SELECT IFNULL(field_type,0) FROM ?:product_filters WHERE filter_id=?i выполняется в цикле без кеша. На реальной странице мы намерили 116 повторов для одного filter_id=35, 69 — для filter_id=26, суммарно ~185 одинаковых запросов. Тип фильтра не меняется — 184 из 185 обращений лишние. Это классический N+1: каждый запрос дешёвый, но сотни round-trip к БД на каждом хите SEO-страницы складываются в заметную нагрузку (а SEO-страниц у магазина тысячи). Решение — статический кеш в рамках запроса: static $field_type_cache=[]; if (!isset($field_type_cache[$filter_id])) { $field_type_cache[$filter_id]=db_get_field('SELECT IFNULL(field_type,0) FROM ?:product_filters WHERE filter_id=?i',$filter_id); } if ($field_type_cache[$filter_id]) { + ~185 запросов → 1 на уникальный filter_id. Всего SQL-запросов на SEO-странице: 660 → 475 (вдвое меньше обращений к БД).

@a.stepanovna легкий скроллер так не умеет кажется. Он супербыстрый и не функциональный.

Приветствую. Клавдия хочет предложить небольшую оптимизацию хука генерации превью в теме Unitheme2 (app/addons/abt__unitheme2/func.php). Даже прям настаивает. говорит несколько раз перепроверила. Гооврит уууххх как все ускорится, т.к. непрозрачных изображений 99% обычно. Суть Хук fn_abt__unitheme2_generate_thumbnail_post нужен для пересоздания превью прозрачных изображений (чтобы сохранить альфа-канал). Однако сейчас он первой же строкой вызывает fn_get_image_size() (а внутри — finfo_file(), чтение файла оригинала) для каждого изображения, и лишь затем проверяет флаг прозрачности: function fn_abt__unitheme2_generate_thumbnail_post($th_filename,$lazy,$image_path,$width,$height,$image){ list(,,,$tmp_path) = fn_get_image_size(Storage::instance('images')->getAbsolutePath($image_path)); if (!empty($tmp_path) && ( (!empty($image['transparent']) && $image['transparent'] == YesNo::YES) || (!empty($image['icon']['transparent']) && $image['icon']['transparent'] == YesNo::YES) )) { // пересоздание превью — только для прозрачных } } Поскольку признак прозрачности уже доступен в $image['transparent'] (поле transparent в cscart_images), чтение файла для непрозрачных изображений можно не выполнять. Это особенно заметно при включённом lazy_thumbnails: ядро в этом режиме намеренно откладывает работу с файлами, но хук вызывается всегда и читает оригинал на каждое изображение. Предложение — проверять флаг прозрачности до чтения файла: function fn_abt__unitheme2_generate_thumbnail_post($th_filename,$lazy,$image_path,$width,$height,$image){ if ( (empty($image['transparent']) || $image['transparent'] != YesNo::YES) && (empty($image['icon']['transparent']) || $image['icon']['transparent'] != YesNo::YES) ) { return; } list(,,,$tmp_path) = fn_get_image_size(Storage::instance('images')->getAbsolutePath($image_path)); if (!empty($tmp_path)) { // оригинальная логика пересоздания превью для прозрачных } } Логика для прозрачных изображений не меняется, а для остальных пропускается лишнее чтение файла. Просьба рассмотреть возможность включить такую проверку в тему. Спасибо!

Приветствую. Сергей, это не я, это все Клава. Тестирую переход на 8.3. Передайте по инстанциям, пожалуйста. В аддоне ab__category_banners обнаружена проблема совместимости с PHP 8.2+. Файл: app/addons/ab__category_banners/func.php, строки 364 и 414 Ошибка: PHP Deprecated: mb_convert_encoding(): Handling HTML entities via mbstring is deprecated; use htmlspecialchars, htmlentities, or mb_encode_numericentity/mb_decode_numericentity instead Причина: функция mb_convert_encoding() с параметром 'HTML-ENTITIES' объявлена устаревшей в PHP 8.2 и будет удалена в PHP 9.0. Исправление (в обоих местах заменить): // Было: mb_convert_encoding($html, 'HTML-ENTITIES', 'UTF-8') // Стало: mb_encode_numericentity($html, [0x80, 0x10FFFF, 0, ~0], 'UTF-8') Просьба включить исправление в следующее обновление аддона.

Приветствую. Тестирую переход на 8.3. Вот такое пока нашлось. Добрый день. В аддоне ab__geo_pages обнаружена проблема совместимости с PHP 8.1+. Файл: app/addons/ab__geo_pages/func.php, строка 278 Ошибка: PHP Deprecated: Automatic conversion of false to array is deprecated Причина: функция fn_ab__gp_get_location() может вернуть false, после чего код пытается записать $location_data['seo_name'] = '' напрямую в false. В PHP 8.1 это deprecated, в PHP 9.0 станет Fatal Error. Исправление: // Было: if (empty($location_data)) { $location_data['seo_name'] = ''; // Стало: if (empty($location_data)) { $location_data = []; $location_data['seo_name'] = ''; Просьба включить исправление в следующее обновление аддона, так как при переходе на PHP 9.0 это вызовет критическую ошибку.

имхо вот так вполне симпатично

т.е. желтая "стена" и выросла за 4 дня до обновления. не знаю как это интерпритировать

Вы тему и Карт 11 марта обновляли?

@djavaПица Пица это не феншуй. 2 заголовка.

Проблема не уходит. Обновился 24го числа. Даже чуть хуже стало.

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

Оооо, так вы таки отслеживаете больнице по палате на форуме Карта)))

Точно на андройде? Форум Карта гудит про проблему с айфонами. И у нас такое было. Решилось перенастройками сервера.