RGB

Проблема в том, что модальные окна (точнее, подгрузка контента в них с использованием метода agree()) - штатный механизм движка, но он имеет свои ограничения, которым и приходится следовать, чтобы не изобретать велосипеды и не усложнять и без того запутанную реализацию

Так назло не пишут же! Молчат, страдают, ждут звездного часа для своего перформанса (чтоб ррраз - и навалить кучу прилюдно, как в случае выше), за спиной критикуют (пока не словишь, опять же, как в случае выше), прикрываются неудачным "опытом коллег", список можно продолжать бесконечно..

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

@SerGan напишите в лс почту куда отправить

Доброго, так сразу бы написали мне вместо того, чтобы связываться с техподдержкой хостинга, которая не разбирается (и не обязана разбираться) в таких проблемах. В следующем обновлении шаблона появится капча для таких форм, но т.к. ко мне за последний год обращалось 2-3 пользователя с такой же проблемой, есть промежуточная версия шаблона, где эта капча уже появлиась. Поэтому могу вам отправить промежуточную версию шаблона с поддержкой капчи, т.к. полноценное обновление еще в процессе подготовки.

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

Просто любопытно, с какой целью вы это сделали? Он вам нагрубил или как-то еще дорогу перешел? Или просто «потому что могу»?

Спасибо за конструктивное дополнение, надо добавить вариант информирования одних лишь клиентов, но тут есть один момент. Даже если практически никто не прислушивался к вам, это же не значит, что всех надо мести под одну гребенку? Я не привожу себя в пример типа "смотрите какой я классный", можете относиться ко мне как угодно, но опять же – пример из личного опыта. В хорошо нам известной сборке .про версии 2.3.0.2.3 был небольшой баг, связанный с отображением вспл. окон при включенном ЧПУ (как на странице возврата товара), при нажатии сюда: получалась такая беда: Мелочь? Конечно! Поэтому я и написал тогда моему нынешнему хейтеру об этой проблеме на его почту с вопросом могут ли они такое подтвердить и получил ответ, что баг вполне может быть. Реален ли тот баг, исправили ли его или он до сих пор есть - я не знаю, да мне это и не важно, т.к. я проинформировал авторов, а дальше уже их личное дело. Можно было раструбить об этом небольшом баге среди всех моих клиентов-пользователей сборки? Конечно! Но зачем это было бы делать и кто бы выиграл в такой ситуации? Совсем другое дело, когда клиент прямо говорит, что вот есть такой баг и его надо исправить - но это же совсем другая ситуация. Или вот еще пример, за которым далеко ходить не надо - отметившийся выше @buslikdrev, будучи вполне грамотным специалистом, как-то пару лет назад решил сделать своеобразное «доброе» дело и наказать неосмотрительного новичка-разработчика шаблона @Medialine, выложив прямые ссылки на файлы его шаблона, доступ к которым тот забыл закрыть: С одной стороны - эти файлы сами по себе особой ценности, конечно, не представляли, поскольку без модуля управления шаблоном были в целом бесполезны, так что прямого вреда никто никому не нанес. С другой - разработчик шаблона прилюдно был усажен в лужу, т.е. его репутация, очевидно, пострадала, как и его самолюбие. Почему нельзя было это сделать в личку, а не публично? Неужели не было понятно, что хоть @Medialine и запомнит навсегда, что .twig-файлы надо закрывать, но от этого акта публичного наказания он теперь вообще десять раз подумает прежде, чем делиться с сообществом каким-то контентом, потому что просто будет опасаться такой же, не совсем адекватной, реакции.

