sv2109

Вышла 5-тая версия модуля, из нововведений: Добавлен фильтр по категориям. При поиске товаров модуль также находит категории всех найденных товаров с возможностью фильтровать результат поиска по любой из этих категорий. Фильтрация также может работать асинхронно через AJAX прямо в блоке поиска, может отображать также количество найденных товаров и сортировать результаты по названию или количеству найденных товаров. Добавлен режим вывода в одну строчку. Он доступен для всех групп: товары, категории, производители, информационные страницы и фильтр по категориям. Удобно выводить названия или изображения для категорий, производителей или фильтра. Добавлено новое поле для товара - Статус наличия на складе, раньше можно было вывести только количество товаров на складе. Добавлено условие для рейтинга товара, чтобы не печатать пустые рейтинги Изменен дизайн модуля Изменен дизайн админки Для удобного изменения CSS стилей был добавлен редактор с подсветкой синтаксиса. Исправлена ошибка поиска категорий и производителей при транслитерации, до этого модуль находил все значения в некоторых случаях. Добавлен украинский язык Другие более мелкие исправления и улучшения. Больше информации на странице модуля: https://opencartforum.com/files/file/2336-search-suggestion-poisk-s-avtodopolneniem-pro/ Также вышла новая, 4-тая версия модуля Поисковая система, новое: Поиск без учета языка. Теперь легко включается в настройках модуля. Пример: если на украинском языке ввести "одеяло" то найдет "ковдри" итд. Полностью переписана функция индексирования, теперь индексирование работает в разы, а иногда и в десятки раз быстрее. Полностью переписан механизм неточного поиска, теперь он работает иначе, намного лучше, чем раньше. Ищет с опечатками, неточным написанием, вхождение итд. Для работы нужен MySQL версии 5.7.6 и выше. Исправлена ошибка при которой поиск с большим количеством слов при логике поиска И на некоторых хостингах подвешивал MySQL сервер. Тут сразу 2 улучшения: - во-первых переписана логика поиска И, теперь она работает в разы быстрее и уже не должна нагружать сервер - во-вторых в настройках добавлено время выполнения поискового запроса, если время вышло то поиск просто завершается. Поиск по атрибутам теперь можно настраивать, указывать какие именно атрибуты нужно индексировать и искать только по ним, а не все сразу. В магазине может быть 50 атрибутов, а искать нужно только по атрибуту "Цвет", теперь это возможно. Сортировка результатов по наличию - теперь можно указывать конкретные статусы товара для товаров, которых нету в наличии. Можно, например убрать из результатов поиска товары "Нет в наличии" и "Снят с производства" но оставить "Под заказ" и "Ожидается через 2 дня". Возможно изменять логику поиска с И на ИЛИ во время поиска если ничего не найдено. Улучшена работа модуля с украинским языком. Улучшен дизайн, дополнительные настройки вынесены в отдельный таб. Исправлены другие ошибки, некоторые функции полностью переписаны, а также другие мелкие изменения и улучшение. Больше информации на странице модуля: https://opencartforum.com/files/file/3278-poiskovaya-sistema-s-morfologiey-i-relevantnostyu-pro/?tab=details

нет, не совсем. 6 пункт - да, я это написал выше. 4 пункт по ошибке это не то что я делал вам, вам я вроде обрезал большую фразу, тут же полностью переписан механизм поиск с логикой И + добавлен лимит на время выполнения запроса, совсем другой механизм работы. 7 пункт - я вам этого не делал, теперь в настройках можно установить чтобы сначала модуль искал по логике И и когда ничего не найдено то логика переключалась на ИЛИ по которой уже скорее всего что-то да найдет. какую именно, я планирую после окончания работы над новой версий этого модуля (уже почти готово, осталось тестирование) приступить к работе над подсказками, есть несколько идей, которые можно было бы реализовать там. Так что если чего не хватает - пишите, если это будет интересно не только вам то добавлю в модуль.

ответил вам в ЛС. Нет, не все. Из ваших доработок в новой версии может от силы процентов 5, остальные доработки совсем другие. + многих ваших доработок я не добавлял в модуль так как не считаю что они будут полезны для всех пользователей. Новую версию модуля вы можете получить бесплатно.

