sv2109

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

Вас что на гугле забанили :) http://papermashup.com/truncate-text-with-the-jtruncate-jquery-plugin/ или http://viralpatel.net/blogs/dynamically-shortened-text-show-more-link-jquery/ или https://www.google.com.ua/search?q=jquery+shorten+text

Спасибо после нажатия на ентер в аякс поиске вы вместо стандартного поиска попадете на этот, это работать будет. Но сам аякс поиск будет по-прежнему работать так как и работал.. никакой морфологии и релевантности там не будет, для этого нужно этот модуль переделывать, добавлять этот функционал.

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

Вы что-то неправильно установили, отписал вам в ЛС

Есть готовый модуль.

буквально минуту назад модуль залил, возможно подойдет.

Там используется плагин colorbox http://www.jacklmoore.com/colorbox у него есть темы, например http://www.jacklmoor...orbox/example2/ и http://www.jacklmoor...orbox/example3/ где навигация сверху. пс не успел))

Обновления затронут системные таблицы, но не таблицы модулей. Все зависит от количества данных которые модуль будет в этой таблице держать. Если это десяток настроек то их смело можно пихать в setting и не париться. Но если это например модуль статей с кучей статей, то тут по любому нужна отдельная таблица

Кстати, хранить данные модулей в таблице settings не правильно. По 2-м причинам: 1. Эта таблица предназначена для небольших данных настроек, что и следует из названия 2. Все эти настройки грузятся при каждой! загрузке опенкарта. Если там просто настройки модуля, тогда нормально. Но если там десятки статей или html блоков то так категорически нельзя делать. Но многим авторам просто впадло создавать свои таблицы + для них еще модели писать нужно.. и в результате пихают все в таблицу settings, работает ну и ладно..

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

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

Больше информации тут http://www.slideshar...numbers-take-ii В последнем коммите на гитхабе ее вроде устранили только не понятно пойдет ли это уже в новую версию или выпустят апдейты и для старых версий. пс гитхаб коммит можно скачать в виде патча правда времени проверить можно ли его применять и на какую версию сейчас нету.

например создать 2 модуля - один кинуть в колумн лефт, другой в колумн райт после чего в каталоге в контроллера модуля получить значение position и в зависимости от условия вернуть или код модуля или false.

если найду время то в ближайшую неделю сделаю

пока нет

странно, что у вас группа ftp имеет меньше прав чем апач, обычно наоборот бывает. через эту модель происходит ресайзинг картинок. Но заливаются они через файловый менеджер. Значит менять права нужно в первую очередь в файловом менеджере.chmod('файл', 0666) - разве не работает? зачем ставить для картинок 777?

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

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

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

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

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

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

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

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