RGB

Лицензионная, а у вас?

Модули, выложенные на варезе o***d.net, такие же официальные, как авторские сборки Windows на рутрекере

Доброго, убрать - редактированием файла catalog\view\theme\moneymaker2\template\common\header.tpl Перенести - можно с помощью расширения меню категорий https://2.mnmkr.com/documentation/#setup-header-megamenu

Добавлена адаптация для бесплатного модуля "SEO мультиязык для сайта, код языка в url и правильный hreflang" Пока изменений для полноценного обновления недостаточно, так что кому нужна адаптация - пишите в ЛС

В таком случае вместе с вышеуказанным кодом удалите его аналогичную часть в файле catalog\view\theme\moneymaker2\template\product\product.tpl

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

А где там заголовочный тег H2?

Доброго, в файле catalog\view\theme\moneymaker2\template\product\product.tpl и после изменений не забудьте обновить кеш модификаторов

Шаблон же не может за вас обеспечить привлечение траффика на карточки товара. Прошу простить за лирическое отступление и раздачу непрошенных советов, но у вас основной упор должен быть именно на них, т.е. желательно направлять траффик именно туда, тогда и проблемы попадания в карточку товара не возникнет, и конверсия будет выше. Не помню точных цифр, но для сравнения у нас около 70% траффика направлялось именно на товары, остальное на категории, в крупных магазинах процент и того больше, насколько мне известно. Почему не видно и почему не спасают? Аналогично карточки товара с таймером, вы можете включить вывод конкретной скидки: Либо, как я писал выше, переверстать шаблон на свой вкус, благо код открыт Шаблон не может перезапускать таймер, т.к. для этого ему пришлось бы лезть туда, где совсем не его область действия - в базу товаров, где пришлось бы менять даты окончания акций товаров. Вместе с тем, это легко реализуется простым sql-запросом в базу, который можно регулярно гонять, к примеру, через крон. В любом случае, если вы используете какой-то сторонний модуль таймера, не мне же я за него отвечать.

Доброго, только правками кода, но не очень понимаю зачем это делать - старая цена выводится и во всплывающей подсказке, и о ее существовании легко узнать из таймера, который также можно включить для привлечения внимания к акциям:

Удаление Добавьте какой-то класс или идентификатор в вышеуказанном коде, например <p class="tags"><?php echo $text_tags; ?> Тогда ваш css будет работать, но, как выше ответил @AWARO, вряд ли это целесообразно

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

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

Пользовательскими стилями точно так же можно переопределить этот цвет, сделав его стандартным, файлы для этого трогать не нужно

Добрый день, пожалуйста, указывайте при обращении логин, с которого покупался шаблон, и площадку, где он покупался (можно в ЛС), т.к. вашего логина в списке покупателей нет

Доброго, можно пользовательскими стилями, но вообще красный цвет, выбранный для акций и прочей такой активности как самый яркий и заметный, вряд ли целесообразно менять, разве что вы выберите красную цветовую схему

Это пиратский ресурс, крайне не советую что-либо оттуда скачивать, вы понятия не имеете, что там может быть внутри Подробнее:

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

Доброго, можно

Не совсем так, critical css нужен в первую очередь для того, чтобы как можно скорее показать пользователю контент, а не для минимизации смещений, устранения дерганий и прочих побочек долгой загрузки - все вышеперечисленное уже последствия его грамотной реализации. Я написал выше о том, какие результаты получил, тестируя все это со своим шаблоном. Если вы делали хоть один шаблон, особенно для массового использования, то должны понимать, что это: мягко говоря, трудоемко, малоприменимо на практике и вряд ли целесообразно в реальных условиях, если шаблон делается не под одного конкретного пользователя и заранее известный набор условий, потому что вы просто физически не сможете предусмотреть все варианты, когда у шаблона будет не один или десять пользователей, а сотня, тысяча и больше.

@GetWeb когда-то проверял это, при общем весе минифицированных стилей главной страницы в 240 кБ (это не только стили шаблона, но и bootstrap, fa, всякие слайдшоу и прочее) критическая часть имела вес около 50 кБ. Допустим, если вручную с умом это делать, получится уменьшить еще больше, но инлайнить на каждой странице сайта простыни из минимум 30-40 кБ стилей - мне показалось не очень перспективной затеей, разве что для накрутки попугаев.

Я об этом и пишу Все, что на практике дает использование вышеуказанной конструкции из заметного невооруженным глазом - это убирает предупреждение "Устраните ресурсы, блокирующие отображение" Мне же начали доказывать, что rel="preload" убивает 20-40 попугаев и стоит его убрать, как оценка с 40 магическим образом поднимается до 90