Кто-то хочет протестировать новую версию модуля? Желательно иметь магазин где будет несколько тыс. товаров чтобы протестировать скорость работы. Уже почти закончил работу над новой версией модуля. Много работы сделано, очень много изменений. Будет новая, 4 версия модуля. Из новых возможностей: 1. Поиск без учета языка. Теперь легко включается в настройках модуля. Пример: если на украинском языке ввести "одеяло" то найдет "ковдри" итд. 2. Полностью переписана функция индексирования, теперь индексирование работает в разы, а иногда и в десятки раз быстрее. У меня на локальном компьютере индексация теперь работает в 50 раз быстрее. 3. Полностью переписан механизм неточного поиска, теперь он работает иначе, намного лучше, чем раньше. Ищет с опечатками, неточным написанием, вхождение итд. 4. Исправлена ошибка при которой поиск с большим количеством слов при логике поиска И на некоторых хостингах подвешивал MySQL сервер. Тут сразу 2 улучшения: - во-первых переписана логика поиска И, теперь она работает в разы быстрее на больших запросах и уже не должна нагружать сервер - во-вторых в настройках добавлено время выполнения поискового запроса, если время вышло то поиск просто завершается. 5. Поиск по атрибутам теперь можно настраивать, указывать какие именно атрибуты нужно индексировать и искать только по ним, а не все сразу. В магазине может быть 50 атрибутов, а искать нужно только по атрибуту "Цвет", теперь это возможно. 6. Сортировка результатов по наличию - теперь можно указывать конкретные статусы товара для товаров, которых нету в наличии. Можно, например убрать из результатов поиска товары "Нет в наличии" и "Снят с производства" но оставить "Под заказ" и "Ожидается через 2 дня". 7. Возможно изменять логику поиска с И на ИЛИ во время поиска если ничего не найдено. 8. Улучшена работа модуля с украинским языком. 9. Улучшен дизайн, дополнительные настройки вынесены в отдельный таб. 10. Исправлены другие ошибки, некоторые функции полностью переписаны, а также другие мелкие изменения и улучшение.

все є

Не знаю хороші там комісії чи ні, але колись переводив через ось цей обмінник, кошти прийшли. https://100btc.kiev.ua/exchange_btc_to_monobankuah/ підпишусь на тему, може ще хтось щось порадить.

в лс я отвечаю всем, то не всегда могу ответить быстро так как работы много + есть рабочее время и ночью я не могу работать. Только что ответил.

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

Баг. В сообщениях есть такой функционал: "Покупки Ваших дополнений автором беседы:" тут показываются дополнения автором беседы, что очень удобно, но работает это неправильно. Например, сегодня у меня пользователь покупает дополнение, а в списке дополнений показываются дополнения, которые он купил раньше, в 2021, 2022 году, а сегодняшнего нету. Или кеш или не понятно по какой логике это работает. Или там какое-то ограничение на к-во дополнений, ну тогда нужно отсортировать по убыванию даты, чтобы отображать именно последние дополнения, а не так что старые показываются а новых тупо нету. Так как в этом случает теряется весь смысл этого функционала.

На самом деле достаточно полезно, даже для своего модуля посмотреть включен ли модификатор и написать сообщение пользователю в настройках модуля, что модификатор не найден или отключен, включите иначе модуль не будет работать как нужно. Ведь по сути в опенкарте эти 2 сущности (модификатор модуля и сам модуль на странице модулей) никак не связаны и их можно включать и отключать отдельно. Но такой функции готовой похоже что нету в движке. можно делать так $this->load->model('setting/modification'); $modification = $this->model_setting_modification->getModification($modification_id); или $modification = $this->model_setting_modification->getModificationByCode($modification_code); и дальше смотреть $modification['status']; хотя такие вещи должны быть в движке и даже имхо в каких-то хелперах или фасадах.

В ЛС ответил

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

Спасибо всем за ответы. Да, практически все описанное знаю и использую в работе. Наверное всем разработчикам эти моменты понятны, проблема скорее как это донести до заказчиков, что процесс разработки это условно не поклейка обоев, где можно рулеткой поменять периметр комнаты, умножить на стоимость погонного метра и получить точную стоимость с точностью до копейки сколько эта работа будет стоить. Тут все многократно сложнее и посчитать можно разве приблизительно и то не всегда, учитывая все особенности опенкарта, когда на одном сайте может работать десятки модулей, при чем какие-то будут работать через модификаторы, какие-то через события, а еще парочка вообще через vqmod.. при этом некоторые модули закодированы, некоторые обфусцированы, яваскрипт код минимизирован, а сверху еще установлена тема типа джорнал + еще парочка модулей кеширования и в такой ситуации даже если ты сутки будет изучать каждый файл этого сайта то все равно не можешь быть уверен в том, что твой код 100% будет работать без конфликтов.. а и какой заказчик заплатит тебе за то что ты будешь сутки изучать код.. да, это тоже использую довольно часто, очень хорошая практика. Особенно когда к тебе приходит заказчик с супер идеей мега модуля в котором будет 100500 функций.. тогда очень хорошо разбить все на этапы, на первом этапе реализовать самый-самый простой и базовый функционал, просто чтобы оно работало, отладить это и уже потом переходить к новому функционалу, чем делать все и сразу, так как тогда этот модуль можно вообще никогда не доделать. вот тут кстати не могу согласиться, так как ситуации бывают разные. Если искать клиентов на одну задачу - то да, это правильно. Но если искать клиентов с которыми можно работать долго то требовать деньги за каждый чих далеко не всегда правильно, иногда можно некоторую мелкую работу сделать и бесплатно, потом вы с этим клиентом будете работать еще не один месяц а то и год и за это время вернете себе эти деньги многократно. С другой стороны если за каждую мелочь очень категорично требовать плату то клиент просто перестанет с вами работать.

