sv2109

Короче, создал только что новый issue в оф. репозитории https://github.com/opencart/opencart/issues/11800 если не сложно - поддержите. Сильно сомневаюсь что это что-то изменить, вероятно Даниель напишет что все разработчики ламеры ничего не понимающие в программировании и только он один самый лучший и все делает правильно и.. закроет это обращение, но я хотя бы буду знать что попытался.

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

это идеальный вариант, но почти нереальный, не может версия 4 поддерживать модуль написанный под напр. 1.5 когда еще не было ни твига ни бутстрапа ни событий + файловая структура была совсем другой итд. Или если тянуть в версию 4 совместимость со всеми предыдущими то код движка будет настолько громоздким и запутанным что это будет наверное еще хуже, чем то что есть сейчас.. да и работать все это будет в разы медленнее из-за огромной кучи очень старого кода. Поэтому у других движках есть правило - совместимыми должны быть модули на уровне главной, мажорной версии движка, напр. если модуль написан для версии движка 2.0 то он должен работать и на 2.1.х.х и на 2.2.х.х и на 2.3.х.х и на 2.х.х.х. Все большие изменения, которые ломают совместимость при этом накапливаются, обкатываются на каких-то дев. версиях и добавляются уже в версию 3.0 (весь старый и ненужный код при этом выбрасывается за ненадобностью), после чего ничего нового и глобального уже не добавляется до версии 4 и так далее. И это очень правильный подход. Разработчик написал модуль для 2.0 и все, он уверен на 100% что этот модуль будет работать на всех подверсиях двойки сколько бы их не было. И пользователь уверен что если он купит модуль под 2.0 то сможет им пользоваться даже на версии 2.99 если она когда-то выйдет. Ну вот почему же так не сделать?! Все же от этого только выиграют и разработчики и пользователи и даже сам движок. А не так что модуль написанный для 4.0.0.0 уже не работает на 4.0.1.0 и это даже не минорная версия, потому что минорная версия это 4.1, а это по логике вообще патч версия для очень мелких изменений и исправлений различных багов, которая по всей логике вообще никак не должна влиять на совместимость..

в 4.0.0.0 була підтримка підпапок, тобто можна було файл назвати наприклад sv2109_event_manager_oc4.0_v1.0.ocmod.zip а вже всередині мати папку sv2109_event_manager (і це буде кодом) з файлом install.json. Але в 4.0.1 це забрали, тепер файл install.json має лажати виключно в корені а назва файлу буде автоматично кодом.

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

