Начало работ над версией ocStore 2.0

[klaos27]

 

ну так я это предлагал выше - сделать отдельную ветку для markimax, в которой он перенесет все на vqmod :)

Он же сказал

Тогда я в деле  :)

Некоторые стараются ветку его закрывать (в меру своих знаний и умений), чтобы у него больше времени было на добавление функционала в свой блогомонстр.

А уж для такого дела как ocstore 2.0 думаю markimax постарается :)  

[markimax]

 

ну так я это предлагал выше - сделать отдельную ветку для markimax, в которой он перенесет все на vqmod :)

 

Нет, как раз с точностью, до наоборот, вы в меньшинстве,  ветку персональную для sv2109 который перенесет vqmod кеш файлы вместо файлов opencart

[markimax]

Он же сказал

 

Некоторые стараются ветку его закрывать (в меру своих знаний и умений), чтобы у него больше времени было на добавление функционала в свой блогомонстр.

А уж для такого дела как ocstore 2.0 думаю markimax постарается :)  

Я и для OC 2.0 уже почти адаптировал SEO CMS PRO без vqmod (я его терпеть ненавижу)! Но для сборки другого выходя нет, с точки зрения архитектуры

[freelancer]

А вы думаете не будет конфликтов, когда будет напрямую код изменен!? Да, еще больше!

минус не-ocmod

- конфликты с другими не-ocmod/ocmod решениями

[markimax]

минус не-ocmod

- конфликты с другими не-ocmod/ocmod решениями

Вот, вот... sv2109 так и не понял, что если код изменить, то как раз пользовательские vqmod решения его могут и не "понять" и конфликтов будет больше, так как vqmod (к примеру который что-то делает) можно отключить, а вот код - нет.

ocmod однозначно, и без вариантов для сборки ocStore.

[sv2109]

А вы думаете не будет конфликтов, когда будет напрямую код изменен!? Да, еще больше!

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

 

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

Да и зачем этот разговор - хотите все делать через vqmod - делайте. Будет 2 ветки - одна без vqmod, вторую делайте с vqmod.  

 

[sv2109]

минус не-ocmod

- конфликты с другими не-ocmod/ocmod решениями

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

 

это минус и одного и другого способа.

[markimax]

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

 

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

Да и зачем этот разговор - хотите все делать через vqmod - делайте. Будет 2 ветки - одна без vqmod, вторую делайте с vqmod.  

 

 

Вы сами написали, что в конфликтах проблема. Исправление, это тоже самое.

Как вы не понимаете, если вы изменили код на прямую = файлу кеша ocmod

Т е наоборот исправить конфликт еще тяжелее, тем более пользователю без квалификации!

 

И не я хочу, а все хотят - вы не видите, что в меньшинстве. Ваши доводы просто "никакие"

[sv2109]

Вы сами написали, что в конфликтах проблема. Исправление, это тоже самое.

Как вы не понимаете, если вы изменили код на прямую = файлу кеша ocmod

Т е наоборот исправить конфликт еще тяжелее, тем более пользователю без квалификации!

 

И не я хочу, а все хотят - вы не видите, что в меньшинстве. Ваши доводы просто "никакие"

ну бред же.. 

где я писал что проблема в конфликтах? Даже 2 моих поста выше я пишу, что конфликты будут в любом случае, проблема в исправлении этих конфликтов.

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

[freelancer]

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

 

это минус и одного и другого способа.

да. оба решения с этим минусом.

[markimax]

ну бред же.. 

где я писал что проблема в конфликтах? Даже 2 моих поста выше я пишу, что конфликты будут в любом случае, проблема в исправлении этих конфликтов.

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

Да тяжелее, когда прямой код, в spyftnt по опыту половина пользователей вообще не пользуется даже ftp, а что такое править файлы, для них это высшая математика!!

А вот выключать vqmod файлы по опыту я знаю умеют почти 99% пользователей, потому что это прямо в админке ocStore

Проще выключить ocmod файл и посмотреть работает или нет и так методом перебора, чем править код.

К тому же можно написать для лично вас автопатчер :) Т е скомпилированные ocmode файлы кеша чтобы заменяли оригинальные файлы :)

 

Вы не поняли, я предлагаю делать ocmod патчи не в одном большом файле для ocStore а для каждой задачи свой! К примеру будет называться ocstore2_h1.xml и т.п.

[markimax]

да. оба решения с этим минусом.

Но oocmode преимущество большое - нет зависимости большой "запутанности".

Я предлагаю просто использовать ocmod только как хук доступа к данным контроллера и всё. Я в своем модуле - перехватываю всё и без vqmod

И кстати нет конфликтов не с одним vqmod файлом и не с одной сборкой на opencart!

[sv2109]

А вот выключать vqmod файлы по опыту я знаю умеют почти 99% пользователей, потому что это прямо в админке ocStore

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

2. где в админке ocstore можно выключить vqmod?

 

Вы не поняли, я предлагаю делать ocmod патчи не в одном большом файле для ocStore а для каждой задачи свой! К примеру будет называться ocstore2_h1.xml и т.п.

1. если сделать 50 патчей, каждый из которых нужно отдельно устанавливать то это уже будет не сборка, а набор патчей.

2. для H1 нужно так же изменить базу данных, чего с помощью vqmod не сделаешь, нужно просить пользователей, вручную выполнить sql код, очень удобно, особенно для пользователей без квалификации.

Все, спор закрываю, он бессмысленный, можно исписать еще 10 страниц и все равно все останутся при своем мнении..

Я поддерживаю предложение dinox - делать 2 версии - кому интересен vqmod - пусть делает все изменения в vqmod, кому vqmod не интерес - пусть делает версию с правками кода в самом движке. 

[markimax]

Все, спор закрываю, он бессмысленный, можно исписать еще 10 страниц и все равно все останутся при своем мнении..

Я поддерживаю предложение dinox - делать 2 версии - кому интересен vqmod - пусть делает все изменения в vqmod, кому vqmod не интерес - пусть делает версию с правками кода в самом движке. 

 

К версии без vqmod даже прикасаться не буду. Лучше уж буду тогда со снастиком пилить его сборку

[markimax]

Делать не ocmod версию - бездумная трата ресурсов.

 

Надо делать только ocmod и ... выпускать сборки уже на базе неё. Т.е. брать кеш файлы ocmod, заменять ядро и выпускать как ветку сборки. Вот что я предлагаю!

 

А вы sv2109 предлагаете делать отдельные ветки ... трудо-затратно и распыление ресурсов.

[sv2109]

К версии без vqmod даже прикасаться не буду. Лучше уж буду тогда со снастиком пилить его сборку

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

[markimax]

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

Повторю может вы не прочли или пропустили

Читаем внимательно

 

Делать не ocmod версию - бездумная трата ресурсов.

 

Надо делать только ocmod и ... выпускать сборки уже на базе неё. Т.е. брать кеш файлы ocmod, заменять ядро и выпускать как ветку сборки. Вот что я предлагаю!

 

А вы sv2109 предлагаете делать отдельные ветки ... трудо-затратно и распыление ресурсов.

 

[MaxD]

Привет всем. Кто еще не видел OpenShop - рекомендую посмотреть, как на концепцию.

 

Все изменения сделаны отдельными vQmodами (по смыслу), что дает возможность отключать ненужные или конфликтирующие части. Также это дает возможность отключить временно "сборку" полностью и посмотреть, как все работает на оригинальной версии движка.

 

Да, есть конечно запарки с совместимостью иногда, но они решаются отключением конфликтирующего vQmod из сборки - если он не очень критичен.

 

Главный плюс - возможность безопасно одеть OpenShop на уже работающий магазин. Это то, чего вы никогда не достигнете сборкой, в которой поменяны файлы.

 

Я не собираюсь делать OpenShop для OpenCart 2.0 - очень много работы, сейчас у меня другие приоритеты. Но могу с радостью поделиться кодом и опытом - а его у меня много.

 

Главное, на что я рекомендую обратить внимание - OpenCart 2 пока очень сырой, и обновления будут выходить часто. Вы запаритесь выпускать за ним новые версии сборки. Также вам ничего не мешает в какой-то момент "влить" изменения в код - если вы решите таки отказаться от vQmod.

 

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

 

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

 

Статические файлы (типа css) можно менять таким образом: в коде менять название файла на свой исправленный.

 

Что касается проблем с конфликтами, разработчикам надо будет писать модули, которые работают как с оригинальным OpenCart, там и новым ocStore. Тогда у них не будет возникать проблем при отключении этих модификаций.

[sv2109]

У меня есть идея, как решить этот спор.
 

Вопрос к разработчикам модулей: как вы создаете новый модуль, если нужно сделать его с vqmod?

1. Сначала создаете vqmod файл и все изменения сразу вносите в этот файл без изменения кода движка.