Потому что меня даже после 10 лет работы с опенкартом этот казалось бы простой вопрос "Нужно сделать ххх, сколько это будет стоить?" все еще иногда вводит в ступор. Потому что для того, чтобы определить стоимость нужно понимать время, которое нужно потратить на работу. А чтобы понимать время нужно: а) очень точно понимать суть задачи, а она в 95% не ясна точно, потому что хороших точных ТЗ в опенкарте (где бы было прописано все - и вся логика и структура базы данных и каждая настройка будущего модуля) я вообще ни разу не видел, и почти всегда это скорее какие-то общие фразы (типа "Нужно сделать модуль импорта, сколько это будет стоить?") и крайне мало конкретики, а потом начинаешь делать что-от и вылазит еще 100500 нюансов, о которых заказчик конечно же ничего не сообщил в начале. Вообще, написание ТЗ это отдельная и очень непростая работа, которая оплачивается отдельно, но кто из заказчиков готов за нее платить?.. б) очень точно знать и понимать весь код с которым приходится работать. А как тут можно быть уверенным, если на сайте может быть установлено несколько десятков модулей и все могут по-своему влиять на логику работы всего магазина и вашего кода в частности. И как тут вообще можно определить время и стоимость?! Если считать все очень точно, детально изучать весь код, самому писать ТЗ итд. то на это уйдет уйма времени, за которое заказчик или не заплатит или скажет "спасибо, я подумаю" и пропадет, потому что кто-то ему назовет меньшую цену не понимая всей сложности. + Даже если изучить все точно то все равно нету гарантии что ты учел вообще все возможные моменты. Если прикинуть все быстро и примерно + добавить несколько процентов сверху на возможные непредвиденные ситуации то опять же не факт что угадаешь, накинешь 30% а получится 60, накинешь 60 а получишь 90.. потому что всегда может вылезти какой-то конфликт на исправление которого придется времени потратить больше чем на всю работу.. И потом объяснить клиенту, что работа будет стоить дороже ой как непросто, а иногда и вообще невозможно, ведь заказчик просил тебя оценить работу и ты оценил, значил все проблемы теперь твои. Но ведь оценить на 100% просто невозможно. Идеальный вариант конечно работать по факту. Есть работа - делаешь, потом смотришь сколько времени на нее потратил, умножаешь на какой-то тариф и выставляешь счет. Идеально для программиста но не очень выгодно для заказчика, ведь он наперед вообще не понимает сколько ему обойдется работа и не превысит ли работа его бюджет + он также не уверен не дурит ли его разработчик, можно же работу сделать за условно 15 минут а сказать что потратил час.. Недавний случай. Обратилась за доработкой одна вроде серьезная фирма из вроде Болгарии, общение на английском, объяснили суть задание (скриншот и десяток предложений с описанием) задание небольшое и несложное, прикинул примерно стоимость, приступил к работе и началось.. то конфликты с нестандартной темой, то еще что-то. Потом от заказчика начали прилетать всевозможные правки типа тут вот нам нужно чтобы не так все работало и вот тут а еще вот тут посмотрите итд. После какой-то 3 или 4 подобной правки я вежливо намекнул, что я могу любую вашу задачу выполнить, но стоить это будет дороже.. на что получил ответ что я очень безответственный, так как определить стоимость - это задача разработчика и я вначале стоимость им назвал, они все оплатили и больше ничего платить не будут.. Пришлось завершить с ними работу. Но как тут можно было поступить иначе?

