-
Posts
6,967 -
Joined
-
Last visited
Content Type
Profiles
Forums
Marketplace
Articles
FAQ
Our New
Store
Blogs
module__dplus_manager
Everything posted by RGB
-
Доброго, убрать - редактированием файла catalog\view\theme\moneymaker2\template\common\header.tpl Перенести - можно с помощью расширения меню категорий https://2.mnmkr.com/documentation/#setup-header-megamenu
- 7,364 replies
-
- продающий шаблон
- продающий дизайн
- (and 5 more)
-
Добавлена адаптация для бесплатного модуля "SEO мультиязык для сайта, код языка в url и правильный hreflang" Пока изменений для полноценного обновления недостаточно, так что кому нужна адаптация - пишите в ЛС
- 7,364 replies
-
- продающий шаблон
- продающий дизайн
- (and 5 more)
-
В таком случае вместе с вышеуказанным кодом удалите его аналогичную часть в файле catalog\view\theme\moneymaker2\template\product\product.tpl
- 7,364 replies
-
- продающий шаблон
- продающий дизайн
- (and 5 more)
-
Доброго, взаимно Убрать уведомление можно небольшими правками кода, для примера каталога я как-то писал в теме но каким образом ваши покупатели поймут, что товар был успешно добавлен в корзину, если вы скроете единственное заметное уведомление об этом?
- 7,364 replies
-
- продающий шаблон
- продающий дизайн
- (and 5 more)
-
А где там заголовочный тег H2?
- 7,364 replies
-
- продающий шаблон
- продающий дизайн
- (and 5 more)
-
Доброго, в файле catalog\view\theme\moneymaker2\template\product\product.tpl и после изменений не забудьте обновить кеш модификаторов
- 7,364 replies
-
- 1
-
- продающий шаблон
- продающий дизайн
- (and 5 more)
-
Шаблон же не может за вас обеспечить привлечение траффика на карточки товара. Прошу простить за лирическое отступление и раздачу непрошенных советов, но у вас основной упор должен быть именно на них, т.е. желательно направлять траффик именно туда, тогда и проблемы попадания в карточку товара не возникнет, и конверсия будет выше. Не помню точных цифр, но для сравнения у нас около 70% траффика направлялось именно на товары, остальное на категории, в крупных магазинах процент и того больше, насколько мне известно. Почему не видно и почему не спасают? Аналогично карточки товара с таймером, вы можете включить вывод конкретной скидки: Либо, как я писал выше, переверстать шаблон на свой вкус, благо код открыт Шаблон не может перезапускать таймер, т.к. для этого ему пришлось бы лезть туда, где совсем не его область действия - в базу товаров, где пришлось бы менять даты окончания акций товаров. Вместе с тем, это легко реализуется простым sql-запросом в базу, который можно регулярно гонять, к примеру, через крон. В любом случае, если вы используете какой-то сторонний модуль таймера, не мне же я за него отвечать.
- 7,364 replies
-
- продающий шаблон
- продающий дизайн
- (and 5 more)
-
Доброго, только правками кода, но не очень понимаю зачем это делать - старая цена выводится и во всплывающей подсказке, и о ее существовании легко узнать из таймера, который также можно включить для привлечения внимания к акциям:
- 7,364 replies
-
- продающий шаблон
- продающий дизайн
- (and 5 more)
-
Удаление Добавьте какой-то класс или идентификатор в вышеуказанном коде, например <p class="tags"><?php echo $text_tags; ?> Тогда ваш css будет работать, но, как выше ответил @AWARO, вряд ли это целесообразно
- 7,364 replies
-
- 1
-
- продающий шаблон
- продающий дизайн
- (and 5 more)
-
Все возможные настройки вы видите в модуле слайдшоу, чтобы текст не обрезался можно или уменьшить саму длину текста, или в качестве заголовка использовать поле подписи например
- 7,364 replies
-
- продающий шаблон
- продающий дизайн
- (and 5 more)
-
Только эти и подобные им заголовки, т.е. то, что касается акционных предложений
- 7,364 replies
-
- 1
-
- продающий шаблон
- продающий дизайн
- (and 5 more)
-
Пользовательскими стилями точно так же можно переопределить этот цвет, сделав его стандартным, файлы для этого трогать не нужно
- 7,364 replies
-
- продающий шаблон
- продающий дизайн
- (and 5 more)
-
Добрый день, пожалуйста, указывайте при обращении логин, с которого покупался шаблон, и площадку, где он покупался (можно в ЛС), т.к. вашего логина в списке покупателей нет
- 7,364 replies
-
- продающий шаблон
- продающий дизайн
- (and 5 more)
-
Доброго, можно пользовательскими стилями, но вообще красный цвет, выбранный для акций и прочей такой активности как самый яркий и заметный, вряд ли целесообразно менять, разве что вы выберите красную цветовую схему
- 7,364 replies
-
- продающий шаблон
- продающий дизайн
- (and 5 more)
-
Frame - быстрый адаптивный шаблон для OpenCart 3 [Поддержка]
RGB replied to xds's topic in Платные шаблоны
Это пиратский ресурс, крайне не советую что-либо оттуда скачивать, вы понятия не имеете, что там может быть внутри Подробнее:- 1,779 replies
-
- 2
-
Доброго, и куда же они делись интересно и почему у меня есть? Вообще говоря, коды всяких метрик ставятся в админке туда же, куда вы ставите код счетчика, поэтому трогать файлы для этого - неправильно
- 7,228 replies
-
- продающий шаблон
- html5
- (and 6 more)
-
Доброго, можно
- 7,364 replies
-
- 2
-
- продающий шаблон
- продающий дизайн
- (and 5 more)
-
Не совсем так, critical css нужен в первую очередь для того, чтобы как можно скорее показать пользователю контент, а не для минимизации смещений, устранения дерганий и прочих побочек долгой загрузки - все вышеперечисленное уже последствия его грамотной реализации. Я написал выше о том, какие результаты получил, тестируя все это со своим шаблоном. Если вы делали хоть один шаблон, особенно для массового использования, то должны понимать, что это: мягко говоря, трудоемко, малоприменимо на практике и вряд ли целесообразно в реальных условиях, если шаблон делается не под одного конкретного пользователя и заранее известный набор условий, потому что вы просто физически не сможете предусмотреть все варианты, когда у шаблона будет не один или десять пользователей, а сотня, тысяча и больше.
- 10 replies
-
@GetWeb когда-то проверял это, при общем весе минифицированных стилей главной страницы в 240 кБ (это не только стили шаблона, но и bootstrap, fa, всякие слайдшоу и прочее) критическая часть имела вес около 50 кБ. Допустим, если вручную с умом это делать, получится уменьшить еще больше, но инлайнить на каждой странице сайта простыни из минимум 30-40 кБ стилей - мне показалось не очень перспективной затеей, разве что для накрутки попугаев.
- 10 replies
-
- 1
-
Я об этом и пишу Все, что на практике дает использование вышеуказанной конструкции из заметного невооруженным глазом - это убирает предупреждение "Устраните ресурсы, блокирующие отображение" Мне же начали доказывать, что rel="preload" убивает 20-40 попугаев и стоит его убрать, как оценка с 40 магическим образом поднимается до 90
- 10 replies
-
Недавно мне написал один товарищ-разработчик (имя которого из соображений профессиональный этики раскрывать не будем): Лирическое отступление, если кто не знает, что это такое: 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 попугаев (как это утверждает мой оппонент)?
- 10 replies
-
- 2
-
Вообще эта языковая конструкция переведена ненормально, но это не перевод шаблона, а такая русская локализация движка. Текст берется из штатного языкового файла catalog\language\ru-ru\affiliate\register.php
- 7,364 replies
-
- продающий шаблон
- продающий дизайн
- (and 5 more)
-
Во вкладке общее Условия согласия:
- 7,364 replies
-
- 1
-
- продающий шаблон
- продающий дизайн
- (and 5 more)