Процесс работ над релизом ocStore 1.5.5.1.2

[freelancer]

не надо глупых советов давать, для версии 1.5.5.1 это уже не актуально, там нет "product/manufacturer/product"

 

да и кончайте флудить, это обсуждение нового релиза

[sega135]

В  Релизе ocStore v1.5.5.1.1 перешел на SEO ЧПУ. Все работает кроме производителей. Заходим в меню производителей - выдается список производителей - щелкаем на любой и  выдается сообщение - Запрашиваемая страница не найдена! В производителях оригинальные seo прописаны, на эти страницы и ссылаются ссылки (сайт/производитель)  В чем проблема.?? Как можно решить эту проблему???

Проблема оказалась в покупном шаблоне  "Shop Universal" для ocstore 1.5.5.1.1. Видимо заменил оригинальные файлы.Благодарю за помощь в выявлении ошибки.Буду разбираться с автором шаблона.

[Redje]

Возможно ошибка.

В файле russian.php мастер версии в стоке 9

$_['thousand_point']        = ' ';

вместо

$_['thousand_point']        = ',';

Из за чего может, например, неправильно рассчитываться размер (%) скидки на акционный товар.

[nizulko]

Ребят, свежую русскую версию с исправлениями откуда можно взять? Или релиз намечается в ближайшие деньки? Не?...

[vertus]

Судя по первому посту, остались только два пункта по SEO. Как можно скачать сборку в текущем состоянии? Или есть ещё другие вопросы?

[Alexey]

Судя по первому посту, остались только два пункта по SEO. Как можно скачать сборку в текущем состоянии? Или есть ещё другие вопросы?

https://opencartforum.com/topic/27002-процесс-работ-над-релизом-ocstore-15512/?do=findComment&comment=232489

[costas]

При добавлении Сопутствующих товаров - если добавить самого себя (товар) то товар будет сам себя отображать в Сопутствующих, не логично.

 

в catalog/model/catalog/product.php это нужно поменять

$product_data[$result['related_id']] = $this->getProduct($result['related_id']);

на это

if( $product_id != $result['related_id'] )$product_data[$result['related_id']] = $this->getProduct($result['related_id']);

[MDS]

Cборка Ocstore-master, несколькими страницами ранее.

1. В свойствах категории на вкладке данные, категорию можно назначить родительской для самой себя.

При этом из списка категорий в админке пропадает сама категория и все подкатегории ей принадлежащие.

Вернуть можно только правкой БД.

2. Оранжевая рамка вокруг основного изображения товара, которая появляется после увеличенного просмотра.

[smind]

посмотрите плиз пулл реквест https://github.com/ocStore/ocStore/pull/10

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

[smind]

у меня в проекте это делается так

 

template/product/category.tpl

     78       <div class="options">
     79       <?php if ($product['options']) { ?>
     80         <?php $toppos = 0; ?>
     81         <?php foreach ($product['options'] as $option) { ?>
     82           <?php foreach ($option['option_value'] as $option_value) { ?>
     83             <?php $toppos += 20; ?>
     84             <div class="option" style="top:<?php echo $toppos ?>px">
     85               <?php echo $option_value['name']; ?>
     86             </div>
     87           <?php } ?>
     88         <?php } ?>
     89       <?php } ?>

пользователь видит вот такое представление

[chukcha]

Но это добавит лишний запрос...

И не всем это надо.

[smind]

Но это добавит лишний запрос...

И не всем это надо.

там накладные расходы минимальны...

[andry]

посмотрите плиз пулл реквест https://github.com/ocStore/ocStore/pull/10

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

нужное дополнение, желательно вообще расширить функционал опций в опенкарте.

[smind]

нужное дополнение, желательно вообще расширить функционал опций в опенкарте.

тикет закрыт - НЕНУЖНО :)

[Tom]

тикет закрыт - НЕНУЖНО :)

Может сделать VQmod ? И это точно кому то нужно.

[rb2]

smind сказал(а) 11 Янв 2014 - 1:46 PM:

тикет закрыт - НЕНУЖНО :)

Надо понимать, что проект (форк основного) может развиваться в двух направлениях:

- вовсю наполняться фичами и допилами;

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

Первый вариант из-за структуры Опенкарта (нет толковой поддержки модулей-расширений, все расширения - это патчи исходного кода) и тактики его развития (никакая совместимость или стабильность между версиями не гарантируется) грозит большими затратами времени. Даже когда разработчиков с энтузиазмом здесь было гораздо больше (порядка десятка человек), мержем с 2011 по факту занимался только Yesvik, насколько я видел. И мерж в этих условиях - кропотливый процесс, причём желательно помнить и хорошо представлять, где у нас были правки. Пусть даже не хорошо, а хотя бы приблизительно. Потому что одна фича размазана по коду Опенкарт так, что хрен соберёшь. Собрать так в сборке 50-100 всяких хороших и нужных фиксов и дополнений - и трындец.

Итого: Затраты времени на поддержку "фичастого дистрибутива" - большие.

Отдача от этих усилий - очень сильно косвенная. Не чувствуется.

Поскольку в рунет сообществе расклад примерно как несколько тысяч людей-"дай" и человек 5-10 способных делиться контрибуторов, в окрестностях выхода релиза оригинального Опенкарт несколько тысяч начинают активно ждать, несколько сотен -- тяжело дышать в затылок, а несколько самых бодрых - бегать, пинать и напоминать, что вот же уже -- давайте, пора уже, все ждут, чо вы там. Пяток тех, кто осиляторы и до этого пытался - постепенно всё дольше задумываются: "и на кой хрен оно мне надо?" И в результате перегорают поддерживать непонятно кого, а окукливаются и поддерживают понятно кого - свои интересы и своих заказчиков. Занимаясь вполне конкретными делами и задачами. Когда могут - подбрасывают что-то в общий доступ из того, что самому нужно было.

Итого: поэтому разработчики из разряда самаритян перегорают, а расходятся по своим кузницам.

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

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

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

Различия к минимуму свели, но к тому времени контрибуторов-энтузиатов уже не осталось.

Да и версии в основном репо пошли какие-то сомнительные.

Цена добавления и поддержки новых фич очень высокая получается, в общем.

Тем более таких, которые нужны далеко не всем.

Так что чего тут удивляться? Я бы тоже отклонил. Такое лучше модулем делать, а не включать в сборку. Если включать - то не в форк, а в оригинал.

[freelancer]

могу поянить ситуация, т.к. я отклонил с комментом

лишние тормоза

 

часто сталивался со случаем когда только model->getProduct() занимало большую часть всего времени, getProductOptions добавить ещё больше тормозов, (проведите тесты на сколько-нибудь серьзной базе)

при этом в большинстве случаев опции там не нужны.

 

но можете оформить как отдельный модуль/vqmod

[markimax]

могу поянить ситуация, т.к. я отклонил с комментом

 

часто сталивался со случаем когда только model->getProduct() занимало большую часть всего времени, getProductOptions добавить ещё больше тормозов, (проведите тесты на сколько-нибудь серьзной базе)

при этом в большинстве случаев опции там не нужны.

 

но можете оформить как отдельный модуль/vqmod

https://opencartforum.com/topic/30184-ocstore-%D1%82%D0%BE%D1%80%D0%BC%D0%BE%D0%B7%D0%B8%D1%82-%D0%BF%D1%80%D0%B8-%D0%B2%D1%8B%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%BD%D0%BE%D0%BC-%D0%BF%D0%BE%D0%B4%D1%81%D1%87%D0%B5%D1%82%D0%B5-%D1%82%D0%BE%D0%B2%D0%B0%D1%80%D0%BE%D0%B2/

 

И я считаю нельзя использовать в модели catalog/product - getProducts

SELECT SQL_CALC_FOUND_ROWS

можно прозевать и наступить  на грабли при большом количестве товаров

[freelancer]

так что ты предлагаешь?

[mobitoria]

так что ты предлагаешь?

Мне кажется кеширование с длительным временем жизни - нормальный выход, а если в моделях админки при добавлении/удалении товара сделать принудительное обновление кеша, вообще хорошо будет. Или кнопкой отдельной вывести в админке "обновить товарный кеш", что бы после импорта можно было принудить обновиться.

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

[freelancer]

интересует конкретный ответ в виде кода.

[smind]

я дико извиняюсь, но выбор картинок не должен работать во встроенном ФМ?

[Alexey]

 

При добавлении Сопутствующих товаров - если добавить самого себя (товар) то товар будет сам себя отображать в Сопутствующих, не логично.

 

в catalog/model/catalog/product.php это нужно поменять

$product_data[$result['related_id']] = $this->getProduct($result['related_id']);

на это

if( $product_id != $result['related_id'] )$product_data[$result['related_id']] = $this->getProduct($result['related_id']);

Это плохое решение, скрывать вывод неправильных данных

 

Хорошее решение, не позволять создавать неправильные данные.

То есть, не разрешать добавлять в сопутсвующие товары - самого себя (товар).

[chukcha]

То есть, не разрешать добавлять в сопутсвующие товары - самого себя (товар).

 

 

Это нужно делать еще в админке

[costas]

Это нужно делать еще в админке

Такая правка коснётся jquery кода который отправляет запрос для авто дополнения, и серверную часть которая отвечает списком товаров.

 

 

Надо понимать, что проект (форк основного) может развиваться в двух направлениях:

- вовсю наполняться фичами и допилами;

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

 

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

 

Идеальный вариант - это тот который ещё не написан (с)

Змінено 20 січня 2014 користувачем costas