sv2109
-
Публікації
3 686 -
З нами
-
Відвідування
Тип публікації
Профілі
Форум
Маркетплейс
Статті
FAQ
Наші новини
Магазин
Блоги
module__dplus_manager
Усі публікації користувача sv2109
-
- сложность решения этих конфликтов - vqmod это неправильное решение, которого нету ни в одном другом движке, будущее за Событиями, а vqmod скорее всего уйдет с какой-то 3 версии opencart - vqmod не покрывает всего кода - например им невозможно заменить установочные файлы (а хочется же добавить логотип ocstore в установку, добить русский язык, поменять какой-то текст, внести изменения в таблицы базы данных итд.), css, js файлы. - намного солиднее выпустить отдельную сборку, а не кучу xml файлов, при установке которых на рабочие сайты появится куча конфликтов. - создание изменений через vqmod и отладка их занимает намного больше времени, чем изменение самих файлов - изменяя сами файлы можно использовать для работы git для например сливания изменений с оригинальной версии через обычный merge
-
О недостатках vqmod/ocmod я уже не раз писал на этом форуме, даже в этой теме, а так же в своем блоге, повторять, что уже не раз обсуждалось, не буду. И что же он решил? Если так же добавил в opencart События? Именно События, а не ocmod, это будущее opencart, потому что системы на подобии Событий, есть во всех современных движках, в то время как недорешение под названием vqmod/ocmod есть только в opencart..
-
конечно, спор идет о том делать ли сборку полностью на vqmod (то есть все изменения делать через vqmod) или делать как и раньше (то есть сразу изменять код)
-
Чтобы решить спор - предлагаю делать ocStore 2.0 без vqmod, а для markimax создать отдельную ветку и пусть, если ему так нравится, переносит все на vqmod :) vqmod это зло, а делать целую сборку на vqmod это зло в квадрате, если сборка ocstore выйдет на vqmod я лично ее использовать не буду, лучше уже чистый opencart, да и всех буду отговаривать использовать эту сборку.
-
найти не проблема, проблема исправить конфликт, если 2 модуля заменяют тот же кусок кода через vqmod replace, или даже офсеты используют. Исправить, конечно, можно но это в разы сложнее чем исправить конфликт, где все изменения в самом коде. единую для ocStore? :) после чего для каждого модуля придется делать 2 отдельные версии, потому что ocStore далеко не все используют.
-
не совсем, если изменения в самом коде то и конфликт находится быстро и исправляется тоже быстро, изменением этого кода. а если изменения в vqmod то нужно сначала найти причину конфликта, после чего поломать голову как его исправить, потому что все изменения через vqmod replace.. и приходиться для исправления конфликта понимать какой vqmod файл вызывается первым, что и как там нужно изменить.. после чего менять vqmod файлы других модулей. Пример
-
Да, но исправлять подобные конфликты очень проблематично. Поэтому я за то, чтобы vqmod использовался по минимуму, а делать целую сборку на vqmod c изменением тысяч строк кода.. категорически нельзя.
-
не только, это также существенно усложнит исправление этих конфликтов. Например если 2 модуля изменяют один и тот же кусок кода через "replace"..
-
только лично моих модулей несколько штук нужно было писать отдельные версии для opencart и ocstore. например: модуль Attribute Category для добавления атрибутов нужно было создавать разные механизмы, так как в ocstore есть главная категория для товара, а в opencart нету модуль Group Price - не работала пагинация в категориях, потому что в ocstore используется getFoundProducts() и FOUND_ROWS вместо стандартной модели, да это увеличивает скорость, но если мой модуль вызывает свой метод в getProduct то FOUND_ROWS сбивается модуль Поиск с морфологией и релевантностью - пришлось переписывать vqmod из-за того же getFoundProducts вместо getProducts это то что что вспомнилось и это только мои модули. Это аксиома - чем больше изменений будет в движке - тем больше будет конфликтов с другими модулями.
-
Пожелания-предложения: Чем меньше будет изменен движок от оригинальной версии - тем лучше. иначе, учитывая специфику опенкарта, где все делается через одно место vqmod, почти любое изменение движка в будущем даст кучу конфликтов и головной боли пользователям, потому что модули, которые работают на оф. версии не будут работать на сборке.
-
небольшой баг, замените в этом файле: if (isset($files[0]) && file_exists($files[0])) { $cache = file_get_contents($files[0]); $data = unserialize($cache); } return $data; на if (isset($files[0]) && file_exists($files[0])) { $cache = file_get_contents($files[0]); return unserialize($cache); }
-
если переменные в GET, в url, то можно использовать например encodeURIComponent(); если переменные в объекте то их нужно как-то перевести в строку, например $.param(Obj); да куча вариантов, пробовать нужно
-
1000 - это к-во переменных, длина тут не учитывается? как-то сжать все переменные в одну, а на сервере по обратному алгоритму разжать и получить 1000.
-
extesion::sql? в 1.5.6.4. похоже что нигде она не используется, возможно осталась со старых версий. в 2.0 ее уже нету.
-
спасибо за отзыв + я вижу у вас установлен filter PRO и работает нормально с BOOST.
-
ух ты! не знал, я думал только через ctrl-f5 кеш браузера сбрасывается, действительно все из кеша, кроме самой страницы, только некоторые картинки даже из кеша грузятся за 600-800 мс. но тут уже наверное ничего не сделаешь.. и я так понимаю, что https://developers.google.com/speed/pagespeed/insights/ никакого кеша не использует, поэтому для пользователя скорость будет намного больше, чем для этого скрипта.
-
Далеко не все грузится из кеша, достаточно открыть в хроме инструмент разработчика, вкладку Network и перегрузить страницу. Я там вижу: http://demo.sv2109.com/ocstore1551/ - 79 мс. - это результат работы BOOST, без BOOST было бы 200-2000мс. дальше: stylesheet.css - 60 мс (не из кеша) slideshow.css - 63 мс (не из кеша) еще штук 5 css и около 10 js и штук 15 картинок (не из кеша) штук 10 картинок, очень мелких - из кеша. может у меня просто не настроен кеш в браузере, но раз не настроен у меня значит не настроен и в огромного к-ва пользователей, поэтому это никак не совершенно не важно - время загрузки картинок и скриптов очень существенное.
-
может вам подойдет готовый модуль: https://opencartforum.com/files/file/2195-%D0%B0%D0%BA%D1%86%D0%B8%D0%B8-%D0%BF%D0%BE%D0%B4%D0%B0%D1%80%D0%BA%D0%B8/ или что не устраивает в модуле то можно доработать, просто создание модуля на заказ будет стоить в разы больше чем покупка или даже переделка готового модуля.
-
Там анализируется куча параметров, загрузка основного кода страницы это только 1 из них. Модуль увеличивает и очень сильно увеличивает, в десятки и сотни раз, скорость создания страницы на сервере. Как следствие, это также увеличивает скорость загрузки страницы. Но на скорость загрузки страницы влияет еще куча факторов, таких как к-во скриптов на странице, к-во картинок, объем кода, скорость интернета итд. Поэтому даже если основная страница загрузилась очень быстро, потом еще догружается все остальное и это также влияет на скорость.
-
если цена обновляется через сторонний модуль, то открыть фай этого модуля и после обновления добавить: $this->load->model('module/boost'); $this->model_module_boost->clearCache(); это очистит кеш после обновления цен этим модулем
-
не проверял, но с другими модулями кеширования этот модуль работает, должен и с турбо кешем работать, в крайнем случае или помогу настроить или верну деньги.
-
в модуле весь кеш чиститься автоматически после редактирования товара, поэтому ситуации, когда на сайте старая цена быть не должно я считаю, что это вообще не критично, очистить весь кеш после чего он опять будет создан. кеш (особенно memcache) нельзя воспринимать как запись в базе данных, которая гарантированно там будет, это скорее помощник - есть - отлично, нету - создадим еще раз, ничего страшного, ведь создав кеш 1 раз потом мы его используем сотни раз. // все страницы проверяются на дату изменения товара и если она отличается, то кеш для такой страницы сбрасывается. для этого нужно обратится к базе данных, а BOOST чтобы увеличить скорость не использует базу данных.
-
кешируется вся страница и что вы предлагаете? всю страницу кеширвать без цен, после чего что? подгружать цену для каждого товара через аякс? тогда на каждой странице у вас будет 50 аякс запросов и страница вместо 1 секунды будет грузиться 10 или даже больше. Наоборот для большого сайта и выгоднее использовать такой вид кеширования, так как после первой загрузки на большом сайте эту страницу могут открыть еще сотни раз, и каждый раз страница будет открываться очень быстро. Отличие этого модуля от других модулей кеширования я писал раньше: https://opencartforum.com/topic/42604-boost-%D1%83%D1%81%D0%BA%D0%BE%D1%80%D0%B8%D1%82%D0%B5%D0%BB%D1%8C-opencart-ajax-%D0%B7%D0%B0%D0%B3%D1%80%D1%83%D0%B7%D0%BA%D0%B0-%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B5%D0%B9/?do=findComment&comment=359043
-
Я так уже 2 года модули продаю, иногда в модулях старые версии модулей, иногда инструкция как получить модуль. Но актуальная версия модуля скидывается на почту. Да и где в правилах сайта написано, что так делать нельзя? Сайт свою прибыль получает? Да. Покупатели жалуются? Если кого-то из покупателей это не устраивает - у них всегда есть выбор не покупать модуль, я никого не заставляю.
-
Нет, по умолчанию нет. Модуль кеширует только запросы к тем контроллерам, которые прописаны в настройках. Аякс запросов там нету. Кстати, нужно как-то решить вопрос с вашим модулем Фильтр Про, могу скинуть вам код модуля чтобы вы посмотрели или скиньте мне модуль фильтра на [email protected] я попробую разобраться. 1 покупатель жалуется что у него как-то через раз Фильтр Про работает вместе с BOOST. Хотя ajax запросы Фильтр Про проходят.