Давно были наброски для этого поста, а тут так кстати подвернулась ситуация, на примере которой можно рассмотреть данный вопрос . Итак, вы нашли баг в дополнении какого-то автора, для начала определимся с тем, в каких случаях он вообще достоин внимания и обсуждения. Шаг 1. Повторение – мать учения Все прекрасно знают, что баги, т.е. программные ошибки, бывают абсолютно у всех разработчиков, которые хоть что-то делают, но не все баги являются действительно багами, поэтому первое, что нужно сделать – убедиться, что это точно баг, а не фича. Для этого, очевидно, нужно подтвердить обнаружение бага путем его локализации и повторения в разных условиях. В идеальном случае эксперимент нужно проводить на чистом движке и в отсутствии влияния каких-либо других дополнений/модификаторов. Если у вас такой возможности нет и баг обнаружен, к примеру, на демо-сайте разработчика, то тут уже ничего не поделать – сразу переходим к следующему шагу. При этом я еще не встречал людей, которые бы покупали дополнение ради подтверждения обнаруженного на демо бага, но этот сценарий вполне имеет право на жизнь. Для этого не обязательно быть добрым волшебником – возможно, у вас просто есть хороший клиент, которого нужно обезопасить от любых проблем и прибыль от работы с которым точно перевешивает расходы на покупку и тестирование дополнения, даже если оно не подойдет. Шаг 2. Насколько все серьезно? Не все баги одинаково полезны опасны, поэтому перед тем, как предпринимать какие-то дальнейшие действия, нужно самостоятельно оценить масштабы и влияние обнаруженного бага. Конечно, когда в результате найденного вами бага удаляются все пользовательские данные (как в этом каноничном примере rm -rf с GitHub), лучше поторопиться и как можно скорее приступать к следующим шагам. Но если вы заметили какую-то мелочь, например, лишний пробел или перенос где-нибудь в верстке – сразу вас огорчу, исправление таких мелочей очень часто откладывается большинством разработчиков на неопределенный срок. Почему так – есть несколько причин: Если мы говорим о дополнениях для OpenCart, то стоимость таких дополнений и средние бюджеты в проектах далеки от высоких, поэтому требовать "Pixel perfect" от какого-нибудь шаблона за 20$ – бесполезно Не все разработчики вообще обновляют дополнения, поэтому и ошибки в них могут существовать годами, а то и весь срок жизни дополнения Те, кто регулярно выпускают обновления, не делают это каждый день из соображений как собственного удобства (разошлите экстренное обновление тысяче пользователей и через день непременно найдете новый баг, поверьте), так и удобства пользователей (все любят регулярные обновления, но никто не любит тратить время на их установку) Обычно в обновление входит исправление сразу множества ошибок, поэтому исправления пары незначительных багов обычно ставится в очередь для подготовки более крупного обновления Тут все зависит от отношения к своей работе самого автора и зачастую вам будет быстрее и проще самостоятельно исправить обнаруженную проблему. Конечно, это не касается случаев, когда работы выполняются по четкому ТЗ, в котором оговорено отсутствие таких багов – в этом случае вы имеете полное право требовать скорейшей реакции, потому что вы за это платите. Шаг 3. Уведомление или неуведомление автора На этом шаге я бы хотел остановиться подробнее. У любого человека, как у простого пользователя, так и у опытного специалиста, в случае нахождения бага в каком-то дополнении всегда есть несколько вариантов действий: Промолчать Уведомить, но не автора Уведомить автора Разберем каждый из вариантов, его плюсы и минусы. Шаг 3.1 Молчание Если баг оказался некритичным и вы сами смогли его исправить, то вполне возможно, что не захотите тратить время на уведомление автора (тем более, если автор не отличается оперативным исправлением багов). Возможна и другая причина – автор составляет вам конкуренцию (или просто неприятен) и вы заинтересованы в том, чтобы он и его клиенты подольше «страдали» от неисправленного бага Промолчали – и ладно, никто вас за это не осудит (разве что сам автор, и то лишь если узнает или вы сами проболтаетесь). Плюсы: ничье самолюбие не пострадало Минусы: баг так и остался незамеченным и неисправленным Шаг 3.2 По секрету всему свету Бывает и так, что обнаруживший баг специально решает скрыть это от автора, но рассказать это другим лицам (конкурентам, читателям, администрации, кому-угодно еще). Мотивация таких персонажей бывает самой разной – от банальной зависти и конкурентной борьбы до простого и старого, как мир, желания исподтишка нагадить ближнему. Справедливости ради стоит заметить, что есть некоторые авторы, которые категорически отрицают любую критику и воспринимают ее в штыки, поэтому бывает и так, что вы многократно следовали шагу 3.3, но это не дало результатов, поскольку к автору просто невозможно достучаться из-за его собственного упрямства и у нашедшего баг остается только два варианта – молчать или подключать третьих лиц. Плюсы: к багу привлечено внимание, вы ощущаете себя Д'Артаньяном Минусы: баг все равно может остаться неисправленным, а отношения с автором с большой долей вероятности будут испорчены Шаг 3.3 Профессиональная этика Я не просто так назвал этот шаг профессиональной этикой, по моему мнению именно этот вариант действий наиболее профессионален, продуктивен и разумен для всех сторон. К сожалению, мне не часто попадается такое поведение со стороны других разработчиков, да и сам я не без греха, поэтому не стоит воспринимать этот пункт как самовосхваление. Итак, если в случае обнаружения и подтверждения бага вы сперва описываете его автору дополнения, то убивается сразу несколько зайцев. Самолюбие автора не страдает так сильно, как если бы вы прилюдно демонстрировали его баг, а времени на исправление бага у автора остается достаточно много, чтобы все обдумать и грамотно пофиксить (в отличии от ситуации, когда вы публично критикуете автора, вынуждая его защищаться, совершать поспешные действия и оправдываться). При этом в случае с адекватной реакцией автора вы получаете благодарность, причем я говорю не о программе Bug Bounty (все таки мы не в фейсбуке работаем), а про нормальное отношение и признательность со стороны автора к человеку, не поленившемуся помочь справиться с проблемой. Плюсы: баг исправлен, автор (как правило) признателен Минусы: автор (иногда) может затаить злобу и не прислушаться к советам, а вы уже не сможете посадить подготовленного автора в лужу Плохой пример Приведу пример из личного опыта, упомянутый в начале этой публикации – некий сеошник, в последнее время активно рекламирующий на форуме свои услуги, обнаружил у меня в шаблоне проблему, связанную с непродуманным выводом артикулов товаров за пределами заголовочных тегов H1. Почти месяц назад он упомянул ее в своей статье, да еще и приписал мне выполнение SEO-аудитов (которых я никогда не делал и не собирался делать), желая на этом фоне выставить меня эдаким сапожником без сапог и думая, что этого никто не заметит. При всем при этом он за все это время даже не подумал обратиться ко мне лично, чтобы сообщить о найденной проблеме или хотя бы уточнить, действительно ли я делаю эти самые аудиты, которые он критикует? Эта информация про артикулы и H1 не являлась новой для меня и я ее видел еще несколько лет назад в отчете довольно известной компании WebPromo, специалисты которой тогда готовили 100-страничный SEO-аудит сайта знакомых и в одном из пунктов прямо советовали «уникализировать заголовок H1 посредством добавления артикула». В то время я не придал должного внимания этой технике (зря, конечно), отложив реализацию на будущее, а потом благополучено забыл об этом, за что мне стыдно Но речь не об этом. Что можно было сделать в такой ситуации? Если бы человек был немного умнее и изначально уведомил меня об этой проблеме, я бы в знак признательности за найденный баг посоветовал обращаться к этому человеку своим многочисленным клиентам, которые у меня стабильно несколько раз в месяц спрашивают контакты толкового сеошника для своих магазинов. Т.е. человек потратил бы 5 минут своего времени на описание бага и получил бы стократ больше – свежий приток новых клиентов, уважительное отношение к себе со стороны автора и хорошую репутацию, которую не купишь рекламными постами. Не спешите писать в комментах «если бы да кабы», сперва прочтите следующий пункт. Хороший пример А вот другой пример из личного опыта с человеком, в особых симпатиях к которому меня точно сейчас не заподозришь Опять же, несколько лет назад, когда мы еще нормально общались и мой оппонент производил в целом адекватное впечатление, у него был в работе проект с моим шаблоном, в котором была обнаружена неприятная проблема – в блоке быстрого поиска я не догадался поставить небольшой таймер для задержки поискового запроса. Поэтому при быстром наборе этого самого запроса каждое нажатие клавиши вызывало отправку запроса на сервер и получение ответа, из-за чего окно поиска мерцало, а сервер вместо того, чтобы с небольшой задержкой сразу искать один товар "кресло" выполнял серию последовательных запросов, пытаясь найти товар "кр", "кре", "крес", "кресл", и т.д. Что сделал мой оппонент в то время? Написал мне в личку «со всем уважением, вы тут не правы)» и объяснил суть проблемы. В итоге уже через день клиент, у которого эта проблема проявлялась, получил инструкцию по ее исправлению, в готовящемся обновлении шаблона тоже появилось это исправление, ну а мой оппонент получил не одну и не две рекомендации его услуг среди моих собственных клиентов. Как мог поступить мой оппонент (и как, вероятно, поступил бы сейчас в такой ситуации)? Разумеется, ни в коем случае не стал бы сообщать об этом баге лично, а предпочел бы выложить на всеобщее обозрение какой-нибудь гневный пост в блоге, сопроводив язвительными комментариями о том, какой шаблон кривой-косой и как он много вреда и бед принес его клиенту. Что полезного в результате получил бы мой оппонент в такой ситуации, кроме минутного удовольствия от того, как жертву макнули в лужу? Ровным счетом ничего. Никто из нас не любит, когда его критикуют, а особенно когда критикуют публично, этому учат и студентов-психологов, и маркетологов, и даже политиков. Если ваша цель не в минутном удовлетворении раздутого ЧСВ, а в том, чтобы кто-либо что-нибудь исправил – будьте умнее, сделайте так, чтобы человек сам добровольно захотел это сделать!

Возможно, некоторые сегодня заметили в телеграм-канале форума сообщение от г-на "Чип и дейл Спешим на помощь" (он же @Yoda, который ко мне неровно дышит после истории с профайлером): Поскольку мне уже в личку начали писать некоторые чрезмерно доверчивые люди с просьбой прокомментировать данное утверждение, отвечу сразу в теме: это утверждение является ложью и не соответствует действительности В шаблоне, используемом его легальными покупателями, нет и никогда не было никаких "стучалок". Г-н @Yoda прекрасно знаком с кодом шаблона (он ему неоднократно отправлялся ранее, т.к. он с ним работал как минимум у нескольких своих клиентов, да еще и оставлял хвалебные отзывы о реализации шаблона, хранившиеся у него в блоге - пример 1 и пример 2) и физически не сможет предоставить никаких доказательств данного утверждения, потому что таких доказательств в природе не существует и не может существовать. Информация о том, на каком домене используется шаблон, предоставляется при его покупке/активации и не является результатом работы "стучалок" и иных подобных механизмов. И чтобы два раза не вставать из-за своих фанатов - относительно найденной мелкой сеошной недоработки с размещением артикула за пределами заголовочного тега H1 информация принята в работу и будет реализована по мере готовности следующего обновления, в списке которого уже больше десятка доработок и исправлений. Сроки релиза обновления по этим же причинам озвучить пока не могу, но если кому-то вышеупомянутая недоработка кажется критически важной - в файле catalog\view\theme\moneymaker2\template\product\product.tpl вам нужно заменить строку <h1 class="h2" itemprop="name"><?php if ($moneymaker2_product_metatitles_enabled) { ?><?php echo $meta_title; ?><?php } else { ?><?php echo $heading_title; ?><?php } ?></h1><?php if ($moneymaker2_code) { ?> <div class="h2"><small>(<?php echo $moneymaker2_code; ?>)</small></div><?php } ?> на <h1 class="h2" itemprop="name"><?php if ($moneymaker2_product_metatitles_enabled) { ?><?php echo $meta_title; ?><?php } else { ?><?php echo $heading_title; ?><?php } ?><?php if ($moneymaker2_code) { ?> <small>(<?php echo $moneymaker2_code; ?>)</small><?php } ?></h1> Затем обновите кеш модификаторов (не забывайте предварительно сделать резервную копию) Добрый день, эта "фича" описана в документации https://2.mnmkr.com/documentation/#setup-catalogpoints

Доброго, если вы имеете в виду вывод таких сроков внутри модуля преимуществ, то он же привязывается не к конкретным товарам, а к категориям, поэтому без переделывания логики шаблона тут не получится такое реализовать. Если же выводить такую информацию в каком-то другом месте, то шаблон никакой роли не будет играть, вам нужно прописать такую логику в том инструменте, которым делается обработка прайса (т.е. если встречается цифра 0, то ставим статус "В наличии" и тд), а затем передавать эту информацию из контроллера в специально для того созданное место в tpl-файле

Это все элементы шапки сайта, т.е. файл шаблона header.tpl <li class="dropdown-header"><?php echo $moneymaker2_text_customer_name; ?></li>

Доброго, что такое меню, где выводится "Имя Фамилия"?

Доброго, простой и примитивный способ - написать модификатор, который ищет все вхождения img и добавляет это туда, также можно проставить всем изображениям width и height, правда это будет чуть сложнее, поскольку придется откуда-то брать эти размеры, т.е. вмешиваться во все контроллеры и передавать оттуда размеры в шаблон из системных настроек

Только правкой кода шаблона, вывод ссылок панели категорий указан в файле шаблона шапки сайта header.tpl, по моему, в цикле <?php foreach ($moneymaker2_header_panellinks as $value) { ?> <li><a href="<?php echo $value['multilink'] ? $value['multilink'] : $value['link']; ?>"><i class="fa fa-fw fa-<?php echo $value['icon']; ?>"></i> <?php echo $value['caption']; ?></a></li> <?php } ?>

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

