sv2109

да, там стоит ограничение, сделал специально, так как у некоторых категории по несколько тыс. товаров напишите мне в ЛС напишу как отключить.

ответил вам на почту, Так работает опенкарт, он весь кеш кидает в одну папку. В будущей версии модуля я уже уменьшил к-во файлов кеша модуля. Но тут пока так. Что можно сделать 1. отключить кеширование в модуле 2. перейти из файлового кеша на напр. memcache 3. изменить библиотеку файлового кеша опенкарт файл /system/library/cache/file.php добавить в нее код, чтобы все кидалось не в одну папку, а разбивалось по папкам. Возможно кто-то уже даже написал какой-то модуль для этого, можно поискать.

Вышла новая, третья версия модуля Новое в версии 3.0 PRO: Добавлена поддержка OpenCart 3.0 Модуль переписан под архитектуру OpenCart 3.0, добавлена возможность установки через установщик дополнений Добавлена возможность ручного выбора ключа Google API прямо на странице поиска. Можно ввести несколько ключей через запятую в настройках модуля и когда закончился лимит по одному ключу, можно легко выбрать другой со списка прямо со страницы поиска изображений и не нужно для этого каждый раз переходить на страницу настроек модуля Улучшен поиск изображений, теперь отображается меньше ошибок при поиске изображений Улучшена загрузка изображений, теперь модуль определяет тип изображения не только по расширению, но и по exif данным, это позволило загружать изображения без расширений, раньше такие изображения не загружались с ошибкой "Не верный тип изображения" Добавлен фильтр по конкретному товару. Многие об этом просили, такой функции очень не хватало раньше, так как часто нужно найти картинки для конкретного товара. Товар можно найти по идентификатору товара, модели, SKU, любому слову из названия товара Улучшены фильтры, фильтр по наличию считает фактическое наличие товара на складе, а не его статус отсутствия Улучшена постраничная навигация по изображениям Улучшена работа с окном просмотра, добавлены ограничения по размеру экрана, чтобы большие изображения не открывались больше размера экрана, добавлена возможность просмотра изображений без расширений Улучшен дизайн модуля Много мелких улучшений по дизайну и коду Модуль стал более функциональным, красивым и удобным в использовании. 3 версия поддерживает OpenCart 2.x (2.0, 2.1, 2.2, 2.3), а также 3 версию движка. Версии для 1.5 на данный момент нету (так как 1.5 уже очень старая версия движка), но если будут желающие то можно будет сделать. Обновление модуля с 2 версии на 3 версию платное и стоит 250 рублей. Эта сумма включает как новую версию модуля так и поддержку по ее установке и настройке. Кому нужно обновление - пишите в ЛС или на почту [email protected] На странице модуля обновлены скриншоты, описание, ссылка на демо (для версии 2.3), а также добавлено видео с демонстрацией работы модуля.

В ЛС пишите

поддерживает

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

подойдет

1. Очень многие темы сделаны "на основе стандартной" но почему-то на стандартной теме работает, а на вашей - нет, значит причина скорее всего в каких-то особенностях именно вашей темы. 2. Вам нужно не "помочь разобраться", а "разобраться", я могу это сделать, но учитывая что, модуль вы приобрели уже больше года назад и причина в конфликте с вашей темой или каким-то вашим яваскриптом, то я могу это сделать если оплатите потраченное на эту работу время. 3. Модуль поддерживает аякс загрузку модулей, как написано в описании модуля , если в каком-то модуле, которые грузится через аякс (и загружается) не работают картинки по причине конфликта с темой или каким-то другим модулем, то это конфликт, который нужно исправлять, а не какая-то ошибка модуля.

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

нужно