Решил создать бесплатный модуль для OpenCart 4 но столкнулся с целой кучей нюансов, которые превращают разработку в сплошной ад.. 1. В 4.0.0.0 можно создать архив модуля с подпапками и он работает, а в 4.0.1.1 уже не работает 2. В 4.0.0.0 вы можете добавить новое событие следующим образом: $this->model_setting_event->addEvent($code,$description,$trigger,$action,$status,$sort_order); но в 4.0.1.0 уже используется массив для событий, что конечно лучше, на зачем же такие изменения делать в минорных версиях!? $this->model_setting_event->addEvent($event); 3. до 4.0.2.0 маршруты были с "|" разделителем: 'marketplace/event|save' но с 4.0.2.0 это уже ".": 'marketplace/event.save' (см. https://github.com/opencart/opencart/issues/11594) 4. 4.0.0.0 использует функцию utf8_strlen() но 4.0.1.0 использует \Opencart\System\Helper\Utf8\strlen И так далее. И вам нужно либо создать отдельную версию модуля для каждой версии OpenCart (и поддерживать их все в будущем), либо добавить кучу конструкций if (version_compare(VERSION... в свой код. И это только малая часть, то, что с чем я сам столкнулся непосредственно. И это при том что вышло всего-то пару минорных версий. Еще даже не версия 4.1.. Что будет в версии 4.3?.. Почему нельзя все подобные изменения которые ломают совместимость модулей внести сразу в главную версию, а потом уже не трогать до новой главной версии? Или если так хочеться изменить то сделать это так, чтобы не поломать совместимость? Можно же в методе addEvent прописать логику, что если там первій параметр это массив то брать данные оттуда, а если строка то брать данные из аргументов. И все, все работает и никому не нужно ничего изменять. Тоже самое с разделителем в маршруте итд. Но нет, нужно добавить целую кучу мелких изменений которые полностью ломают совместимость всех модулей и то что работает на 4.0.0 уже не будет работать на 4.0.1, а то, что работает на 4.0.1 уже не будет на 4.0.2.. Пц.. + документации нету вообще никакой, все приходится искать самостоятельно в коде. + модификаторов в 4 версии нету, убрали полностью, а События покрывают только малую часть функционала и.. выкручивайся как хочешь, уже есть vqmod для 4 версии опеканрта.. добавили его еще в 1 версии движка, чтобы в версии 2 заменить на модификаторы, а в версии 4 отказаться от модификаторов и вернуться обратно к vqmod?.. У меня есть какое-то скрытое чувство, что Даниель люто ненавидит всех разработчиков OpenCart...

Если никакие доп. программы не нужны типа фотошопа то я как линуксоид бы посоветовал линукс, например Ubuntu (достаточно легкая, красивая и функциональная) ну или Linux Mint (у меня сейчас на рабочем ноуте установлен) Какой-то старой флешки на 4 гига должно хватить.

Поправьте перевод, а то не понятно на каком это языке

Завантажити / Придбати розширення Event менеджер Что делает этот модуль? Модуль улучшает страницу События (Events) в OpenCart 4.0. Он добавляет следующий функционал: Возможность редактировать события, изменяя все поля в них. Возможность создавать новые события через админку а не через программный код. Фильтровать существующие события по таким полям: код, trigger, action, статус Совместимость: OpenCart 4.0 (4.0.0.0, 4.0.1.0, 4.0.2.0) Другие мои модули, которые могут Вас заинтересовать: Поисковая система з морфологиею и релевантностью Search suggestion - поиск с автодополнением Акции, Подарки PRO 4.0 PRO Статусы Товара PRO Speed, автостатусы, стикеры, текстовые статусы и много других Также можете обращаться ко мне, если вам нужна помощь по OpenCart, программированию разработке модулей для OpenCart. Для связи пишите в ЛС на форуме или по почте [email protected] Автор sv2109 долучення 07.10.22 Категорія Модули Системные требования Метод активации Без активации Ioncube Loader Нет ocStore Несовместим OpenCart.Pro, ocShop Звернення до сервера розробника Нет  

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

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

Спасибо, но чуда не произошло

да, вообще любой файл, например info.php

Сам спросил, сам проверил, сам отпишусь. Не работает У меня енкодер 10.2, лицензия закодировал им файл для php 7.1 (также пробовал для 7.2) и на 8.1 не работает этот файл. Возможно, если закодировать используя более новый кодировщик версии 11 то будет работать, не знаю, не имею возможности проверить, если у кого-то есть возможность - проверьте. Придется похоже покупать новую лицензию, а это 299$, обновиться можно вроде за 230$ или подождать черную пятницу тогда обычно делают очень хорошие скидки аж до 50% наверное так и сделаю. Спешить пока некуда, OpenCart начал поддерживать php 8 только с версии 4 но на ней я пока еще не видел рабочих сайтов, по крайней мере никто из клиентов не обращался. И еще одну странность увидел. Когда у меня стояла php 8.0 то я не мог установить лоадер, визард написал что версия не поддерживается. Похоже лоадер поддерживает только php 7.4 и сразу 8.1, а 8.0 почему-то нету.. что конечно не очень хорошо, так как у некоторых клиентов может быть 8.0 и на него они не смогут установить лоадер.

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

Если включить Только верхний уровень то вы как раз и получите только главные категории без второстепенных.

Ура, свершилось. Информация с оф. сайта ionCube News 12th Aug 2022 - Encoder version 12.0.0 Encoder version 12, with support for PHP 8.1 has now been released. There are accompanying version 12 loaders. Кто попробует - отпишитесь. Интересует такой вопрос - я покупал лицензию на кодировщик, но уже достаточно давно, несколько лет назад, до этого все работало, кодировал файлы под PHP 7.1 и они отлично работали на 7.2,7.3,7.4. Но будет ли теперь работать на 8 или нужно опять покупать лицензию на новый кодировщик, ведь в старом нету поддержки php 8, максимум 7.2.

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

Здравствуйте, в модуле нету функционала выгрузки товаров. Можно делать или через базу данных, напр. через phpMyAdmin или можно дописать этот функционал для модуля, если нужно. По "отметить товары" не понял где отметить, для какой цели?

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

Спасибо за код Но.. вот у меня скорее риторический вопрос - и чем же это улучшает ocmod? 1. код становится намного сложнее. 2. из-за п.1 этот код уже никак не напишет обычный пользователь, в отличии от модификаторов, которые могли изменять все 3. искать конфликты теперь будет очень веселым занятием.. Ведь если раньше все изменения хранились в одном месте то теперь они размазаны по контроллерах всех модулей. Если раньше измененный код всех файлов можно было найти в одной папке то где сейчас смотреть измененный код шаблонов через события? Он вообще где-то сохраняется? 4. конкретно в этом примере мы получаем еще и ужасный код, где в php контроллере мы имеем еще и куски html кода да еще и с буферными функциями.. С самого начала своего существования опенкарт старался избегать этого для этого была использована MVC архитектура, а теперь.. привет начало двухтысячных когда весь код был таким. 5. метода insertString я так понимаю в самом движке не додумались добавить (я не могу найти) чтобы все было одинаково у всех, следовательно каждый разработчик будет писать какой-то свой велосипед для этого и потом для поиска конфликтов и их исправления придется разбираться еще и в каждом таком велосипеде каждого разработчика, который может быть еще и закодирован.. И самое главное! 6. существенно работа с шаблонами таким способом по сути вообще никак не отличается от модификаторов, она осталась такой же плохой - через какие-то строковые функции или регулярки изменяем html код шаблонов. И что будет если 2 модуля захотят изменить тот же самый кусок кода?.. те же самые конфликты что и были при модификаторах, только теперь найти и исправить такой конфликт будет раз в 10 сложнее чем это было с модификаторами.. Вся суть событий в том, чтобы избежать подобных конфликтов и из-за этого целесообразно терпеть большую сложность кода, если код будет чуть сложнее, но и работать будет намного стабильнее и без конфликтов то на такую жертву вполне можно (и даже нужно) пойти. НО если код и разработка стали намного сложнее, но к-во конфликтов при этом останется такой же, да еще и исправление этих конфликтов усложнилось в разы, то какой в этом вообще смысл?..

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

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

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