Недавно мне написал один товарищ-разработчик (имя которого из соображений профессиональный этики раскрывать не будем): Лирическое отступление, если кто не знает, что это такое: https://developer.mozilla.org/ru/docs/Web/HTML/Preloading_content Значение preload атрибута rel в элементе <link> позволяет вам запросить данные через <head> вашего HTML, указав необходимые вашей странице ресурсы ещё в начале её жизненного цикла, - до того, как сработает основной механизм отрисовки браузера. Это гарантирует, что предзагрузчик нужных ресурсов с меньшей вероятностью заблокирует отрисовку страницы, тем самым улучшая её производительность. Пример: Идеальный сценарий использования предзагрузчика контента описан в документации https://web.dev/uses-rel-preload/ Когда у нас на странице есть некая критическая цепочка ресурсов, к примеру, index.html содержит app.js, а в последнем идет подгрузка пары ресурсов styles.css и ui.js, то наша страница, очевидно, не будет полностью загружена, пока эта парочка ресурсов не будет также загружена и выполнена. Соответственно, узким местом такого сценария является загрузка и обработка app.js, до выполнения которой про вышеупомянутую парочку ресурсов никто не знает. Использование rel="preload" позволяет "вклиниться" в этот процесс и запросить загрузку дополнительных ресурсов (та самая парочка styles.css и ui.js) ДО того, как будет загружен и обработан app.js, поэтому при использовании предзагрузчика картинка заметно меняется и нам не приходится ждать, пока поочередно загрузятся все ресурсы, мы сразу заранее требуем их загрузчки: <head> ... <link rel="preload" href="styles.css" as="style"> <link rel="preload" href="ui.js" as="script"> ... </head> Так вот, у меня в шаблоне (да и не только у меня и не только в шаблонах) rel="preload" используется "втупую" для всех ресурсов, поскольку я не знаю, какие ресурсы могут оказаться критически важными, ведь отвечаю только за ресурсы шаблона, а пользователь может дополнительно поставить модули и подключать что угодно еще, что может быть как критичным, так и нет. Этот сценарий не особо эффективен и практического смысла в таком использовании rel="preload" мало, но я был уверен, что никакого заметного влияния на попугаев PageSpeed это иметь не может, поэтому, чтобы на практике подтвердить это, показал своему оппоненту результат использования/отсутствия rel="preload" на демке шаблона (много текста и картинок): С preload: 56/72 55/69 57/70 Без preload: 56/70 52/69 54/70 Как видите, разницы вообще нет, ведь что мы сделали, добавив всем ресурсам rel=preload? Да ничего полезного (и вредного) в целом, мы объявили, что все ресурсы - критические, и их всех надо грузить в первую очередь, в результате пузомерка больше не ругается на традиционный пункт: Устраните ресурсы, блокирующие отображение И накидывает нам 1-2 попугая, которых можно списать на статистическую погрешность. Изменилась ли фактическая скорость загрузки страницы? Да ничуть, ведь у нас как раньше все эти ресурсы грузились сразу, так и сейчас грузятся сразу. Мой оппонент, продолжая спорить и подчеркивая свою важность и экспертность, ответил мне, что всему виной мой быстрый сервер: Хотя по факту у меня на демо даже не VPS, но ладно - мы, как говорится, люди не гордые, иду на бесплатный Beget, разворачиваю там чистый движок и копию чистого шаблона и что же видим: С preload: 84/92 83/93 86/92 Без preload: 84/91 83/95 85/92 Оппоненту был неоднократно предложен доступ к FTP, чтобы он сам все своими руками проверил, если не верит мне и считает, что я как-то по особенному все настраиваю или подкручиваю цифры в свою пользу, также я попросил доступ к хоть одному из его клиентов, у которого, по его словам, наблюдаются такие просадки попугаев, которые мне озвучиваются, но увы - мои предложения были проигнорированы, а я получил еще один убийственный аргумент: Оказывается, бесплатный бегет слишком быстр, чтобы увидеть обещанную просадку попугаев. Ну что ж поделать, иду на медлительный бесплатный американский Awardspace (чтоб уж наверняка медленно все было, даже пинг в 2 раза дольше бегета) и повторяю процедуру, получая предсказуемое подтверждение отсутствия разницы в попугаях: С preload: 67/91 63/85 63/87 Без preload: 65/81 66/89 62/86 Какой я получаю ответ от оппонента? Думаете, признание собственной неправоты? Как бы не так! Оказывается, теперь уже тесты неправильные, а файл у меня внезапно оказался объединен (хотя выше 3 раза демонстрирую, что это не так и в тестах минификация выключена и проверяется подключение всех 12-ти штатных файлов, а не одного объединенного, но мой оппонент не опускается до таких скучных задач, как чтение аргументов). Внимание, вопрос! Что я делаю не так и почему не вижу разницы в попугаях и с чего вдруг использование rel="preload" должно давать просадку в 20-40 попугаев (как это утверждает мой оппонент)?

Вообще эта языковая конструкция переведена ненормально, но это не перевод шаблона, а такая русская локализация движка. Текст берется из штатного языкового файла catalog\language\ru-ru\affiliate\register.php

Во вкладке общее Условия согласия: