sv2109

А где гарантия, что модуль не предоставляет опасности?Идеал этот вполне достижим. Он успешно применяется уже много лет в других системах. Я не говорю чтобы применять все и сразу. Просто когда есть какой-то идеал тогда задается вектор движения. И не важно с какой скоростью это движение происходит, важно то, что оно идет в правильном направлении.

Именно для этого и придумали стандарты кодирования. Каждая уважающая себя система его имеет. И любой программист который пишет под эту систему обязан его придерживаться. Иначе в одном файле отступы будут через табуляции, в другом через 2 пробела в третьем через 4, в четвертом через 8. Один файл в utf8, другой в cp1251 итд. Такого в том что это противоречит шаблону MVC, работа с базой должна быль вынесена в один независимый слой. Так код получается намного чище, более независимым и его намного приятнее читать.Только что посмотрел код опенкарта. SQL запрос в каталоге используется в одном единственном контроллере - seo_url, возможно на это есть своя причина, которой я не вижу, возможно просто поленились создавать для парочки запросов отдельную модель, не знаю. Но в любом случае это аж никак не "часто делает". В админке тоже в 1 контроллере - главной странице, там вроде какие-то заказы вытягиваются с базы.

да, кстати, и быстрее и релевантнее. Но там есть один минус - гугл покажет только проиндексированные страницы. А из 100 тысяч страниц в индексе может оказаться только 5 тыс.. а остальные гугл может воспринять как спамные или не оригинальные или ему просто сайт не понравится и он решит что пару тысяч страниц для него хватит. Плюс индекс пожет обновляться не сразу. Товара уже может 2 недели как не быть на сайте а в индексе он будет и по поиску находится тоже будет.

Если у вас стандартный поиск работает настолько медленно (это уже слишком долго) то включать еще и поиск с релевантностью вам сомневаюсь что вообще есть смысл, так как он сделает поиск еще медленнее. Плюс вы еще хотите добавить туда и модели и артикулы.. что сделает его еще медленнее. Я бы на вашем месте при таком количестве товаров вообще отключил все и оставил поиск только по названию с морфологией. Без описаний, моделей, тегов и релевантности. Плюс создал все индексы и выбросил весь мусор с поискового запроса (типа рейтинга) и только тогда возможно у вас более менее нормально будет работать поиск.. А сделать почти все возможно, только в данный момент я новых заказов на доработки не принимаю, нету времени. насчет этого не уверен. Малый вес дают совпадения в описании, если они не нужны то их просто можно отключить.

Ну, красота понятие очень индивидуальное. И то, что не нравится вам вполне возможно что понравиться кому-то другому. Но что действительно бы не помешало так это премодерация дополнений на качество кода. К качеству кода можно отнести: - соответствие стандартам кодирования Кстати под опенкарт я таких не встречал, если есть дайте ссылку, если нету значит нужно создать. - соответствие шаблону MVC, чтобы не было sql запросов в контроллерах и тем более в представлениях итд. - всегда использовать апи опенкарта там где это возможно - всегда использовать идеологию опенкарта. Там где можно решить проблему с помощью стандартного модуля нужно использовать именно его, а не писать кучу непонятного кода, а потом прикручивать его с помощью каких-то костылей.. - не использовать слепой копипаст. Нужно создать что-то, скопировал 2 страницы кода движка, вставил в свой модуль, проверил, как-то работает.. и какая разница что там половина переменных не используется?.. - безопасность кода - итд. Просто.. покупатель не видит и не понимает что внутри, он видит красивую заставку и хорошее описание.. А внутри может быть настоящий ад, который может даже навредить сайту и который потом ни один уважающий себя разработчик не возьмется доделывать.. В результате может пострадать покупатель, который честно заплатил за этот модуль. В Друпале например каждый модуль перед тем как попасть в раздел модули на оф.сайте проход тщательную проверку по куче пунктов - и если что-то не так, его просто не пропустят. Что здесь? Любой "гений программирования" может на коленке сделать свой первый модуль и выставить за него любую цену.. И это вообще никто не проверяет?

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

