AndreyJ

Небольшое уточнение к моему посту выше — про флаг lazy_load_disabled. Я назвал его «мёртвым кодом», но, разобравшись глубже, это неточно: правильнее — незавершённая заготовка ровно под эту задачу. Само имя выдаёт замысел: пометить картинку как «ленивую загрузку отключили». Уточняю, почему в текущем виде оно не работает — это подсказывает, где механизм не был доведён. Единственное присваивание — в хуке ab__preload hooks/common/image.pre.tpl: {if $restore} {$image_additional_attrs['lazy_load_disabled'] = true scope="parent"} {$restore = false} {/if} Ставится только в JS-режиме ($restore = true лишь когда на входе $lazy_load == true). В нативном режиме, где и возникает проблема с loading="lazy", флаг не выставляется вовсе. Потребитель не реализован. Значение нигде не читается: шифрованных файлов в ab__preload/ab__lazy_load нет, lazysizes 5.3.2 такого атрибута не знает, func.js ab__lazy_load его не проверяет, PHP тоже. И не может быть прочитан ab__lazy_load из-за порядка хуков — он выполняется раньше ab__preload (priority 190000 против 200000), поэтому на момент его работы флага ещё нет. Побочный эффект: render_tag_attrs булев true выводит как голый атрибут, поэтому в JS-режиме флаг протекает в разметку — <img … lazy_load_disabled> (невалидный атрибут, браузер игнорирует). Вывод: проще всего закрыть задачу форсированием loading="eager" в ab__preload (как в предложении выше) — это покрывает оба режима и не зависит от порядка хуков, а присваивание lazy_load_disabled тогда можно убрать (заодно уйдёт мусорный атрибут в JS-режиме). Если же сигнальную модель хочется сохранить, её придётся переносить: сигнал должен выставляться до работы ab__lazy_load, и на его стороне нужен читатель.

Снова приветствую. Тут еще в борьбе с гуглпейджспидом и дерганьем при загрузке нашли момент важный. --- Тема: в нативном режиме ab__lazy_load предзагружаемая картинка получает loading="lazy" — прелоад и ленивая загрузка противоречат друг другу, страдает LCP Оба модуля — ваши, и в связке они не примиряются, когда ab__lazy_load работает в нативном режиме (mode = native). Итог: главное фото товара (а также баннеры и плитки категорий) одновременно: предзагружается: <link rel="preload" as="image" fetchpriority="high" href="…"> (ставит ab__preload); и помечено loading="lazy" (ставит ab__lazy_load). Это прямой антипаттерн: прелоад говорит браузеру «грузи сразу с высоким приоритетом», а loading="lazy" — «отложи». Lighthouse/PageSpeed это ловит («LCP image was lazily loaded»), и предзагрузка фактически обесценивается. Причина (разобрана по коду): Оба модуля вешают хук на common/image.pre.tpl. Шаблонные хуки выполняются в порядке приоритета аддонов (fn.init.php: SELECT … FROM ?:addons … ORDER BY priority; SmartyEngine/Blocks/Hook.php: foreach по аддонам без пересортировки). Приоритеты: ab__lazy_load = 190000, ab__preload = 200000 → ab__lazy_load выполняется ПЕРВЫМ. В нативном режиме хук ab__lazy_load вешает атрибут loading="lazy": {if !$lazy_load} {$image_additional_attrs.loading="lazy" scope=parent} {/if} и при этом НЕ меняет переменную $lazy_load (в true её ставит только JS-режим). Хук ab__preload (выполняется вторым) свою защиту от lazy включает только веткой {if $lazy_load} — истинной лишь в JS-режиме. В нативном режиме $lazy_load = false, поэтому защита не срабатывает: предзагружаемая картинка так и остаётся с loading="lazy". Флаг lazy_load_disabled, который ab__preload при этом присваивает, нигде не читается (мёртвый код) — то есть текущая защита в нативном режиме не делает ничего. Подтверждено на реальных страницах и замерами. На пристинной установке (нативный режим) главное фото товара приходит с loading="lazy" при наличии preload fetchpriority="high" на ту же картинку. Сравнительный A/B (PageSpeed mobile, одна страница, по 2 прогона на режим): нативный режим устойчиво лучше JS-режима (score ~73–78 против 62–72; TBT ~250–380 мс против 510–590 мс — JS-режим грузит основной поток ленивой обработкой ~100 картинок). То есть переключение в JS-режим как обходной путь не подходит — чинить надо в нативном. Предложение (владелец фикса — ab__preload, т.к. он выполняется вторым и уже знает, что картинка приоритетная). В хуке ab__preload/hooks/common/image.pre.tpl, внутри блока принятия решения о предзагрузке, форсировать eager: {if ($ab__ll.mode|default:'') !== 'js'} {$image_additional_attrs.loading = 'eager' scope="parent"} {$image_additional_attrs.fetchpriority = 'high' scope="parent"} {/if} Поскольку ab__preload выполняется после ab__lazy_load, его loading="eager" перекрывает выставленный ранее loading="lazy". Guard !== 'js' оставляет JS-режим без изменений (там ab__preload уже разлочивает картинку через $lazy_load = false, и вмешательство в атрибуты может задеть lazysizes/srcset). Правка покрывает разом главное фото, баннеры и плитки категорий. Мотивация: предзагрузка картинок — ключевая функция ab__preload ради быстрого LCP — в нативном режиме ab__lazy_load сейчас не работает: браузер всё равно откладывает предзагруженную картинку. После правки прелоад начинает выполнять своё назначение, и у пользователей снимается замечание PageSpeed «LCP image was lazily loaded». Минусов нет: правка применяется только к тем картинкам, что ab__preload и так помечает на предзагрузку (приоритетные, первый экран); обычные картинки сохраняют нативный loading="lazy". JS-режим не затрагивается (guard). Проверено: в нативном режиме предзагружаемое главное фото становится eager, прочие картинки остаются lazy; в JS-режиме рендер идентичен прежнему.