если вы выводите какой-то модуль через аякс и он выводится, но без картинок, значил сам аякс работает. Но через аякс нужно стараться грузить простые модули, которые не используют яваскрипт, тогда все будет работать. Если же использовать какие-то скрипты, например какие-то галереи, слайдеры, скрипты ленивой загрузки изображений итд. в модулях, которые грузятся через аякс то эти скрипты по умолчанию работать не будут, нужно разбираться как они работают и после загрузки модуля через аякс подключать каждый такой скрипт. Но проще грузить модули без скриптов, тогда все будет работать. тут сложно что-то сказать, так как я никогда с этим модулем не работает и даже совсем с ним не знаком, но никто на проблемы с ним не жаловался до этого я недавно разбирался почему не работает. Boost сохраняет заголовки, с этим все нормально, но модуль для Last-Modified проверяет наличие этих заголовков и отдает 304 ответ уже после того как загрузился движок, а модуль Boost проверяет наличие данных в кеше и отдает кеш вместо того, чтобы грузить движок дальше до этого, следовательно до выполнения кода модуля Last-Modified просто не доходит. Как решить: 1. не использовать модуль Last-Modified, я недавно общался с автором этого (или похожего на ваш модуль) и он тоже согласился, что с Boost-ом этот заголовок не особо и нужен, так как Boost сам отдает готовый html код из кеша, без загрузки движка, поэтому отдача происходит очень быстро. 2. нужно код модуля Last-Modified, то есть проверку на то есть ли заголовок и если есть, то отдать 304 добавить ДО вызова модуля Boost в index.php (первой части кода модуля) тогда все будет работать. Кода там не много в модуля Last-Modified, можно это сделать. Только на этом этапе еще нету движка и объектов $response, $request, реестра опенкарт итд, нужно писать все на чистом php или если это возможно делать эту проверку в .htaccess что будет еще лучше, но если это возможно.

я же выше давал цифры по версиям php, на 5.6 прирост скорости с опкешем +16%, на 7.1 +20% то есть далеко не 5%

Опять специально замерил выполнение всех вызовов json_decode на opencart 2.3 (на самом деле там их не так и много, штук 5, не считая разные модули оплаты и других модулей, которые почти не используются типа openbay) и что у меня получилось? На весь магазин все вызовы json_decode выполняются аж.. 0.00047492980957031 секунды.. или пол миллисекунды.. вот и вся чудовищная нагрузка json_decode на опенкарт.. наверное вместо нее нужно использовать какую-то другую ф-цию, которая будет нагружать сервер меньше, может 0.4 мс вместо 0.5

