bobrovantig

Добрый день. Ваш функционал отложенной загрузки секций позволяет повысить скорость загрузки страницы, чем хочется пользоваться. Однако было бы здорово добавить отложенную загрузку не только секций в макете, но и вкладок товара. Например, я перенёс недавно карусели товаров с аналогами и принадлежностями товаров из блоков в макете товара во вкладки товара, т.к. это позволяет нагляднее отобразить наличие этих полезных подборок товаров сразу при изначальном просмотре карточки товара и быстро на них переключаться: Но отложенную загрузку для таких вкладок и блоков настроить сейчас нельзя. Было бы здорово иметь такую возможность, такого плана: Сможете такое добавить? Было бы здорово очень.

Т.е. надо не просто категорию выключать, а ещё и сами товары внутри категории отключать. Ок, понял, спасибо.

Ещё вопросы касательно выключенных товаров/категорий: Тратит ли время модуль на выключенные товары или игнорирует их? Тратит ли время модуль на включенные товары, но в выключенных категориях, или игнорирует их? Например, у меня есть большая опорная категория, в которой я настраиваю связи. А внутри этой большой опорной есть несколько подкатегорий, часть из которых выключена. Будет ли модуль тратить на них ресурсы?

Спасибо за ответ, но сильно понятнее не стало, если честно:) Ну т.е. чем больше товаров нужно отфильтровать, тем больше условий мне вообще-то нужно добавить) Тут какой-то взаимоисключающий совет: нужно устанавливать больше условий, но чем количество этих условий судя по ответу влияет на скорость генерации) я, к сожалению, не умею пользоваться БД и смотреть там что-то. Ладно, буду как-то пытаться по ощущениям всё настраивать. Вообще инструмент топовый, конечно, но на большом объёме данных у меня перестал работать, к сожалению.

Добрый день. Использую ваш модуль. Столкнулся с проблемой, что на большом объёме процесс формирования кеша длится либо очень долго (несколько часов), либо в принципе не выполняется в конце концов. Хочу понять, как оптимизировать этот процесс и от чего зависит быстродействие. Уточните, пожалуйста: 1. Быстродействие зависит от количества товаров в связанной категории (откуда подбираются товары) или от количества в опорной категории (для которой подбираются товары). От какой именно категории? 2. При добавлении условий, которые по идее сужают перечень подходящих товаров, эти условия за счёт уменьшения подходящих товаров ускоряют работу или наоборот каждое условие добавляет времени к вычислению? Ну т.е. мне лучше максимально добавлять побольше условий, чтобы по лишним товарам не проходился модуль, или наоборот лучше как можно меньше условий? 3. Про параметр limit поясните, не очень понимаю. В вашем примере написано: 5 23 * * * php /path/to/admin.php --dispatch=ab__ia_data.cron_update_cache --limit=5 --switch_company_id=* Во-первых, чтобы каждые 10 минут выполнялся, то наверное нужно что-то типа того: /10 * * * * php /path/to/admin.php --dispatch=ab__ia_data.cron_update_cache --limit=5 --switch_company_id=* Во-вторых, не очень понимаю вот что: например, у меня всего 100 связей. Скрипт как-то понимает, что он в предыдущий раз обработал первые 5 связей, и при каждом последующем запуске будет обрабатывать уже следующие 5 из 95 оставшихся? Потом следующие 5 из 90 оставшихся и так далее? Пока не обработает все, а потом начнёт обрабатывать по второму кругу и т.д.? Ещё интересно, как мне в принципе оценить, какое адекватное количество нужно за раз проставлять в параметре limit. По идее хочется каким-то образом знать общее количество связей, чтобы я понимал, что например, у меня 7000 связей, а я хочу, чтобы у меня все связи обновились не позднее, чем за неделю, т.е. за день мне нужно, чтобы обновлялось 1000 связей. И тогда мне запускать крон каждый час с лимитов limit=1000/24=42. Но проблема, что я не знаю, как понять, сколько у меня всего связей, чтобы эти расчёты выполнить. А то я ставлю сейчас какой-то limit, а с моим количеством связей ему нужно полгода, например, чтобы их все по первому кругу только обработать.

Ок, принято.

