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

[sv2109]

Но нужен механизм "магнитофона". Чтобы накопленные атомарные изменения были локализуемы и их можно было воспроизвести при работе над следующей версией сборки. Заходим в репо патчей предпоследней версии, делаем ветку для новой, берём по очереди, применяем. Есть конфликты - лечим. Будет там 50-100 папочек с патчами и разными вариантами исполнения - и замечательно.

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

 

Эта система пока неспособна решить проблему модификации шаблонов. Тут кроме OCMOD других вариантов пока нет.

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

2. Менять шаблон через vqmod не самая лучшая идея, так как шаблоны то все разные, при чем есть очень нестандартные.

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

[Baco]

OCMOD чуть совершенней и немного пафосней, чем скромный vQmod и работает по тому же принципу:

$modification[$key] = preg_replace($search, $replace, $modification[$key], $limit);

записывает начинку файлов в базу + автолоадером (spl_autoload_register) всё экранируется через modification в стартапе, фактически по принципу (как раньше было в индексном файле) vQmod-а:

 

А теперь вопрос: "Сильно ли отличается быстродействие, от того, что было при vQmod-е ? Или просто сменили шило на мыло, поменяв просто версию при этом ?"

[rb2]

sv2109 сказал(а) 24 Янв 2015 - 4:01 PM:

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

Попробуй.

Я тоже такой умный был - погугли мои посты здесь за 2011 год. Там чуть ли не слово в слово будет то же самое.

Я такое пробовал и при работе с языками, и свою модификацию с удобствами держать рядом в соседней ветке или соседнем репо. Итог? Я устал ежедневно по 10-50 конфликтов разрешать. У DK&Co нет ни какого-либо плана-роадмапа, ни культуры ведения совместной или публичной разработке, ни хорошего знания инструмента (гита). С их репо тяжело работать с удовольствием.

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

В теории оно всё хорошо должно работать. Но практика вносит существенные коррективы.

Это не значит, что прям совсем нельзя и всё настолько плохо. Это как раз то направление, куда стоит стремиться. Просто при таком подходе маты в сторону DK будут нестись ежедневно, а не раз в полгода. Я проверял.

sv2109 сказал(а) 24 Янв 2015 - 4:01 PM:

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

Ок, заменили, подменили модифицировали. Модифицировали ДАННЫЕ. Некоторые из которых вопреки заветам - уже не просто данные, а с оформлением. Это решает часть проблемы. Причём мне кажется, что малую.

Не решает проблему, когда что-то добавить надо в шаблон.

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

sv2109 сказал(а) 24 Янв 2015 - 4:01 PM:

2. Менять шаблон через vqmod не самая лучшая идея, так как шаблоны то все разные, при чем есть очень нестандартные.

Спасибо, кэп. Но есть такое слово "надо".

И вручную вносить правки - это только один из вариантов. Навязывать который конечному пользователю как единственный - не самая хорошая идея. Может у него как раз default шаблон или минимально отличающийся по структуре (а CSS-ом он натворил чудеса и шаблон не узнать).

[rb2]

Baco сказал(а) 24 Янв 2015 - 6:56 PM:

А теперь вопрос: "Сильно ли отличается быстродействие, от того, что было при vQmod-е ? Или просто сменили шило на мыло, поменяв просто версию при этом ?"

А при чём тут быстродействие? DK никогда это не заботило - он, например, и про индексы в базе с пренебрежением отзывался, и долгое время публично тупил и обзывал умных людей идиотами, когда ему про составные индексы рассказывали.

Да и сменили не только шило на мыло, а синтаксис. И если бы не упёртость некоторых очень уважаемых разработчиков - OCMOD ещё долго оставался бы "vQmod-ом для бедных", как его прозвали поначалу. Но сейчас вполне терпимо.

[sv2109]

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

Как вариант, больше использовать массивы и в шаблоне выводить все через foreach. Тогда в любой массив мы легко можем добавить новые элементы.

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

