sv2109

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

можно открыть файл импорта и добавить в него 3 строчки кода и кеш будет очищаться автоматически.

нужно менять код модуля, иначе никак

После изменения товара весь кеш очищается, поэтому в кеше всегда актуальные данные. Модуль кеширует всю страницу, поэтому получается огромная скорость генерации и загрузки страницы.

В описании модуля есть информация, о том, что для работы модуля необходим ionCube. Я вам это уже 2 раза в ЛС написал, даже скрин выслал. Еще раз сюда продублирую: https://docs.google.com/file/d/0B2qVovNZWDJlR2Mzb3FMRl9EbWM/edit соответственно модуль у вас не работает не потому, что модуль не рабочий, модуль рабочий, он уже работает на десятках сайтов. Модуль у вас не работает потому, что у вас не установлен ionCube, установите его и модуль заработает. модуль не изменяет системные файлы, для работы модуля необходимо изменить 1 файл, добавит в него 4 строчки кода. Изменение файлов движка абсолютно нормально для модулей в опенкарте, почти все более менее сложные модули изменяют файлы движка через vqmod или там где vqmod изменить не может через правку файлов вручную. Если вам такой подход не нравится - берите другой движок для магазина, а не опенкарт.

Как вариант, больше использовать массивы и в шаблоне выводить все через foreach. Тогда в любой массив мы легко можем добавить новые элементы. Например. Как сейчас выводятся табы на странице товара? Все отдельно, прописывается каждый таб. Изменить что-то без модификации шаблона невозможно. А вот если бы все табы были в массиве, то через модификацию данных до рендеринга страницы, мы можем легко добавить новый элемент этого массива и в товаре появится новый таб без изменения кода шаблона! Это пример но суть думаю понятна. То же самое можно сделать с другими элементами на странице, например с полями товара. К-ва запросов я не вижу где бы выросло, это же темизация, данные товара получаются также, теми же запросами, просто логика отображения другая.

есть также studio.services, studio.expert, studio.business итд. которые можно купить за 2-3 тыс. рублей, а не за 60 тыс. Это получается как в том анекдоте про мужика, который курицу за 1000 долларов продавал.. потому что деньги нужны были :))

Для доменов в нормальных зонах (ru,com,net,ua) DNS Lookup составляет доли миллисекунд и даже не отображается браузером. А 200 мс. это очень много, это значит, что каждая страница для пользователя будет грузится на 200 мс. больше, а время загрузки страницы учитывается даже поисковиками для ранжирования.

Если есть репозиторий, который держит историю всех изменений то зачем эти изменения держать в патчах? Если разговор идет о создании сборок то просто держим все в git, пилим свою сборку, периодически сливаем изменения с оф. версии opencart, исправляем конфликты (а если сливать регулярно то конфликтов почти не будет) и получаем новую версию ocstore, причем получаем ее не через пол года, как сейчас, а через 2 дня или даже если все оперативно делать то и через 2 часа после выхода новой версии opencart. 1. В шаблон передается массив с данными, то есть перед генерацией страницы можно добавить событие, типа pre_render, с помощью которого можно будет изменить любую переменную перед генерацией страницы из шаблона, это уже будет огромный прорыв, отпадет потребность в сотнях vqmod файлов, который меняют эти переменные шаблона. 2. Менять шаблон через vqmod не самая лучшая идея, так как шаблоны то все разные, при чем есть очень нестандартные. Я никогда в своих модулях не меняю шаблоны через vqmod, вместо этого пишу инструкцию: в этом файле добавить вот это после этого.

В подобных доменов большой DNS Lookup, например на этом сайте - это 200 мс. То есть целых 200 мс. браузер только ищет домен.

Спасибо, но в изменении кода с помощью патчей я вижу еще больше проблем, чем с vqmod: как уже писали выше, - патчем нельзя изменить файл, уже измененный другим патчем. Это не просто проблема, это огромная проблема, потому что ситуация, когда модуль устанавливается на голый движок достаточно редка, обычно на сайте установлено пару десятков модулей, а такие файлы как контроллер товара или категории меняются много раз. И конфликтов будет больше, чем в vqmod, потому что в vqmod конфликты будут только если 2 vqmod меняют один и тот же код, а если меняется разные куски кода то конфликта на будет, то в патчах будет конфликт если 2 пачта меняют 1 файл в любом месте, так как патч привязывается к конкретным строкам в файле, а не к коду. сложность использования. Если для vqmod нужно просто скопировать файл в нужную папку и в идеальном варианте все будет работать, то наложить патч пользователь с фтп доступом к сайту просто не сможет + для этого нужно знать дополнительные команды + для windows (а это 99% пользователей) нужно устанавливать доп. софт. А vqmod просто копируется файл и все работает.. сложность исправления конфликтов между 2 патчами. Если vqmod файл можно открыть и изменить его то сделать это с патчем будет почти невозможно так как патч создает программно с конкретными номерами строк, чексумой итд. Патчи это больше инструмент для программистов, который используется для каких-то единичных изменений, а не инструмент массового использования во всех модулях для обычных пользователей, это будет еще хуже, чем с vqmod. Простого ответа на вопрос "Как изменить файлы движка и избежать всех конфликтов?" НЕТУ. Если бы такое простое решение было, то оно бы уже наверное использовалось всеми движками. Но почему-то никто это не использует. Вместо этого все движки и фреймворки, с которыми я работал, развивают системы хуков и событий. Потому что это единственно правильное решение, потому что только с помощью такого решения можно решить проблему конфликтов. В Друпале, например, может быть установлено 50 модулей на сайте и все установятся без единого конфликта. Для примера в опенкарте можно установить аж 2 модуля и они уже не будут работать вместе. В опенкарте тоже появилась система Событий, она пока не очень развита, но это будущее опенкарта потому что этим путем также пошли все другие движки, а не путем vqmod или патчей. Если кто-то знает другие движки, где основным инструментом для изменения движка при создании модулей используется аналог vqmod или патчи - напишите. Подозреваю, что таких или нету вообще или это единичные и малопопулярные движки на начальной стадии своего развития.