Добрый день. Обнаружил проблему, что шаблон для Яндекс.Маркет некорректно прописывает доступность товара, а именно она всегда true даже для случаев, когда товара нет в наличии или его меньше, чем min quantity, например. Полез разбираться в формуле, потратил полдня, чтобы понять, как она работает и какая в неё логика заложена из-за довольно длинной формулы, обилия условий "не" и т.п. Для этого решил разбить её на несколько частей и проверять по отдельности каждое условие (см. код с комментом ниже) и выявить, какое из них косячно отрабатывает. В общем, заменил в паре место "и" на "или", где-то убрал или наоборот добавил "не". В общем, можете сравнить мой код и оригинальный. Т.к. нет описания, что скрывается под некоторыми переменными, то может я что-то не совсем корректно исправил и правильнее как-то по-другому её переписать, но по крайней мере у меня с таким кодом сейчас корректно определяется доступность товара. Проверьте, пожалуйста. Мой код: {foreach $products as $product} {* DELETE after checking *} {if !($product.zero_price_action === "R" && $product.price == 0)}true1 {else}false1 {/if} {if !($settings.General.inventory_tracking !== "Y")}true2 {else}false2 {/if} {if !($settings.General.allow_negative_amount !== "Y")}true3 {else}false3 {/if} {if !(($product.amount <= 0 || $product.amount < $product.min_qty) && $product.tracking != "ProductTracking::DO_NOT_TRACK"|enum)}true4 {else}false4 {/if} {if !($product.is_edp == "Y")}true5 {else}false5 {/if} {* DELETE after checking *} {$available = !($product.zero_price_action === "R" && $product.price == 0) && !($settings.General.inventory_tracking !== "Y" || $settings.General.allow_negative_amount !== "Y" || (($product.amount <= 0 || $product.amount < $product.min_qty) && $product.tracking != "ProductTracking::DO_NOT_TRACK"|enum) || $product.is_edp == "Y")} {strip}<offer id="{$product.product_id}" available="{if $available}true{else}false{/if}" ... Оригинальный код: {foreach $products as $product} {$available = !($product.zero_price_action === "R" && $product.price == 0) && !($settings.General.inventory_tracking === "Y" && $settings.General.allow_negative_amount !== "Y" && (($product.amount <= 0 || $product.amount < $product.min_qty) && $product.tracking != "ProductTracking::DO_NOT_TRACK"|enum) && $product.is_edp !== "Y")} {strip}<offer id="{$product.product_id}" available="{if $available}true{else}false{/if}" ...

нашёл, спасибо

Добрый день. Подскажите, а как проверить, что контент реально закрыт от ботов? я, например, характеристики закрыл, обернув их в файле шаблона в такой код: <!--googleoff: all--><!--noindex-->...<!--/noindex--><!--googleon: all--> и это реально видно в коде страницы и хотя бы можно как-то проверить. А вот как в принципе работает модуль Антибот не понимаю, т.к. в коде страницы общепринятые теги закрытия от индекса не вносятся, а как ещё понять, что реально закрылось, не понятно. Поясните, пожалуйста.

Добрый день. Включил ваш модуль. Есть вопросы: Как массово (для всех имеющихся категорий) активировать настройку, которая создаёт отдельную страницу с отзывами по категории? У меня есть экспорт категорий на сайте, но там этот параметр нельзя экспортировать/импортировать. Как для всех вновь создаваемых категорий сделать, чтобы эта галочка активировалась сразу по умолчанию? Я если честно пока не вижу причин, почему эту нужно активировать только точечно вручную и что будет, если для всех категорий это будет активировано. Ладно бы создавались пустые страницы с отзывами, если в категории нет товаров с отзывами, так ведь предусмотрено, что такие пустые страницы не создаются и проблем соответственно быть не должно. А какие ещё риски и проблемы есть - я не вижу. В любом случае, мне кажется нужно какую-то опцию автоматической/массовой активации этой опции сделать.

Если скрыть все языки и валюты, чтобы остались только по одному, то селектор логично скрывается в хедере и во fly-menu. Но при этом во fly-menu остаётся большое пустое поле под эти блоки, хотя они скрыты. Проверено на демо. Если прям удалить эти блоки валют и языка из fly-menu, то это пустое поле пропадает. Но ведь это не совсем правильно.

Добрый день. Замечено ещё ранее, не конкретно в этом релизе темы, но всё же: Если скрыть все языки и валюты, чтобы остались только по одному, то селектор логично скрывается в хедере и во fly-menu. Но при этом во fly-menu остаётся большое пустое поле под эти блоки, хотя они скрыты. Проверено на демо: https://abd-79e7973164.demos.abt.team/ Если прям удалить эти блоки валют и языка из dly-menu, то это пустое поле пропадает. Но ведь это не совсем правильно.

Добрый день. Спасибо за обновление. Заметил проблему, что кнопка «добавить в корзину» не принимает цвет, выбранный в цветосхеме. На демо тоже вот воспроизвел: https://abd-79e7973164.demos.abt.team/admin.php Тикет создал. Заодно напомните, пожалуйста, где меняется содержимое блока "Контакты" в нижнем липком меню на мобиле.

На маркете есть пара модулей других разработчиков, которые отдают роботам параметр Last-Modified + 304 Not Modified. Это не про sitemap, но в целом процесс мне кажется аналогичный, т.е. они как-то этот параметр смогли вылавливать и передавать, я думаю и вы сможете в сайтмап аналогично это передавать.