Это пример но суть думаю понятна. То же самое можно сделать с другими элементами на странице, например с полями товара. 

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

[tabook]

Изменить что-то без модификации шаблона невозможно. А вот если бы все табы были в массиве...

Возможно и на лету (читай, на клиенте), без модификации шаблона, используя jquery. Другое дело, что универсальности не получится все равно. Нужно точно знать, что за движок. Вот, к примеру в 2.0 каждая закладка в шапке уже обрамляется как <li>, в 1.5.x - просто список <a>. Добавим сюда любую сильно переработанную тему и все, приплыли.

В массиве - это отличная идея и 100% масштабируемая.

[rb2]

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

Конечно, можно кучу улучшений внести в движок. Десятки узких и кривых мест давно известны. Но тут дилемма - надо или уговорить DK их принять и включить в апстрим, либо забить на кучу пожеланий с "+1" на первой странице этого топика.

Переделать предложенным способом вывод шаблона и говорить после этого о надеждах на совместимость с шаблонами и модулями от опенкарт никто же наверное не будет?

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

Это в том варианте, о котором я говорил. Построение страницы товара (например) из множества отдельных модулей (таких, как переключатели валют и языков).

[JohnnyVega]

Предлагаю:

 

1) Выкладывать OcStore сразу с измененнёми файлами. Т.е., также как и сейчас. Этот вариант подходит для тех, кто делает магазин с нуля.

2) Разницу между OcStore и Opencart (SEoPro, H1/Tittle и т.д) выкладывать в виде отдельных модулей/дополнений/инструкций. Этот вариант подходит для тех, у кого уже есть существующий магазин на Opencart и кто хочет сделать из него частично или полностью OcStore

 

Особого смысла нет именно с текущей версии Opencart делать OcStore, достаточно локализации. Текущие версии Opencart'а ещё сырые и будут полгода/год допиливаться и доделываться.

[mitulka]

А есть хоть какие-то приблизительные сроки выхода Ocstore 2?

[fes53]

А есть хоть какие-то приблизительные сроки выхода Ocstore 2?

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

[markimax]

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

 

Честно сказать - я как раз занимаюсь адаптированием своего модуля (а он очень большой и много что использует от opencart, поэтому все подводные камни я уже увидел) под OC 2 - он (opencart 2.0) оооочень сырой, даже скажу так - 3.14

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

Если квалификации "не очень" советую пока обходить стороной версию 2

[fes53]

Спасибо за совет. Значит не стоит ждать...

[markimax]

Спасибо за совет. Значит не стоит ждать...

 

Ну почему же - уже есть сборки русскоязычные от snastik, а по ocStore еще даже пока и стратегию не выработали как делать сборку

[rb2]

fes53 сказал(а) 28 Янв 2015 - 6:14 PM:

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

Да хоть сейчас.

SeoPro для OC2 (github) мы уже адаптировали и переделали, прекрасно работает (есть кеширование, мультиязык в URL и не помню что ещё).

Русский язык - я свою локализацию продаю по 2$, ну или есть несколько бесплатных. Или ждите. Или участвуйте. Мой перевод для OC2 давно уже, ещё с октября, доступен.

OCMOD для Сеопро выложили день-два назад, его я ещё не тестил - у меня на сайте стоит вручную поставленный. Мы обычно делаем и раздаём два архива - для ocmod и ручной установки (для разработчиков и тех, кто активно перепиливает свой магазин, набор изменённых файлов и возможность посмотреть в .diff удобней).

Snastik кажется говорил, что они тоже Seopro для второй версии адаптировали в OCSHOP.CMS.

Остальные мелочи вроде title/h1/meta-keywords и потом можно добавить. Хоть самостоятельно, хоть дождаться, когда другие впилят.

А главное, как Вы заметили - не париться через какое-то время с миграцией данных и исправлений.