Да, 10 тысяч это не много, если при 10 тысяч страницы генерируется 5 секунд то проблема или в хостинге, или возможно есть узкие места в коде, например какой-то очень неоптимизированный модуль (это можно проверить отключив модули по очереди) + уже советовали выше - установить модуль для ускорения, например мой BOOST способен увеличить скорость генерации страниц до 100 раз, а при очень тяжелых сайтах и до 1000 и даже больше. Но это относится к второй и последующим загрузкам страницы.

https://opencartforum.com/files/file/526-attribute-category/

Конечно, отключить проще всего, но ведь отключение это никак не решение конфликта. Да и не верю я в то, что проблемы с совместимости бывают "иногда", если изменений в сборке много и все через vqmod + в магазине пару десятков сторонних модулей с vqmod то проблемы будут не "иногда", а "довольно часто", возможно даже почти в каждом таком магазине. Это могу сказать по моему немалому опыту работы с опенкарт.

У меня есть идея, как решить этот спор. Вопрос к разработчикам модулей: как вы создаете новый модуль, если нужно сделать его с vqmod? 1. Сначала создаете vqmod файл и все изменения сразу вносите в этот файл без изменения кода движка. 2. Сначала изменяете код движка, а когда все готово и нормально работает, переносите изменения в vqmod. Я почти всегда (кроме мелких правок) использую п 2. Потому что создание vqmod файла занимает гораздо больше времени, чем правки кода движка, а в процессе разработки модуля очень часто приходится менять и код и логику и даже файлы, которые нужно менять. Поэтому намного быстрее получается, если сначала изменять код движка, а когда все полностью готово - результат перенести в vqmod. Если другие разработчики, как и я, предпочитают 2 вариант, то ответ на вопрос как вносить изменения в ocstore очевидный - так как в любом случае нужно изменять код движка то почему бы эти изменения не держать в git? После чего если есть желание, можно создать vqmod вариант правок. Дополнительных затрат времени тут не будет, потому что изменять код движка нужно будет в любом случае. Затраты будут для создания vqmod версии.

в которой как раз таки все изменения внесены в код, а не через vqmod :)))))

1. исправить конфликт - это не выключить, это сделать так, чтобы работало, разница между выключить с делать - огромная. 2. где в админке ocstore можно выключить vqmod? 1. если сделать 50 патчей, каждый из которых нужно отдельно устанавливать то это уже будет не сборка, а набор патчей. 2. для H1 нужно так же изменить базу данных, чего с помощью vqmod не сделаешь, нужно просить пользователей, вручную выполнить sql код, очень удобно, особенно для пользователей без квалификации. Все, спор закрываю, он бессмысленный, можно исписать еще 10 страниц и все равно все останутся при своем мнении.. Я поддерживаю предложение dinox - делать 2 версии - кому интересен vqmod - пусть делает все изменения в vqmod, кому vqmod не интерес - пусть делает версию с правками кода в самом движке.

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

ну так конфликты же будут в любом случае! это минус и одного и другого способа.

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

ну так я это предлагал выше - сделать отдельную ветку для markimax, в которой он перенесет все на vqmod :) А если серьезно, то идея неплохая, но только тянуть параллельно 2 ветки увеличит время разработки в разы.. сейчас и так новые версии ocstore выходят раз в год с огромным опозданием, а если будет 2 ветки то выходить будет раз в 2 года..

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

ну так если движок "перепилен вдоль и поперек" с помощью vqmod то проблем с ним будет в разы больше.

я также не понимаю в чем сложность для ocstore использовать git для сливания изменений с opencart. тогда бы новые версии ocstore выходили не через год, а через 2 дня после релиза оригинальной версии. git merge + исправить конфликты (если они будут) и новая версия ocstore готова. Понятно, делать это нужно регулярно, тогда конфликтов почти не будет, а не раз в год после тысячи коммитов. Зачем каждый раз вносить одни и те же изменения?

- сложность решения этих конфликтов - vqmod это неправильное решение, которого нету ни в одном другом движке, будущее за Событиями, а vqmod скорее всего уйдет с какой-то 3 версии opencart - vqmod не покрывает всего кода - например им невозможно заменить установочные файлы (а хочется же добавить логотип ocstore в установку, добить русский язык, поменять какой-то текст, внести изменения в таблицы базы данных итд.), css, js файлы. - намного солиднее выпустить отдельную сборку, а не кучу xml файлов, при установке которых на рабочие сайты появится куча конфликтов. - создание изменений через vqmod и отладка их занимает намного больше времени, чем изменение самих файлов - изменяя сами файлы можно использовать для работы git для например сливания изменений с оригинальной версии через обычный merge