sv2109

все є

Не знаю хороші там комісії чи ні, але колись переводив через ось цей обмінник, кошти прийшли. 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 модулей но нормально, правильно оформленных, чем то, что есть сейчас, чем пользоваться вообще невозможно.

Короче, создал только что новый 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 має лажати виключно в корені а назва файлу буде автоматично кодом.