Добрый день, если вы про вывод дополнительной информации в шапке сайта и если я правильно понял что нужно, то в шаблоне предусмотрено два вида компонентов для этого - меню категорий и панель категорий с расширением, первое подразумевает вывод любой дополнительной информации внутри отдельного выпадающего меню https://2.mnmkr.com/documentation/#setup-header-megamenu, а второе https://2.mnmkr.com/documentation/#marketing-catbanner - вывод такой информации непосредственно среди категорий магазина, пример последнего у меня на демо: этот блок добавляется вручную и может содержать любой html-контент, т.е. автоматически список всех производителей туда, конечно, не попадет, но вы можете сами вручную добавить что вам нужно и в том виде, в каком вам это кажется удобнее.

Для этого вам нужен любой из модулей типа "Стена категорий", например, из раздела совместимости (там их два): https://2.mnmkr.com/documentation/#compatibility или любой другой, т.к. они обычно (если написаны грамотно) не особо зависят от шаблонов и полагаются на стандарты bootstrap

Можно сразу последнюю из архива с 2.7.2 по инструкции https://2.mnmkr.com/documentation/#installation-update

Доброго, шаблону все равно в каком порядке, но для других модулей смена РНР может вызвать проблемы, поэтому я бы пока что не советовал обновляться до РНР новее 7.3. Ну и между обновлениями не забывайте делать резервные копии

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

Добрый день, можно перенести часть базы из тройки в двойку или, если это для вас сложно, использовать какой-нибудь модуль импорта/экспорта, например: для 3 ставите этот модуль https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=17 и после его работы получаете xls-таблицу с вашими товарами, потом ставите чистую двойку (лучше всего последнюю версию ocstore 2.3.0.2.4), на нее аналогичный модуль затем делаете тестовый экспорт из двойки, чтобы увидеть образец xls-файла, и в него просто переносите из аналогичного файла после тройки данные по товарам. Если это для вас тоже сложно, можете обратиться к @Rubynoid Насчет модуля фильтра - он совместим с шаблоном.

Так мне-то с чего и на кого обижаться, все ок

1. У меня в карточке товара выводится модуль связанных (сопутствующих) товаров, это разные модули и настройки для этого находятся внутри вкладки Товар в самом низу 2. Я дал подробный ответ выше и даже указал точку фиксации, куда можно добавить любой сторонний код, вам никакой ид не нужен и более того - он вам никак не поможет, т.к. форма одна и та же и используется для нескольких операций, постановка вашего вопроса говорит о том, что вам лучше обратиться к специалисту для решения этой и других возникающих задач (я работу не ищу, если что)

В настройках шаблона на вкл. Модули - Родные есть блок настроек для Рекомендуемых, т.к. хоть шаблон и не контролирует их логику, у него есть возможность включения/отключения отображения товаров модуля в виде карусели