AndreyJ

@ab.support.serhiiспасибо. скажите мне тогда плиз записали ли вы Предложения, которые я в субботу и воскресенье делал? Там как определять? Какие лайкнули, то записано, а если не лайкнуто то нет? п.с. я без наездов если что. а то как то грубовато выглядит

Не прошу отчет. Только чтобы сказали принято или нет. И будет ли когда то в будущих версиях. Форум. Поймите меня тоже правильно. Нужен фидбек по запрасом, чтобы понимать как действовать дальше. Принято ли предложение как общеполезное и будет внедрено или даже не ждать и идти к вам с оплатой как за доработку. В основном я на форум и пишу то что считаю общеполезным, а уже с доработками иду к РМу. Пример Репрайсер. Так что моя совесть чиста))

Вы ток напишите плиз приняли или надо еще поуговаривать и добавить аргументов. Понятно, что сиюминутного внедрения я тут не жду, может пока сам ченить навайбкодю. Но просто для понимания, что идея зашла и будет реализована. Спасибо. Сергей и по остальных запросам, которые я на выходных писал пожалуйста дайте фидбек в обозримом будущем. Сильно не тороплю. А то я потом снова забуду свои запросы и буду заново писать )))

Изменения в существующей функциональности: [*] На странице товара при активной настройке "Липкие колонки" для фиксируемой колонки сделано выключение залипания в ситуации, когда высота колонки превышает размеры окна, таким образом исключая недоступность нижних элементов в колонке. Снова вернулось это поведение. Вы ж его уже вроде назад отмотали. В прошлой версии колонки уже прилипали и на ноутбуках, а теперь снова как написано выше. Уже и не пойму как задумывается, но пожалуйста сделайте чтоб прилипало вне зависимости от размера экрана. Как это было много лет, потом на пару версий убрали, потом снова вернули и теперь опять убрали. Как это было до обновы. На странице тогда всегда самое важное и про акции и про кнопку Купить, а в противном случае справа просто много пустоты. Может лучше уже и опционально. И скажите плиз как сейчас это пофиксить. Спасибо.

Приветствую. Возможно это и не баг, но имхо упущение точно. Язык витрины по умолчанию Украинский. Но в карте сайта страницы по умолчанию русские. Возможно т.к. сам язык по умолчанию стоит русский в Языках. Но хз как его вообще поменять по умолчанию. В общем логично, чтобы Карты сайта ориенторовалась на настройку Язык витрины по умолчанию. Сделаете так?

Обновился. Все равно ползут вниз. Тикет создал. Кеш сайта чистил, кеш сервера чистил, кастомные стили удалял.

Тоже прочитал справку. Но думал может модуль как то гугл "обманнывает" и просто у меня что то отпало. Решил переспросить. Спасибо за ответ.

Коллеги, в продолжении изысканий в Сеарч Консоле гугла, выяснил что ни одно видео на сайте он не индексирует. Посмотрите пожалуйста у кого еще Ютуб не "замедляли"как у вас дела с этим обстоят. Меню Индексирование - Видео. @a.stepanovna@djava По ссылке, которую он там дал такое описание. @ab.support.serhii обратите внимание разработчиков, пожалуйста. А то как так нет видео на странице... Оно и вместе с фото товара есть и ниже в разделе видео.

Оооо. Я как то пропустил, что уже есть С. У меня Б, подписанная как А.

Да. Там и заметил. И сразу пошел тестить на демку.

Приветствую. На странице акции товары ползут вниз. Посмотреть можно тут. 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в теме на форуме Карта посмотрите моее сообщение. Там поддержка хостинга подняла какте тотлиммты и проблема ушла. На сайте и гугл аналитика есть и тег менеджер. Дело в каких то ограничениях хостинга. Сейчас на фаствпс. Неделя переписок с ними принесла плоды, которые и указаны в сообщении.

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

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