нет

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

на OpenCart 1.5.3.1 модуль не проверял, завтра проверю, отпишу. Думаю, должен работать, если не будет то сделаю. На магазине в 100к товаров протестировать модуль нету возможности. А как там работает стандартный поиск? Если нормально то скорее всего что будет работать и этот, во всяком случае морфология точно будет. На счет релевантности не уверен, там немного усложняется sql запрос что на больших объемах может значительно увеличить время поиска. На сколько сложно сказать, нужно пробовать. Можете в личку скинуть ссылку этого магазина?

без изменения контроллера никак

Посмотрите этот модуль http://opencartforum...99-group-price/ там можно менять цены в процентах (и фиксировано) как для определенных групп покупателей так и для категорий товаров.

Спасибо всем за ответы, ситуация немного прояснилась. На днях пришлось установить эту сборку для тестирования одного модуля. В код не заглядывал, с виду довольно симпатично + есть немало модулей уже установленных. Я так понимаю что именно на это и ведутся новички, которые сами не умеют установить модуль. Но этот плюс является и большим минусом. Для опытного пользователя возникает проблема как удалить установленный модуль, если он жестко прописан в коде движка (vqmod максистор не использует) и не нужен или не устраивает по качеству или пользователь нашел более качественный аналог. Выпилять что-то в этом случае реально проблематично.. Для неопытного пользователя проблемы начнутся тогда, когда нужны будут сторонние модули, которые не смогут работать если например используют vqmod (а его используют почти все более менее сложные модули) который рассчитан на стандартный не измененный движок. Например у меня один модуль из-за этого не заработал. То есть сэкономив немного времени сначала можно получить немало проблем из-за несовместимости потом.. :/

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

Все можно, вот только времени на все нету.. На данный момент уже сделана и работает интеграция с модулем Search Suggestion, который как я понимаю делает почти тоже самое что и модуль ajax search

catalog/view/theme/firstenergycorp/template/common/header.tpl - в этом файле скорее всего ваш телефон, откройте и поменяйте

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

product.php.diff.zip

В последнее время все чаще получаю сообщения типа "А будет ли ваш модуль работать на МаксиСторе?" Уже третий или четвертый подобный вопрос за последних 3 дня.. Получается сборка достаточно популярная. Но немного поискал на этом форуме инфу об этой сборке и почти ничего не нашел. Да, достаточно много негатива но ничего конкретного. Нашел, правда, тему в которой, как я понял, автор этой сборки поступил некрасиво и в свои шаблоны понапихивал кучу своих ссылок. После чего мало того, что не захотел извинятся так еще и нагрубил. Но это характеризует автора но не движок, хотя сомневаюсь, что хам может создать что-то хорошее.. Хочется услышать от людей, которые работали с MaxyStore, кто что о ней думает? По возможности больше конкретики. Возможно кто-то писал модули под эту сборку - прокоментируйте ее код, качество, насколько сильно он отличается от базового? Просто с одной стороны достаточно много людей просит переделать модули под MaxyStore, а с другой даже не знаю стоит ли вообще с ней связываться..

Вроде исправил баг, выложил тут.

ну это навряд ли.. скрипт же не знает какой именно товар вы ищете и тем более ничего не знает о несуществующих товарах. Он просто показывает наиболее подходящие под поисковый запрос товары.

Да, только что проверил.. на версии opencart 1.5.4.1 и на ocstore 1.5.4.1 похоже так и есть.. независимо от выбранной категории поиск осуществляется по всем категориям. Сейчас нету времени, потом гляну в чем тут проблема, скорее всего какая-то опечатка в коде..

Я тут в описании писал как загрузить таблицы через phpmyadmin, там и тестовые данные есть.

запустите /vqmod/install/

Добавил поддержку модуля Search Suggestion - Поиск с автодополнением

http://dev.mysql.com/doc/refman/5.0/en/control-flow-functions.html#function_if