Добрый день. Делаем аналитику ГА4 полноценную и она не цепляет вкладки в которых выводятся блоки этого модуля. А они важные. На виду. Добавте плиз хук или может тот экзит лишний и случайно там оказался. Все как обычно проверено кучей изысканий и поиском иных вариантов. но этот самый надежный и феншуйный. Дальше письмо со смыслом. --- Мы используем ваш модуль ab__intelligent_accessories (блоки «Сумісні / Схожі / Похожие товары» на карточке товара) вместе с модулем GA4-аналитики. Зачем пишем. Нам нужно снимать по этим блокам стандартную e-commerce-аналитику Google Analytics 4: view_item_list — показы товаров в блоке (какие сопутствующие товары реально увидел покупатель), select_item — клики по товару из блока. Это наполняет встроенные отчёты GA4 «Список товаров» (Item list), и мы видим, какой из блоков подбора приносит просмотры, клики и в итоге продажи — то есть насколько эффективен ваш модуль в деньгах. Сейчас эти блоки в аналитику не попадают, и мы буквально «слепы» по ним, хотя по категориям/поиску/каруселям всё уже трекается. Техническая причина. Товары вкладки наливаются AJAX-контроллером ab__ia_joins.get_join_products (app/addons/ab__intelligent_accessories/controllers/frontend/ab__ia_joins.php), который завершается через exit; (строка ~89). Из-за exit; обходится штатный механизм пост-контроллеров CS-Cart, и никакой сторонний аддон не может пост-обработать отрендеренный products_scroller (добавить в него разметку для аналитики). Просьба. Добавьте, пожалуйста, точку расширения — хук перед exit;: /** * Fires after the join products scroller is rendered, before the AJAX response is sent. * * @param array $block Block data * @param array $products Products shown in the join tab */ fn_set_hook('ab__ia_joins_get_join_products', $block, $products); exit; (при желании — с guard if (isset($block, $products)) { ... }). Изменение минимальное, логику модуля не меняет — просто даёт штатную точку расширения. Это позволит нам (и другим клиентам) корректно интегрировать аналитику без правок вашего кода. Спасибо!

Приветсвую. Изучите плиз на сколько Клавдия Антроповна говорит по дело. Я со своей стороны тесты погонял, замеры поделал. Вроде не вреть. Это и баг т.к. не работает и предложение как решить. Оно конечно только в связки с ядром сработает. Надеюсь вы со своей стороны простимулируете команду Карта к фиксу. Ну а если нет, то предлагаю добавить этот фикс к вам и информацию в справку модуля, как у вас сделано с модулем Мтеатегов например. Я им тоже написаль. Тема: прелоад шрифтов промахивается мимо query в CSS — шрифт грузится дважды fn_ab__p_get_css_timestamp() формирует query для <link rel="preload"> из собственной метки. Она никогда не совпадает с query того же шрифта внутри скомпилированного файла стилей standalone.*.css, потому что ядро (Tygh\Less::parseUrls) пишет туда компайл-тайм TIME, различный у каждого такого файла. Итог: предзагруженный шрифт браузер скачивает повторно при разборе CSS — прелоад не срабатывает, и вместо ускорения получается лишняя загрузка, то есть противоположное назначению модуля. Предложение: привязать query прелоада к cache_id: $cache_id = fn_get_storage_data('cache_id'); if ($cache_id) { return $cache_id; } return Registry::ifGet('ab__preload.timestamp', 0); и по возможности эскалировать правку в ядро (см. выше) — тогда query прелоада совпадёт и со скомпилированными файлами стилей, а с критическим CSS (если он на cache_id) совпадает уже сейчас. Мотивация: сейчас ключевая ценность модуля — предзагрузка ради быстрого первого рендера — для шрифтов не работает вовсе; после правки модуль начинает делать ровно то, что обещает, и снимает у пользователей замечание PageSpeed по шрифтам. Минусов нет: cache_id стабилен в пределах одной генерации ассетов и бампается при очистке кэша — busting сохраняется, а идентичные шрифты получают единый URL во всех скомпилированных файлах стилей.

