Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

sv2109

Users
  • Posts

    3,685
  • Joined

  • Last visited

Everything posted by sv2109

  1. О недостатках vqmod/ocmod я уже не раз писал на этом форуме, даже в этой теме, а так же в своем блоге, повторять, что уже не раз обсуждалось, не буду. И что же он решил? Если так же добавил в opencart События? Именно События, а не ocmod, это будущее opencart, потому что системы на подобии Событий, есть во всех современных движках, в то время как недорешение под названием vqmod/ocmod есть только в opencart..
  2. конечно, спор идет о том делать ли сборку полностью на vqmod (то есть все изменения делать через vqmod) или делать как и раньше (то есть сразу изменять код)
  3. Чтобы решить спор - предлагаю делать ocStore 2.0 без vqmod, а для markimax создать отдельную ветку и пусть, если ему так нравится, переносит все на vqmod :) vqmod это зло, а делать целую сборку на vqmod это зло в квадрате, если сборка ocstore выйдет на vqmod я лично ее использовать не буду, лучше уже чистый opencart, да и всех буду отговаривать использовать эту сборку.
  4. найти не проблема, проблема исправить конфликт, если 2 модуля заменяют тот же кусок кода через vqmod replace, или даже офсеты используют. Исправить, конечно, можно но это в разы сложнее чем исправить конфликт, где все изменения в самом коде. единую для ocStore? :) после чего для каждого модуля придется делать 2 отдельные версии, потому что ocStore далеко не все используют.
  5. не совсем, если изменения в самом коде то и конфликт находится быстро и исправляется тоже быстро, изменением этого кода. а если изменения в vqmod то нужно сначала найти причину конфликта, после чего поломать голову как его исправить, потому что все изменения через vqmod replace.. и приходиться для исправления конфликта понимать какой vqmod файл вызывается первым, что и как там нужно изменить.. после чего менять vqmod файлы других модулей. Пример
  6. Да, но исправлять подобные конфликты очень проблематично. Поэтому я за то, чтобы vqmod использовался по минимуму, а делать целую сборку на vqmod c изменением тысяч строк кода.. категорически нельзя.
  7. не только, это также существенно усложнит исправление этих конфликтов. Например если 2 модуля изменяют один и тот же кусок кода через "replace"..
  8. только лично моих модулей несколько штук нужно было писать отдельные версии для opencart и ocstore. например: модуль Attribute Category для добавления атрибутов нужно было создавать разные механизмы, так как в ocstore есть главная категория для товара, а в opencart нету модуль Group Price - не работала пагинация в категориях, потому что в ocstore используется getFoundProducts() и FOUND_ROWS вместо стандартной модели, да это увеличивает скорость, но если мой модуль вызывает свой метод в getProduct то FOUND_ROWS сбивается модуль Поиск с морфологией и релевантностью - пришлось переписывать vqmod из-за того же getFoundProducts вместо getProducts это то что что вспомнилось и это только мои модули. Это аксиома - чем больше изменений будет в движке - тем больше будет конфликтов с другими модулями.
  9. Пожелания-предложения: Чем меньше будет изменен движок от оригинальной версии - тем лучше. иначе, учитывая специфику опенкарта, где все делается через одно место vqmod, почти любое изменение движка в будущем даст кучу конфликтов и головной боли пользователям, потому что модули, которые работают на оф. версии не будут работать на сборке.
  10. небольшой баг, замените в этом файле: 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); }
  11. если переменные в GET, в url, то можно использовать например encodeURIComponent(); если переменные в объекте то их нужно как-то перевести в строку, например $.param(Obj); да куча вариантов, пробовать нужно
  12. 1000 - это к-во переменных, длина тут не учитывается? как-то сжать все переменные в одну, а на сервере по обратному алгоритму разжать и получить 1000.
  13. extesion::sql? в 1.5.6.4. похоже что нигде она не используется, возможно осталась со старых версий. в 2.0 ее уже нету.
  14. ух ты! не знал, я думал только через ctrl-f5 кеш браузера сбрасывается, действительно все из кеша, кроме самой страницы, только некоторые картинки даже из кеша грузятся за 600-800 мс. но тут уже наверное ничего не сделаешь.. и я так понимаю, что https://developers.google.com/speed/pagespeed/insights/ никакого кеша не использует, поэтому для пользователя скорость будет намного больше, чем для этого скрипта.
  15. Далеко не все грузится из кеша, достаточно открыть в хроме инструмент разработчика, вкладку Network и перегрузить страницу. Я там вижу: http://demo.sv2109.com/ocstore1551/ - 79 мс. - это результат работы BOOST, без BOOST было бы 200-2000мс. дальше: stylesheet.css - 60 мс (не из кеша) slideshow.css - 63 мс (не из кеша) еще штук 5 css и около 10 js и штук 15 картинок (не из кеша) штук 10 картинок, очень мелких - из кеша. может у меня просто не настроен кеш в браузере, но раз не настроен у меня значит не настроен и в огромного к-ва пользователей, поэтому это никак не совершенно не важно - время загрузки картинок и скриптов очень существенное.
  16. может вам подойдет готовый модуль: 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/ или что не устраивает в модуле то можно доработать, просто создание модуля на заказ будет стоить в разы больше чем покупка или даже переделка готового модуля.
  17. Там анализируется куча параметров, загрузка основного кода страницы это только 1 из них. Модуль увеличивает и очень сильно увеличивает, в десятки и сотни раз, скорость создания страницы на сервере. Как следствие, это также увеличивает скорость загрузки страницы. Но на скорость загрузки страницы влияет еще куча факторов, таких как к-во скриптов на странице, к-во картинок, объем кода, скорость интернета итд. Поэтому даже если основная страница загрузилась очень быстро, потом еще догружается все остальное и это также влияет на скорость.
  18. если цена обновляется через сторонний модуль, то открыть фай этого модуля и после обновления добавить: $this->load->model('module/boost'); $this->model_module_boost->clearCache(); это очистит кеш после обновления цен этим модулем
  19. не проверял, но с другими модулями кеширования этот модуль работает, должен и с турбо кешем работать, в крайнем случае или помогу настроить или верну деньги.
  20. в модуле весь кеш чиститься автоматически после редактирования товара, поэтому ситуации, когда на сайте старая цена быть не должно я считаю, что это вообще не критично, очистить весь кеш после чего он опять будет создан. кеш (особенно memcache) нельзя воспринимать как запись в базе данных, которая гарантированно там будет, это скорее помощник - есть - отлично, нету - создадим еще раз, ничего страшного, ведь создав кеш 1 раз потом мы его используем сотни раз. // все страницы проверяются на дату изменения товара и если она отличается, то кеш для такой страницы сбрасывается. для этого нужно обратится к базе данных, а BOOST чтобы увеличить скорость не использует базу данных.
  21. кешируется вся страница и что вы предлагаете? всю страницу кеширвать без цен, после чего что? подгружать цену для каждого товара через аякс? тогда на каждой странице у вас будет 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
  22. Я так уже 2 года модули продаю, иногда в модулях старые версии модулей, иногда инструкция как получить модуль. Но актуальная версия модуля скидывается на почту. Да и где в правилах сайта написано, что так делать нельзя? Сайт свою прибыль получает? Да. Покупатели жалуются? Если кого-то из покупателей это не устраивает - у них всегда есть выбор не покупать модуль, я никого не заставляю.
  23. Нет, по умолчанию нет. Модуль кеширует только запросы к тем контроллерам, которые прописаны в настройках. Аякс запросов там нету. Кстати, нужно как-то решить вопрос с вашим модулем Фильтр Про, могу скинуть вам код модуля чтобы вы посмотрели или скиньте мне модуль фильтра на [email protected] я попробую разобраться. 1 покупатель жалуется что у него как-то через раз Фильтр Про работает вместе с BOOST. Хотя ajax запросы Фильтр Про проходят.
  24. 1. Наличие и цену не кешировать не получится, да и зачем. 2. Теоретически можно написать сканер по принципу робота яндекса, который после запуска будет обходить все ссылки на сайте, тем самым создавая кеш для всех страниц.
×
×
  • Create New...

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.