1. Какие конкретные проблемы с опкешем? Я за уже больше 6 лет что работают с опенкартос ни разу не сталкивался с какими-то проблемами опкеша. Нет, я не спорю, может они и есть на каких-то конфигурациях серверов, то это явно скорее или исключения или кривость рук, тех, кто все настраивал. Да и почему это десятки других движков, которые в разы сложнее опенкарта с опкешем работают, а опенкарт вот вдруг вообще не может работать? 2. Специально проверил с выключенным опкешем, тот же сайт, то же железо 5.6 запросов Complete requests: 50 делает за Time taken for tests: 8.567 seconds запросов в секунду Requests per second: 5.84 [#/sec] (mean) среднее время одного запроса Time per request: 171.346 [ms] (mean) 7.1 запросов Complete requests: 50 делает за Time taken for tests: 6.771 seconds запросов в секунду Requests per second: 7.38 [#/sec] (mean) среднее время одного запроса Time per request: 135.429 [ms] (mean) То есть даже с выключенным опкешем прирост скорости все равно около 30% между 5.6 и 7.1

Чтобы не писать пустые посты решить проверить на реальных цифрах. Проверял на OpenCart 2.3.0.2 на версиях php 5.6 и 7.1 Просто эти 2 версии установлены на моем рабочем ноутбуке, то есть железо то же, все то же, просто переключался между версиями php, перезапускал апач и делал вторую проверку. И так 5.6 7.1 и коротко 5.6 Complete requests: 50 делает за Time taken for tests: 7.605 seconds запросов в секунду Requests per second: 6.57 [#/sec] (mean) среднее время одного запроса Time per request: 152.100 [ms] (mean) 7.1 Complete requests: 50 делает за Time taken for tests: 5.410 seconds запросов в секунду Requests per second: 9.24 [#/sec] (mean) среднее время одного запроса Time per request: 108.205 [ms] (mean) То есть на 7.1 опенкарт 2.3 работает больше чем на 40% (почти в полтора раза) быстрее, чем на 5.6 Вот вам реальные цифры, а не домысли из потолка о том, что для опенкарт версия php вообще никак не повлияет на скорость, ведь там оказывается база.. и сложного кода нету.. и вообще все работает коряво и не так как у всех..

И вот тут кстати подробное описание этого теста. https://habr.com/company/mailru/blog/326696/

Ну то, что 7 версия в 2-3 раза быстрее 5.6 уже давно не новость. На хабре есть сравнение производительности разных версий php (есть и 7.2) на разных движках, это более интересно, чем какой-то bench.php, так как там реальные движки https://habr.com/company/mailru/blog/350686/ А вот последняя колонка очень интересна, о том, что php 8 выйдет с поддержкой JIT компилятора я уже в другой теме писал, а тут даже тесты есть, получается с JIT php будет быстрее в 2 раза за 7.1! Это круто. Вот только выйдет php 8 года через 3..

1. О том где новая версия и когда она будет и причину почему ее еще нету я писал в теме поддержки версии для опенкарт 2.0 тут буквально на днях. Новая версия действительно почти готова и уже достаточно давно, доделать не мог по причине болезни, которая длится уже почти год. Как только станет легче сразу доделаю, я в этом тоже заинтересован. 2. Несмотря на это модуль развивается, вышла версия модуля для опенкарт 2, а также для опенкарт 3 3. Цена подарка должна падать в корзину с ценой 0, если она этого не делает, значит скорее всего конфликт или с темой или у вас установлен какой-то сторонний модуль корзины, исправление подобных конфликтов не входит в бесплатную поддержку и оплачивается отдельно 4. То, что модуль не делает каких-то фишек, которые нужны именно вам (например добавление подарка во всплывающее окно) и в нем не добавляются "интересные плюшки" это совсем не значит что модуль, плохой, не рабочий итд. и это не ошибки. Модуль должен делать, что описано в его описании, не больше. Если вам нужно, чтобы в модуле был какой-то функционал, которого на странице описания этого модуля нету то теоретически это можно сделать, если готовы оплатить время разработки этого функционала. Я вам это предлагал год или больше назад, когда вы мне писали. Вместо того, чтобы оплатить индивидуальную доработку вы написали администрации, что вас обманывают, заставляют платить деньги за разработку нового функционала (которого нету в описании модуля). Выслушав стороны конфликта администрация стала на сторону разработчика, согласившись, что требования покупателя до разработчика бесплатно реализовать новый функционал, которого нету в описании модуля абсолютно не обоснованными. То есть в вашем конкретном случае я не "не оказываю поддержку", вы просто хотите чтобы вам все сделали бесплатно, поэтому вам ничего и не делают бесплатно. 5. Поддержка по модулю оказывается постоянно всем покупателям, я оказываю помощь в установке и настройке модуля. В бесплатную поддержку не входит разработка нового функционала, который нужен именно конкретному пользователю, а также исправление конфликтов с другими модулями.

Еще одну реплику добавлю напоследок. Я считаю ocmod не просто злом, а самым большим злом, которое есть в опенкарте. В опенкарте есть очень много преимуществ: он простой, легкий, быстрый, достаточно функциональный из коробки и так далее. Но есть одно г.., которое буквально перечеркивает все эти преимущества и это именно ocmod (в прошлом vqmod) Это как в той народной мудрости о том, что ложка дегтя бочку меда портит. Точь в точь как у нас с опенкартом. И если бы ко всем тем преимуществам, которые уже есть в движке добавили нормальные события (предварительно изменив движок под них, напр. добавив конструктор запросов итд.) и выкинули нафиг ocmod (на первых порах можно оставить в статусе deprecated) то мы бы получили просто отличнейший движок, один из лучших в своем сегменте. А так.. имеем жалкое подобие этого.

Вот такая аналогия родилась Как Дениел видит ocmod И как я его вижу Нет, использование костылей в определенных ситуациях вполне может быть оправдано, напр. у вас посреди дороги отвалилось колесо, а до ближайшего автосервиса 500 метров, нужно срочно и тут вот такая чудо тележка под рукой.. почему бы и нет? Но как бы вы охарактеризовали человека, который так ездит 6 лет?.. Да еще и рассказывает всем какой он молодец, что придумал такой чудо метод! Как это до такого другие не додумались? Ведь это можно на все автомобили установить! Ему все: "Ну посмотри же, у всех нормальные колеса, у всех! Давай и себе установим!.. даже любое и ржавое и то будет намного лучше, чем есть сейчас", а он им: "Идите все нафиг, ничего вы в разработке не понимаете, я лучше знаю как нужно". И ладно бы это ноухау хвалил его создатель, но находятся еще и водители, которые ездят на этом чуде уже по 5 и больше лет, половину времени тратят на ремонт и тоже рассказывают как им всем классно им пользоваться.. Просто нужно с умом его использовать: не "гнать" больше 5 км в час, объежжать все ямы и можно вполне себе нормально ездить, то же самое колесо и даже во многом лучше - резину не нужно менять.. Короче, отписываюсь, не могу больше читать весь этот бред в теме.

Больше всего меня удивляют разработчики на опенкарт, которые защищают этот костыль. Ладно, это делают пользователи, которые ничего не понимают в коде, ладно это делают начинающие разработчики, которые еще толком не разобрались как все работает, но когда это делают те, кто работает с опенкартом уже по 5 и более лет, за это время ему пришлось исправить наверное сотни конфликтов из-за vqmod или ocmod и после этого он все равно пишет, что "А что? нормальный же инструмент, просто использовать его нужно правильно и все проблемы чудесным образом исчезнут.." то это просто фейспалм какой-то.. Вот вчера покупатель покупает модуль, устанавливает и пишет, что модуль не работает, после установки - белый экран. Я трачу кучу времени на переписку с покупателем "проверьте то, проверьте это, попробуйте так или так итд" ничего не помогает, прошу доступ, захожу на сайт, трачу еще время чтобы понять в чем проблема, оказывается, что контроллер моего модуля изменил другой модуль после чего все поломалось.. В файле quantity_control_PRO_for_OC_v1.5.xml автора [email protected] нахожу вот такой замечательный код <file name="catalog/controller/*/*.php"> <operation error="skip"> <search position="after"><![CDATA[$result['product_id'],]]></search> <add><![CDATA[ 'quantity' => $result['quantity'], 'minimum' => $result['minimum'], 'price_value' => $result['price'], 'special_value' => $result['special'], ]]></add> </operation> </file> то есть, в любом контроллере, нашли $result['product_id'], и втыкнули после него какой-то свой кусок кода.. в результате в моем модуле получаем ошибку 500 и белый экран и потом кому придется все это разгребать и искать почему все не работает? Разработчику, конечно.. И это по сути не ошибка разработчика (ни одного ни другого), тот, кто писал модуль quantity control все делал по сути правильно! Он использовал тот инструмент для создания модулей, который ему предоставил движок, он проверил код у себя и у него он работал, как он вообще может знать, какой код может потом написать другой разработчик? Это невозможно. И что изменит то, что я или кто-то другой напишет свой модуль правильно? Мой модуль, который не заработал вообще не использовал ни vqmod ни ocmod и все равно я получил ошибку 500. Потому что такой код как выше есть в тысячах!!! модулей опенкарта и в vqmod и в ocmod. Потому что проблема не в том что кто-то его использует правильно или не правильно, проблема в самом инструменте, который сам по себе не правильный! Неужели это так сложно понять? То, что в опенкарте нету аналогов, чем его заменить никак не делает его правильным, он как был костылем так и остался. PS vqmod или ocmod это по существу вообще одно и тоже, принцип работы абсолютно один и тот же, название другое и реализация немного другая, но проблемы один и те же, так как и такой код как выше и такой конфликт как выше может быть и там и там. Опять же смешно читать, как кто-то ругает vqmod, типа он вот весь такой плохой.. был.. да, а вот ocmod уже хороший, он совершенно другой.. ну еще один фейспалм..

Я этот перл даже заскринил))) от автора строк, о том, что "опенкарт самый лучший движок и фреймворк с самой лучшей архитектурой" Ocmod - это костыль и зло. Точка. Да, если! правильно и очень осторожно, только в самых крайних случаях его использовать и это будут делать вообще все разработчики то это сможет уменьшить к-во конфликтов. НО это только уменьшит к-во конфликтов может на 30%, может на 50%, но их все равно останется очень много, в разы больше, чем на системах, которые этот костыль не используют. Потому что и сам опенкарт написан так, что часто просто необходимо делать изменения через замену и далеко не все разработчики прислушаются к этим рекомендациям, особенно создатели тем, где в ocmod по 1000 строк кода.. и так далее. О чем вы вообще спорите? Ocmod просто берет кусок какого-то кода и тупо втыкает его в какое-то место в движке.. при этом ни разработчик, который вставил свой код до этого в тоже самое место ни разработчик который вставит свой код после этого знать ничего не знают о том, что кто-то этот код изменили, и тут не обязательно вставлять через замену, можно просто вставить до или после но добавить какое-то условие (которое необходимо даному модулю) которое поломает код другого разработчика.. Избежать подобных конфликтов просто невозможно, даже если все разработчики будут очень правильно использовать ocmod (чего никогда даже близко не будет) Тему создал @freelancer я так понял, что он пишет фильтр и ему нужно изменить SQL запрос получения товаров getProducts и как это сделать подключив свою модель? Нет, сделать конечно можно и даже очень просто - пишем свою модель, скопировав туда весь код из getProducts, изменяем ее как нам угодно и подключаем в своем контроллере и что? А то, что таким методом вместо того, чтобы избавиться от конфликтов мы их наоборот наплодили целую кучу, потому что на сайте может быть установлен с десяток модулей, которым тоже нужно изменить метод getProducts (а это один из самых изменяемых методов в движке) и которые или изменят оригинальную версию и работать ничего конечно же не будет, потому что контроллер будет вызывать модель фильтра, а не модель товара, или пойдут по тому же пути и создадут свои модели и получится полная жесть.. Вот вам и супер классный инструмент "совместной" разработки на супер классной архитектуре.. Я о том, что ocmod и конфликты это почти слова синонимы и избавится от конфликтов используя ocmod просто невозможно, в смысле вообще. При правильном подходе (которого никогда у всех не будет) можно немного знизить к-во конфликтов но это максимум.

Я 6 лет назад точно так же думал, ну прям слово в слово :))) еще чуть-чуть.. ну если не в этом году так в следующем.. а потом проходил год, потом еще один, потом еще и еще и еще.. и так 6 лет.

десятки движков отлично работаю через события и знать не знают что такое окмод, но вот только почему-то разработчики опенкарт вбили себе в голову, что без окмод ничего работать не сможет.. Нужен инициатор? Без проблем, что мешает каждому запросу присвоить свой идентификатор, напр. $query->id = "уникальный идентификатор"; Или что мешает объекту $query присвоить этот идентификатор автоматически из напр. названия класса и метода, что его вызвал? будет напр. $query->id = "model_catalog_product_getProduct"; После чего из своего модуля подключиться к событию, которое будет вызываться перед выполнением каждого запроса, напр. query_pre_execute(&$query) и сделать if ($query->id == "model_catalog_product_getProduct") { // изменяем запрос как нам угодно } Все, это первое что пришло в голову пока писал это сообщение, на самом деле реализовать все можно как угодно и никакой окмод тут вообще не нужен.

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