Приветствую. В func.php, fn_ab__dotd_get_plural_rule(): if (__('ab__dotd.countdown.seconds',[],'en') === __('ab__dotd.countdown.seconds',[],$lang_code)) { Если язык en в магазине не установлен, этой строки нет в cscart_language_values, а ядро не кэширует отсутствующие langvars — в итоге на каждой странице с блоком «Товара дня» выполняется лишний SQL-запрос, вечно. Воспроизводится на CS-Cart 4.20.1 ULTIMATE (языки uk/ru): дважды открыть страницу с блоком — запрос виден в дебагере оба раза. Обошли так: INSERT IGNORE INTO cscart_language_values (lang_code, name, value) VALUES ('en', 'ab__dotd.countdown.seconds', '[n] second|[n] seconds|[n] seconds'); Предложение: кэшировать результат функции в static по $lang_code или не запрашивать перевод неустановленного языка. Спасибо!

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

ага. может даже и писал им когда то про это.. попробуйте еще вы ))

/app/functions/fn.products.php вот тут сделать вот так. Уже правда и не помню где это взял и есть ли другой способ.

В карте колво товаров по идиотски считается, там количество колонок кажется на 4 умножается. Посмотрите на его форуме про это. При каждой обнове этот кусочек кода правлю. Про баннеры есть настройка учитывать их в количестве товаров или нет. Что то такое.

я так не считаю, но удержаться невозможно АБ Лучшие!

@ab.support.serhii понял. Думал что может я что то упускаю. Удивлен, что за столько лет это никому не понадобилось. Спасибо. Скажите хоть а зачем город отправления зафиксировали жестко? В чем тут логика?

Приветствую. Начали атки вникать в автоматизацию вместо работы в кабинете НП. Сергей, помогите разобраться. Лучше под спойлер уберу)

Приветствую. Мы тут ще чуток с Клавдией нарыли. перепроверьте плиз и если она не врет, то добавте. --- Здравствуйте! При генерации карты сайта (CS-Cart 4.20.1, PHP 8.x) в лог пишется предупреждение: Deprecated: strpos(): Passing null to parameter #1 ($haystack) of type string in .../ab__advanced_sitemap/Tygh/Addons/Ab_AdvancedSitemap/XmlBuilder.php on line 250 Причина. В методе generateLinks() переменная $link объявляется только внутри веток switch. Для типов объектов, попадающих в ветку default и не реализующих хук sitemap_link_object (например, объекты от ab__geo_pages, которые формируют ссылку через пост-хук sitemap_link), $link остаётся неинициализированной (null), и строка strpos($link, '?') получает null. На состав карты это не влияет (ссылки добавляются корректно через sitemap_link), но засоряет логи. Предлагаемое исправление — инициализировать переменную перед switch: protected function generateLinks($object_type, $value, $lang_code = '') { $link = ''; // <-- добавить switch ($object_type) { ... } $sep = strpos($link, '?') === false ? '?' : '&'; ... Просьба учесть в следующем обновлении модуля. Спасибо!

@ab.qa.trsспасибо. помню про эту возможность. Тут основное про "как на Розетке". Не спроста оно там.

Предлагаю такое внедрить в теме, как на Розетке. Когда нет отзывов, то не рисовать пустые звезды, а писать - Оставить отзыв.

Спасибо. Значит буду оформлять предложение. Слишком разная логика в ОВЛ и Фотосвайре вашем.

Приветствую. Не знаю так задумано или таки баг. Сделайте плиз одинаковое поведение для стрелки и для жеста . Сейчас если стрелку на последнем фото нажать, т опромотается до 1го. Если жестом тянуть, то ничего не происходит. Надо чтобы было всегда по кругу фото. Это задерживает клиентов на странице. И Гугл это видит и подымает.

Ого. Я даже не знал про существование этой настройки... Вот я ж говорю, что ваши ответы очень полезны!

@ab.support.serhiiну блииинннн. такое сложно отслеживать. а это тоже что и или иначе расшифровывается? )) А то я все посты вот пошел пересчитал лайки ))) И тогда дизлайки ставьте если не принято. Конечно текстом было бы понятнее. У вас прекрасно получается объяснять где мы не правы и это реально помогает и направляет в нужное русло! Ну и как то человечнее.

Так у меня и выбран Трехколоночный. Не залипает. Если блок Мотивации выходит за нижнюю границу экрана. Это будет иделаьно.

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

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

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

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

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