А что, при изменении атрибутов товара страница не меняется что ли? Не вижу противоречия. Какой-то контент на странице поменялся (то, что я перечислил выше), страница соответственно тоже изменилась.

Почему, можете пояснить, пожалуйста?

я не специалист, но мне кажется достаточно отслеживать изменение только: наименование товара (Product name) фотографии цена мета-теги (тайтл, дескрипшн) заголовок h1 краткое и полное описание на странице товара Добавить какую-то доп. таблицу в БД, в которую будет записываться дата изменения этих параметров товара. И эту дату передавать в модуле сайтмап. Если там пусто, то можно дату создания товара. Остальные динамические блоки отслеживать не надо.

Добрый день. От СЕО-специалиста поступил комментарий, что в sitemap нужно в параметре lastmod прописывать дату реального изменения страницы (когда контент страницы изменился, например), а не дату генерации sitemap (сейчас именно так работает). Сейчас получается, что у всех страниц прописывается одна и та же дата (просто дата генерации sitemap), что не есть хорошо. Смысл этого параметра тогда теряется, если он для всех страниц одинаковое значение всегда имеет. Смысл в том, чтобы не расходовать краулинговый бюджет, и боты поисковых систем проверяли только обновленные страницы, а не все, находящиеся в sitemap. Когда сайт до 100 страниц это не имеет значения. Для магазинов с 100K+ товарами это очень актуально. Можно реализовать это замечание?

Добрый день. От СЕО-специалиста поступил комментарий, что в sitemap нужно в параметре lastmod прописывать дату реального изменения страницы (когда контент страницы изменился, например), а не дату генерации sitemap (сейчас именно так работает). Сейчас получается, что у всех страниц прописывается одна и та же дата (просто дата генерации sitemap), что не есть хорошо. Смысл этого параметра тогда теряется, если он для всех страниц одинаковое значение всегда имеет. Смысл в том, чтобы не расходовать краулинговый бюджет, и боты поисковых систем проверяли только обновленные страницы, а не все, находящиеся в sitemap. Когда сайт до 100 страниц это не имеет значения. Для магазинов с 100K+ товарами это очень актуально. Можно реализовать это замечание?

Добрый день. От СЕО-специалиста поступил комментарий, что в sitemap нужно в параметре lastmod прописывать дату реального изменения страницы (когда контент страницы изменился, например), а не дату генерации sitemap (сейчас именно так работает). Сейчас получается, что у всех страниц прописывается одна и та же дата (просто дата генерации sitemap), что не есть хорошо. Смысл этого параметра тогда теряется, если он для всех страниц одинаковое значение всегда имеет. Можно реализовать это замечание?

Добрый день. Очень не хватает плейсхолдера компании, который задаётся в настройках витрины. Есть плейсхолдер названия витрины [storefront], но мне его неудобно использовать, т.к. название витрины - это одно, а название компании - это другое. Например, витрина у меня называется Компания филиал KZ , а при этом сама компания называется ТОО "Компания". И когда я задаю мета-тег товара, например: [{fvalue_2661}] [{fvalue_2662}] [product_brand] [{fvalue_59}] по цене [product_price_nocurrency] [currency_nohtml] с доставкой по [ГОРОД_ДП] и Казахстану. Описание, характеристики, фото в каталоге на сайте компании [storefront] то мне нужно, чтобы в конце подставлялось ТОО "Компания", а не Компания филиал KZ. Можете добавить какой-нибудь плейсхолдер [company], например? Сильно поможет.

Добрый день. Очень не хватает плейсхолдера компании, который задаётся в настройках витрины. Есть плейсхолдер названия витрины [storefront], но мне его неудобно использовать, т.к. название витрины - это одно, а название компании - это другое. Например, витрина у меня называется Компания филиал KZ , а при этом сама компания называется ТОО "Компания" . И когда я задаю мета-тег товара, например: [{fvalue_2661}] [{fvalue_2662}] [product_brand] [{fvalue_59}] по цене [product_price_nocurrency] [currency_nohtml] с доставкой по [ГОРОД_ДП] и Казахстану. Описание, характеристики, фото в каталоге на сайте компании [storefront] то мне нужно, чтобы в конце подставлялось ТОО "Компания", а не Компания филиал KZ. Можете добавить какой-нибудь плейсхолдер [company], например? Сильно поможет.

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

Также всё в том же своём тикете писал, что в описаниях характеристик периодически появляется какой-то полупрозрачный фон. Тоже к сожалению не исправлено. Вот воспроизвёл на демо: https://abd-c8408e1b9b.demos.abt.team/ru/elektronika/igrovye-pristavki/pristavki/playstation-4/

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