От себя так скажу: oc2011 очень хорош по сравнению с 1.5.6.4 и вообще прилично от 1.5.x в лучшую сторону отличается по части многих исправлений. Ставьте и начинайте пользоваться. Ошибки есть, то там, то здесь - как и во всех версиях опенкарт. Некоторые критичные вещи мы уже пофиксили, я в блоге про некоторые писал (может не про все). Я активно пользуюсь oc2011 и очень доволен. Хоть и ругаем DK в скайпе через день.

[mitulka]

…  Я активно пользуюсь oc2011 и очень доволен. Хоть и ругаем DK в скайпе через день.

Спасибо! Буду думать.

П.С. было бы чем :)

[partizzzzzan]

Очень бы хотелось, чтобы в ОС2 наконец-то решили вопрос со страницей оформлением заказа - а то карусели со сторонними модулями надоели. Не пойму почему в оригинальной сборке этого до сих пор не сделали, т.к. судя по кол-ву модулей быстрого заказа и кол-ву их продаж, понимаешь, что не только русскоязычным пользователям не нравится реализация страницы оформления заказа.

[efremovxp]

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

То есть, переверстать тему без бутстрапа. Я все свои проекты делаю модификацией стандартной темы. А бутстрап это доброкачественная, но все же опухоль. Зачем сайту тащить лишний код бутстрапа и я не имею никакого желания разбираться в непонятных id и classах. Вроде, год назад это было модно, но сейчас такой стиль смотрится смешно.

Видимо, так и придется остаться на ветке 1.5.Х, пока не переверстаю :(

[markimax]

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

То есть, переверстать тему без бутстрапа. Я все свои проекты делаю модификацией стандартной темы. А бутстрап это доброкачественная, но все же опухоль. Зачем сайту тащить лишний код бутстрапа и я не имею никакого желания разбираться в непонятных id и classах. Вроде, год назад это было модно, но сейчас такой стиль смотрится смешно.

Видимо, так и придется остаться на ветке 1.5.Х, пока не переверстаю :(

Ну здрасте  :ugeek: 

А вы подумали о совместимости? ;)

[Otvet]

Зачем сайту тащить лишний код бутстрапа и я не имею никакого желания разбираться в непонятных id и classах. 

сидите на HTML 1.0, зачем лишний код, классы, скрипты .... :-D

[najmubadr]

Всем доброго времени суток! 

Сообщаю о начале работ над версией ocStore 2.0!

В теме пишите коментарии пожелания и предложения, в скором времени можно будет и pull реквесты отправлять

 

 А можно как-нибудь поучаствовать в этой работе в качестве дизайнера верстальщика? А то предыдущие версии в этом плане мягка говоря не радуют 

[ocdev_pro]

Хотелось бы видеть в сборке такие необходимые модули, как Обратная связь, Стикеры для товаров, Автоформирование URL, keywords главной страницы. Хотя бы как модули и отдельные модификации, что бы не затрагивать саму систему... Было бы здорово!

[markimax]

Хотелось бы видеть в сборке такие необходимые модули, как Обратная связь, Стикеры для товаров, Автоформирование URL, keywords главной страницы. Хотя бы как модули и отдельные модификации, что бы не затрагивать саму систему... Было бы здорово!

Ну могу предложить в сборку SEO CMS FREE, там только новости, статьи будут и один виджет

[ocdev_pro]

Ну могу предложить в сборку SEO CMS FREE, там только новости, статьи будут и один виджет

Желательно простое решение, Статьи с категориями 1 виджет с интерфейсом не отличающимся от OC 2.0 и без лишних надписей аля "сделано тем-то за инфой или полной версией туда-то"

[ocdev_pro]

Но думаю решение от OldAin можно допилить для разбивки по категориям и ничего выдумывать не надо

[Tom]

Честно говоря как по мне , так кроме Seo Pro никаких больше наворотов и не нужно вживлять.Не нужно  делать  отдельную сборку .Пусть уж лучше начиная с 2,0  различий станет ещё меньше.А всё остальное оформлять как дополнения.Потому как на вкус и цвет даже фломастеры разные  и то что нужно одним,даром не нужно другим.