sv2109

я бы на html делал. Создается страница, туда подставляются нужные данные (ФИО, адрес итд. ). Возле каждого заказа есть кнопка "Распечатать бланк наложенного платежа", после нажатия на которую открывается например во фрейме эта страница со всеми вставленными данными с кнопкой "Печать". Жмешь печать, получаешь готовую бумажку.

Наибольший вес имеет точное

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

Вот что имеется в виду под описанием? В описании товара? если да, то у меня по умолчанию модуль не делает поиск по описанию товара, только если на странице поиска поставить галочку.... так и должно быть? или он сразу должен искать в описании тоже? и еще объясните что значат цифры в админке управления модуля,я понял что это вес, но что будет если поставить где-то больше или меньше число? можно как-то простыми словами?

и по умолчанию где осуществляет поиск модуль? только в названии товара и все или еще по тегам? или....?

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

Цифры в админке означают вес. Чем больше вес тем выше это совпадение будет в результатах поиска.

Насчет тегов, теоретически да, по тегам должно искать быстрее, особенно если еще и индексы посоздавать. Но нужно пробовать.

заказчику до лампочки соответствует код конвенции или нет )

вот я не так давно покупал модуль на оф.сайте - видео галерея. Зашел на демо сайт, все нормально, все работает, зашел в админку, покликал все работает. Купил, установил и вот засада.. модуль написан с поддержкой только 1 языка. А установить его я хотел на двумовный сайт. И что? заплатил деньги, закатывай рукава и дописывай, разбирая чужой код..

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

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

но вижу многим на это глубоко наплевать, как-то работает.. ну и фиг с ним..

я за премодерацию, особенно платных решений, но как я понял это труднореализуемо.

sv2109, это недостижимый идеал =)) модули должны хотя бы работать без ошибок и не представлять опасность =))

А где гарантия, что модуль не предоставляет опасности?

Идеал этот вполне достижим. Он успешно применяется уже много лет в других системах.

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

Красота и качество кода штука тоже относительная.

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

А что такого в том, чтобы в контроллере использовать SQL? OpenCart так часто делает.

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

Только что посмотрел код опенкарта. SQL запрос в каталоге используется в одном единственном контроллере - seo_url, возможно на это есть своя причина, которой я не вижу, возможно просто поленились создавать для парочки запросов отдельную модель, не знаю. Но в любом случае это аж никак не "часто делает".

В админке тоже в 1 контроллере - главной странице, там вроде какие-то заказы вытягиваются с базы.

Или просто поставьте поиск по сайту от google, он быстрее всего работает.

да, кстати, и быстрее и релевантнее.

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

Плюс индекс пожет обновляться не сразу. Товара уже может 2 недели как не быть на сайте а в индексе он будет и по поиску находится тоже будет.

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

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

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

насчет этого не уверен. Малый вес дают совпадения в описании, если они не нужны то их просто можно отключить.

Ну, красота понятие очень индивидуальное. И то, что не нравится вам вполне возможно что понравиться кому-то другому.

Но что действительно бы не помешало так это премодерация дополнений на качество кода. К качеству кода можно отнести:

- соответствие стандартам кодирования Кстати под опенкарт я таких не встречал, если есть дайте ссылку, если нету значит нужно создать.

- соответствие шаблону MVC, чтобы не было sql запросов в контроллерах и тем более в представлениях итд.

- всегда использовать апи опенкарта там где это возможно

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

- не использовать слепой копипаст. Нужно создать что-то, скопировал 2 страницы кода движка, вставил в свой модуль, проверил, как-то работает.. и какая разница что там половина переменных не используется?..

- безопасность кода

- итд.

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

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

Что здесь? Любой "гений программирования" может на коленке сделать свой первый модуль и выставить за него любую цену.. И это вообще никто не проверяет?

кстати ваш поиск ищет только в названии товара и все? или в модели, артикуле, в описании?

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

жду Вашего ответа, касательно совместимости с Opencart 1.5.1.3

проверил, все работает

нет

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

Если у вас поиск уже измененный то модуль без доработок к нему подключить не получится. Модуль вместо стандартных методов модели использует их измененные версии. В админки все что на скрине. Там опций не много.

модуль работает на OpenCart 1.5.1.3 ?

как модуль справляется если товаров 100 000 или более?

на OpenCart 1.5.3.1 модуль не проверял, завтра проверю, отпишу. Думаю, должен работать, если не будет то сделаю.

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

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

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

Спасибо всем за ответы, ситуация немного прояснилась.

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

Но этот плюс является и большим минусом.

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

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

То есть сэкономив немного времени сначала можно получить немало проблем из-за несовместимости потом.. :/

Если не встанет поможете соединить? Если они похожи то наверно и встанет без проблем?

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

А вы можете настроить на работу с модулем ajax search, им много кто пользуется просто. Мне кажется будет полезным.

Все можно, вот только времени на все нету..

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

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

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

Вопрос к автору мода. вы поддержку оказываете после покупки?

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

спасибо большое добрый программер, а не мог бы ты выложить именно тот кусок, что ты поправил, а то свой product.php уже не тот)))

product.php.diff.zip

В последнее время все чаще получаю сообщения типа "А будет ли ваш модуль работать на МаксиСторе?" Уже третий или четвертый подобный вопрос за последних 3 дня..

Получается сборка достаточно популярная. Но немного поискал на этом форуме инфу об этой сборке и почти ничего не нашел.

Да, достаточно много негатива но ничего конкретного.

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

Хочется услышать от людей, которые работали с MaxyStore, кто что о ней думает? По возможности больше конкретики.

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

Просто с одной стороны достаточно много людей просит переделать модули под MaxyStore, а с другой даже не знаю стоит ли вообще с ней связываться..

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

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

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

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

Сейчас нету времени, потом гляну в чем тут проблема, скорее всего какая-то опечатка в коде..

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