2. Сначала изменяете код движка, а когда все готово и нормально работает, переносите изменения в vqmod.

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

 

Если другие разработчики, как и я, предпочитают 2 вариант, то ответ на вопрос как вносить изменения в ocstore очевидный - так как в любом случае нужно изменять код движка то почему бы эти изменения не держать в git? После чего если есть желание, можно создать vqmod вариант правок.
Дополнительных затрат времени тут не будет, потому что изменять код движка нужно будет в любом случае. Затраты будут для создания vqmod версии. 

[chukcha]

п 2.

совмещенный с п.1

 

Чтобы внести изменения нужно посмотреть исходник

И... все зависит от сложности изменений.

[sv2109]

 

Да, есть конечно запарки с совместимостью иногда, но они решаются отключением конфликтирующего vQmod из сборки - если он не очень критичен.

 

Конечно, отключить проще всего, но ведь отключение это никак не решение конфликта.

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

[Otvet]

вопрос обывателя:

а инструмента который может показать пересечения xml патчей нет?

[snastik]

Прочитал все от корки до корки. Не вижу сути проблемы.

В формате ocstore 1.5 - не было критичных изменений, которые бы вносили дискомфорт при использовании модулей для чистого opencart.

Так что все изменения можно оставить в том же формате.

Самая большая проблема была с отсутствием ветки 1.5.6, в которой добавили Profiles и Reccuring, из-за чего были проблемы с установкой свежих шаблонов.

 

Если господин Марк реализует внедрением своей технологией реализацию seopro - в таком случае даже отпадет надобность править index.php

 

А сделать отдельный раздел в настройках админки тем же vqmod с одной большой кнопкой INSTALL TABLES, который будет устанавливать недостающие таблицы и добавлять поля - тоже не такая себе большая проблема, ну или же олдскульно  - в корне installocstore.php - как это реализовано у Usergio или у Progroman.

 

Как бы многим не хотелось, было лениво делать два варианта модулей для opencart ocstore, де-факто Даниэль уже все за всех решил. Любые попытки отойти от политики основной сборки будут вести к изобретению велосипеда.

 

Что касатеся проблем с vqmod и системы хуков. Vqmod какой бы он ни был костыль, но все же удобный костыль, так как позволяет менять логику подчеркиваю ВНУТРИ МЕТОДОВ. При том что любая система хуков позволяет это делать в формате _set _get. Т.е  вам нужно или полностью модменять метод, либо по результату переопределять и добавлять данные. Пока что я еще не видел ни одного хука, который позволял бы настолько гибко как и vqmod внедряться в формирование сложных запросов. Хуки же свяжут все по рукам и ногам. Мало того, использование хуков приведет однозначно к повышенной нагрузке на систему.

 

Также в том же WP, для того чтобы разобраться в логике плагинов, иногда нужно днем с огнем шерстить простыни кода.

 

 

вопрос обывателя:

а инструмента который может показать пересечения xml патчей нет?

 

В ситуации же с vqmod - есть vqmod manager - который очень наглядно показывает ошибки привязок.

Достаточно туда глянуть, пойти в vqmodcache слить нужный файл, и посмотреть XML инструкцию. Не вижу проблемы. Это намного проще чем разбираться в наслоении неявных инструкций множества дополнений, реализованных хуками.

 

Почему не стоит целиком и полностью, переходить на реализацию дополнений иcпользуя концепцию марка, тоже попробую объяснить.

Во первых формирование многих элементов DOM через ajax - не совсем правильный подход, так как некоторые элементы все таки желательно чтобы индексировались, а SimpleHtmlDom, по моему он еще не внедрил.

Во вторых дефакто 95% людей, которые используют дополнения, с трудом разобрались с моделью MVC и нынешней структурой модулей. Вводить, пусть миллион раз архитектурно правильные, но усложненные реализации - это плюнуть людям в лицо. Проще тогда уже не придумывать каких то собственных конструкций, а сделать OpencartDrupal, или OpencartYii.

 

Вся прелесть Opencart в простоте архитектуры. А любыми хуками можно из него сделать Абраказябру.

[Otvet]

мои 5 копеек:

1. создать wishlist  :lol:

2. записать туда уже озвученные h1, title,...

3. убрать уже наконец с корнями окончание breadcrumbs

4. от меня: возможность добавлять атрибуты не по одному а группой

 

про оптимизации и т.д. молчу  :ph34r:

[sv2109]

4. от меня: возможность добавлять атрибуты не по одному а группой

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