Jump to content
Sign in to follow this  
dinox

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

Recommended Posts

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

А когда чуть ли не весь модуль полностью запихивают в xml (встречал неоднократно) - за это убивать надо ;)

Иногда нет выхода. Например, микроразметка. Надо модифицировать очень многие TPL-ки. XML -- 100 кило. Внутри файла почти 2000 строк. И что тут сделаешь?

 

Хотелось бы видеть новый ocstore полностью совместимым с оригинальными модулями ...и шаблонами от opencart....

Простой пример: весь рунет поголовно хочет Title/H1/Meta-keywords для всех страниц. Чтобы их вывести, надо в т.ч. и шаблоны страниц менять для вывода новых полей или переделки вывода старых. Все опенкарт-шаблоны, разумеется, эту кухню поломают, поскольку не знают о ней. И их в любом случае адаптировать надо. У @snastik в OCSHOP-е этого ещё больше и гораздо более заметно, чем в ocStore.

Как можно хотеть в таких условиях полной совместимости?

Не будет её. Можно и нужно к ней стремиться. Но тут - или стремиться сохранить совместимость и вносить как можно меньше изменений (и как можно больше - внешними модулями, хочешь ставишь, не хочешь - не ставишь), либо забить и делать фичастую и удобную сборку. Которая будет удобная, но со своим локальным рынком сбыта и перепилов.

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

Share this post


Link to post
Share on other sites

Патчи я и предлагаю для программистов. Проблему ocStore вижу в том, что здесь есть много хороших и грамотных решений, но пользоваться ими трудно. Как тем, кто пришёл с другим движком (нативным опенкартом) и не может от него взять и легко отказаться, а вынужден заниматься раскопками и догадками, так и команде - у которой весь опыт не накапливается в виде решений. И пофиг, в каком формате, если честно. Мне уютней сохранять наборы "diff + git-extract" (.diff и рядом папка со всеми изменёнными файлами) и работать с ними, кому-то нравится оформлять это в vQmod-ы, а в следующий раз распутывать в обратном направлении - пожалуйста. Ну и пусть себе лежат рядом.

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

Тогда и над сборками станет легче работать. А опыт - накапливать. А не массивно впрыскивать изменения щедро по всему коду сборки. А через полгода чесать репу: опа, а теперь же надо собрать и вычленить снова всё, что мы туда нафигачили... А ведь делать это снова и снова - скучно, нунафиг. Так и живёт сборка от одного энтузиаста, которому больше всех надо, до другого. От Yesvika до Toporchillo. Которые устают обсуждать и решают просто сделать. Но хватает на пару-другую итераций и перегорают, ясен пень. Потому что выгоду от своих вложений получают лишь косвенную.

sv2109 сказал(а) 24 Янв 2015 - 10:32 AM:

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

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

Share this post


Link to post
Share on other sites

MaxD сказал(а) 24 Янв 2015 - 12:43 PM:

Почему? Моды применяются четко по алфавиту названия. Если надо, чтобы мод применялся последним - в начале названия ставится "z". Если первым - черточку.

А в OC2? Там XML-ки в базу складываются. Но я подробно не вникал, другим сейчас занят. Для разработчиков есть возможность положить xml-ки в `system`, но это как вариант для отладки, чтобы не обновлять модификации при каждом изменении файла.

Про vQmod уже можно забывать.

Share this post


Link to post
Share on other sites

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

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

 

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

f34af1a4b1.jpg

 

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

Share this post


Link to post
Share on other sites

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-ом он натворил чудеса и шаблон не узнать).

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites

Предлагаю:

 

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

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

 

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

  • +1 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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 в скайпе через день.

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

  • +1 1

Share this post


Link to post
Share on other sites

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

  • Similar Content

    • By IronMann
      Объявляется тендер на проведение разовых работ по адаптации OcStore 2.0
      под действующие процессы работающего интернет-магазина.
      Весь учёт и трассировка заказов ведётся в 1С, на сайт под управлением OcStore будет возложена только функция набора корзины и оформления заказа.
      В этом отношении, существующий алгоритм работы OcStore 2.0 для действующего порядка работы перегружен лишними не нужными шагами.
      Что хотелось бы видеть в переработанном варианте, после набора товаров в корзину:
      Шаг 1. Вывод публичного соглашения на экран, подтверждение и продолжение работы.
      Шаг 2. Ввод данных покупателя. ФИО, индекс, адрес, контактный телефон получателя и емейл получателя. (Все поля обязательны к заполнению).
      Шаг 3. Вывод содержимого заказа и адресных данных. Подтверждение заказа.
      Как видно, схема оформления заказа предельно упрощена по сравнению с дефолтной. Убраны в частности блоки Новый/старый покупатель (вообще не нужно), Платёжная информация (плательщик и получатель считается одним и тем же лицом), Способ доставки и Способ оплаты (это согласует оператор обрабатывающий заказ в 1С и связывающийся с клиентом). Основной упор делается на корректном заполнении данных покупателя.
      Ещё потребуется аккуратно заполнить в самой базе данных OcStore некоторыми автоматизированным дефолтными значениями те поля, которые присутствуют в убранных блоках, чтобы не было разных возможных конфликтов на уровне данных.
      Пожелания к конечному результату, помимо собственно работающего функционала, будут такими: сохранить исходники модифицированных файлов, в модифицированных файлах убираемые или изменяемые блоки кода комментировать, т.к. с этим ещё возможно придётся работать и дальше.
      С предложениями выполнить указанную работу, сроками и финансовыми пожеланиями - в личку.
  • Recently Browsing   0 members

    No registered users viewing this page.

×

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.