они это кто? Модуль Search Suggestion и Live Search - если я правильно понимаю что делают эти модули то они просто не могут работать вместе, так как делают то же самое - добавляют поиск с подсказками в шапке сайта, поэтому вам нужно использовать или один или другой модуль. Если это модуль Live Search и Поисковая система. То они могут работать вместе, но они будут работать отдельно и использовать каждый свою модель для поиска, так как подозреваю, что этот модуль не адаптирован для работы с Поисковой системой. Чтобы сделать чтобы и поиск в шапке сайта и поиск на странице поиска - Поисковая система работали вместе нужно или изменять код вашего модуля Live Search и писать интеграцию для него с модулем Поисковая система. Или вместо модуля Live Search установить мой модуль Search Suggestion у которого это уже реализовано из коробки + этот модуль обычно намного функциональнее простых модулей поиска в темах, в нем очень много настроек и поиск как товаров так и категорий, производителей, информационных страниц. Обычно пользователи берут 2 модуля - Search Suggestion и Поисковая система если им нужен и хороший поиск и поиск в шапке сайта и чтобы все работала как одно целое.

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

нет

Ответил вам в теме модуля Поисковая система, в ней это сделать проще

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

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

если нужно взять какой-то элемент у которого есть потомок с каким-то свойством то есть метод .has() в jquery или на чистом css тоже есть псевдоклас :has() уже поддерживается почити всеми современными браузерами.

Мне кажется вы путаете понятия класс и объект. Объект это экземпляр класса он создается через new А класс это условно шаблон для создания объекта. Статический метод - это метод класса, не объекта, когда объект еще не создан. Вы не можете из статического метода класса вызвать метод объекта потому что объект еще не создан. Вам нужно вначале создать объект (пусть даже из этого статического метода и потом вызывать методы этого объекта) но это очень нестандартный подход. Или через статический метод работать с такими же статическими методами или свойствами этого класса - так обычно и делается. Или использовать не статические методы для работы с методами объекта. пс. или в вашем статическом методе сделать как-то так не привязываясь к методам этого объекта Registry::get('language')->getLanguage('errors');

тройка да еще и ocstore

Похоже нашел баг в последнем 12 лоадере. (у клиента стоил ionCube24 v12.0.2 и php 7.3.3) Код закодированный 10 кубом не работает не 12 лоадере.. Причем заметил что некоторые функции работают, а некоторые - нет, получаю ошибку PHP Fatal error: Uncaught Error: Call to undefined function [obfuscated]() отключил обфускацию строк, проверил по коду и выяснилось что если использовать при кодировании обфускацию функций --obfuscate functions то перестают работать втроенные строковые функции mb_*: mb_strtolower mb_strlen mb_substr При чем раньше на 10 и 11 лоадере все работало отлично, а на 12 получаем undefined function [obfuscated]() решается добавлением этих функций в исключения

Ужасно плохо работает мультиязычность на форуме. В данной реализации пользоваться ею просто невозможно. Задался целью и добавил для некоторых своих дополнений английские описания. Но переключение языка по сути не работает. Например, захожу на англоязычную страницу со своими дополнениями https://opencartforum.com/en/files/developer/20996-sv2109/ 1. вся страница полностью на русском, хотя язык - английський 2. все ссылки на все модули на странице ведут на русские версии модулей, не на страницы с /en/ внутри Если зайти на страницу какого-то модуля и переключиться на английский язык, например https://opencartforum.com/en/files/file/3278-poiskovaya-sistema-s-morfologiey-i-relevantnostyu-pro/ 1. все ссылки на странице ведут на русскоязычные версии модулей 2. снизу блок с другими модулями, опять же все на русском - название, описание, ссылки 3. на странице куча текста вообще не переведенного, например "Метод активации: По запросу в ЛС" итд. + блок переключения языков находится в футере где его мало кто найдет. При такой реализации пользоваться этим функционалом фактически вообще невозможно. Просто представьте себя на месте какого-то англоязычного пользователя который зайдет на этот сайт.. переключение языка не работает, куча текста непереведенная, куча описания модулей на русском, фото на русском, опции на русском, в форуме все сообщения на русском итд. Какой смысл ему вообще тут что-то искать и покупать? Для русского и украинского языков это еще куда не шло (хотя переключение походу и там не работает), так как практически 100% украинцев понимают русский язык. Но для англоязычного пользователя наша кириллица это все равно что для нас китайские иероглифы. Вам сильно захочется покупать что-то на сайте, где 95% информации на китайском и переключение языка не работает?.. Я предлагал где-то полгода назад сделать английскую версию сайта для англоязычных пользователей, но я имел ввиду сделать полностью отдельный сайт или вообще на отдельном домене или поддомене или подпапке типа https://opencartforum.com/en/ (тут лучше посоветоваться с сеошниками какой вариант лучше) где развернуть копию магазина с форумом и там уже и добавлять все модули только на английском языке. Тогда вообще вся информация будет на английском, включая название, описание, фото, опции, поддержка на форум, даже ссылки на дополнения. Лучше пусть там будет 50 модулей но нормально, правильно оформленных, чем то, что есть сейчас, чем пользоваться вообще невозможно.