rb2

Я так понимаю, при редактировании товара на вкладку "бонусные баллы" вы не заглядывали.

Таки да, теперь вижу. И Jay Gilford там же в extarnal links светится. Спасибо за пояснение. Но всё равно: а давайте Override Engine (JNeuhoff) почаще использовать! :) Он и vqmod интегрирует-поддерживает (для модификаций tpl что ещё использовать?), и правильные вещи допиливает.

А кто заставляет? Поддерживайте Override Engine или SafePatch. В наших силах писать модули под правильные решения и продвигать именно их использование в своих модулях, а не vQmod/ocmod. А вокруг чего там Даниэль пляшет с бубном - ну не пофиг ли? Чем больше у него и Опенкарта будет косяков, тем больше простора для разных модулей и улучшений.

В старом репо информация про 2.5.0 есть, а о переезде на гитхаб - ни слова. На гитхабе, похоже, один контрибутор (постящий релизы), и это Jay6390, а не Qphoria (автор vQmod). Какой-то чудесатый переезд.

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

Я вообще-то сомневаюсь, что и реализация задуманного увеличит продажи. Когда я сам покупаю несколько наименований - нет абсолютно никакого желания продолжать шоппинг после того, как всё уже оплатил и десять раз приценился и выбрал более подходящий вариант из нескольких. Даже если мне на этом этапе (после успешного оформления или оплаты) покажут что-то из похожих или связанных товаров - очень мало шансов, что они меня заинтересуют. Потому что я обычно уже эти связанные товары пересмотрел и наизучался в процессе набора корзины, а потом её пересмотра и возможной очистки от чего-то. То есть меня эти связанные товары, которые подсовываются в процессе покупки, очень привлекают - и я их изучаю, кладу в корзину, чтобы потом выбрать вариант получше. А после оплаты меня такой же список ну аж никак не привлекает. Он ведь никуда не девается на сайтах с большим ассортиментом дешёвых товаров (liexpress, dealextreme, amazon. ebay и т.п.) - а именно на россыпи дешёвых товаров это могло бы срабоать (теоретически). Потому что на сайтах с более дорогими товарами (футболки, платье, одежда например) - уже сложнее представить, что кто-то хлопнет себя по лбу "ах куда же я поспешил" и начнёт заново ещё один заказ дозаказывать. Так что мне кажется, что на конверсии это никак не скажется. Ну будет чуть удобней. Но момент не тот. Мало людей, думаю, будут второй заказ делать. Тут бы чем-то их заманивать - то ли большой скидкой (на эти товары или на следующий заказ), то ли ещё чем. В общем, стимул нужен приличный, чтобы второй заказ тут же начать собирать.

Я думаю, это непонимание пройдёт после реального живого обслуживания нескольких продающихся и развивающихся модулей. Попробуй. И через пару месяцев или полгода вернёмся к обсуждению. Потому что цель - именно получение этих разниц. Которые и рассылаются в обновлениях клиентам. В моей практике многие хотели именно список изменений, а не обновлённый модуль полностью. Синхронизация двух репозиториев целью не является. В моём случае по крайней мере. И никаких дополнительных бонусов мне не приносит.

Вовсе нет. Это легко лечится .htaccess-ом в папке исходников фото. Я и в репо ocStore кажется это когда-то очень давно коммитил.https://opencartforum.com/topic/6503-kak-skryt-originalnye-kartinki/?do=findComment&comment=40920

Вручную. Где искать - написано в предыдущем сообщении. Вкладки транзакций и бонусов там рядом находятся.

В опенкарт для этого предназначен механизм кредита пользователю от магазина (доступно через Продажи / Покупатели / Покупатели / Изменить / вкладка Транзакции). Делает ровно то, что описано, скидка действует сразу на весь заказ. Поэтому можно конвертировать баллы пользователя в кредит магазина, а механизм баллов не трогать. Может это устроит. А баллы действительно предназначены для того, чтобы можно было продавать товар как за живые деньги, так и за бонусы. Реализуя таким способом другие механизмы привязывания и увеличения лояльности.

Отвечу ещё раз конкретно на этот вопрос: я обычно делаю 2 команды git log -p HEAD^.. > issue1234-fix-header-info.diffи git-extract HEAD^.. && mv .deployment issue1234-fix-header-info.CHANGED-FILESВсё. И переносится один-два коммита в другой репо легко и просто. То ли через `git apply issue1234.diff`, то ли копированием файлов поверх и фиксацией коммита (в истории команд найти и нажать энтер). Если файлы модуля слинкованы из репо ocs1551 в репо модуля, то в репо с полной копией идёт чисто правка файлов (отладка) и тестирование в броузере, а коммиты делаются только в репо с файлами модуля. То есть в репо с копией движка - отпочковали ветку, скопировали модуль, исправили, пофиксили, проверили. Всё работает? Перешли в репо модуля и закоммитили изменения, т.к. все файлы изменялись здесь, а там только симлинки и рабочая копия, которую можно и нужно безболезненно грохнуть по окончании работы. Либо же упоминавшийся неопробованный на практике вариант с `git format-patch ...` и переносом изменений через один или несколько .patch файлов. Вариант связывания репозиториев мне кажется слишком избыточным. Если даже там удастся сделать более громоздкий вариант с автоматической синхронизацией (в чём я сомневаюсь), то затруднится сопутствующая задача документирования изменений в модуле.

Я не вижу смысла через добавление репозитория и пушы-пуллы делать это всё. Мне, честно говоря, не верится, что пуш из репо с десятком файлов в репозиторий с полной копией движка (и эти репо никак не связаны между собой) пройдёт безболезненно. Да и смысла не вижу городить огород. Поясню. Самые важные - это задачи установки, затем отладки / разработки модуля. Иметь модуль в виде, допускающим быстрое разворачивание - очень полезно. Всё ранее описанное прекрасно эту задачу решает. Модуль хранится и распространяется в двух видах: "файлы модуля без перезаписи + vQmod XML" - для обычных пользователей, и "копия всех изменённых файлов + diff" - для разработчиков и тех, кому надо внести изменения в сильно изменённый движок. * Накатить модуль на любой движок/версию в целях проверки установки пользователем? Задача легко решается. * Накатить модуль на движок в целях доработки? `git branch` в настроенном движке нужной нам версии, копирование и установка модуля, доработки. Обычно здесь присутствует 1-2 коммита. Их можно перенести в родной репозиторий модуля хоть вручную (извлекли разницу в виде изменённых файлов или взяли дифф последних 1-2 коммитов, накатили в репо модуля, сделали коммит "fix #123 подробное описание чего фиксили"), хоть через `git-format-patch` (получаем набор {1,2,3}.patch и храним их в репо модуля) В общем-то всё. Все задачи разработки и дистрибуции модуля решаются. Фиксы и новые фичи переносить из репо `ocs1551` в репо `opencart-sv2109-megasuperpuper` нетрудно. Заодно с этим переносом логично решается задача оформления описания изменений в ридми. Может он и автоматом сгенерится из истории коммитов, а может и вручную куда допишется (в ридми, в описание на площадках, где модуль выставлен). И в этом поможет эта вот тарнзакция из вручную переносимого diff + изменившиеся файлы (или пачка из нескольких .patch файлов, копирующих коммиты). То есть одновременно этот перенос помогает задаче документирования изменений. Ведь там надо: - задокументировать изменения в модуле для себя - описать изменения в CHANGELOG для пользователей - разослать обновление или уведомление об изменениях - если речь идёт о критичных или сложных модулях (там, где требуется адаптация под нестандартную тему оформления), то фиксы лучше рассылать не в виде готового модуля для установки с нуля, а в виде "добавлено то-то, исправлено то-то". И в виде списков изменённых файлов только для этого багфикса или фичи. Потому что на живой магазин, сильно переделанный, не всегда хочется все обновления ставить. И распространение модуля не в виде кумулятивного образа, а в виде набора истории изменений -- тоже полезная форма. Затронутая ещё одна тема, распространения и описания модуля, тоже заслуживает отдельного внимания. Можно и об этом поговорить.

kourysan, да всё нормально написано. Есть купленные товары. На странице после успешного оформления заказа человек хочет вывести содержимое вкладок рекомендуемых/связанных товаров, которые были в коризне. Может он передумает и докупит ещё что-то забытое. Топикстартеру: готовых идей у меня нет. Возможно, есть смысл смотреть в сторону модулей "вы недавно просматривали такие-то товары". Может на их основе проще будет реализовать.

@sv2109, у меня всё, как в первом сообщении. В репо с модулем ветки -- по версиям. В этом репо хранятся только файлы модуля и обслуживающие скрипты, наборы конфигов, доки/вики и т.п. Без движка. В репах для работы-отладки устанавливаются движки определённой версии. В мастере - чистая сборка. В ветках - отдельные модули. Больной вопрос - как разрабатывать и фиксить модуль в одном репо (с дистрибутивом), а изменения коммитить-документировать в репо модуля. Пока не знаю хорошего решения. Но подумываю о том, чтобы просто сделать в модуле скрипт "установки" в папку с дистром, который будет делать симлинки на все файлы модуля. В случае с русским переводом такой подход зарекомендовал себя идеально. Но там всего два симлинка надо сделать. В репо с переводом переключаемся на соотв. версию, в нужном живом репо получаем нужную версию перевода. Из мелких недостатков - работать можно с переводом одной версии (движок с другой версией смотрит туда же) и надо не забывать переключаться. Ну, это вопрос дисциплины - можно себе какие-то чеклисты понаписать. В случае с другими модулями может будет сложнее, но вряд ли намного. Сохранить вывод `tree`, дописать там к полным путям `ln ...`, и скрипт готов. Мне кажется, это довольно удобно будет работать. Но ещё не пробовал. Ещё к первому сообщению хочу добавить, что мелькала мысль (пока не пробовал) хранить все изменения в виде патчей (один коммит = один патч), чтобы можно было восстанавливать историю коммитов на другом репо, доделывать что-то, затем опять получать разницу и сохранять её. Или после доделок дописывать несколько патчей в папку модуля. В общем, что-то вроде механизма миграций в фремворках. В модуле обязательно сохраняю пары diff + папка со всеми изменёнными модулями. Это уже давно повелось. Разницу сохраняю готовым скриптом - см. http://rb.labtodo.com/page/kak-oblegchit-process-publikacii-izmenenij-na-server (первый раздел, про `git-extract`)

То, что есть в ocStore, задумывалось для продажи цифровых товаров. Поэтому там скачивание доступно только зарегистрированным пользователям и после покупки. * Каталог - Файлы для скачивания * редактирование товара - вкладка Связи - Загрузки. Присоединяете ранее созданные файлы для скачивания. * Посетитель покупает этот товар. Обязан зарегистрироваться - если в корзине есть хоть один цифровой товар, опенкарт будет вынуждать зарегистрироваться. * После покупки файлы доступны для скачивания на страницах акаунта покупателя.

Недостатки - невозможность добраться до футера (пока все товары не закончатся) и неиндексируемость поисковиками. Но если поисковикам скармливается полный `sitemap.xml`, то оно и не надо.

Используйте `if( $this->customer->isLogged() )` Ели все товары одинаковые (для всех действует одно правило упак/кв.м.) - выводите через языковые переменные. Если язык один и всегда будет один - можно и напрямую в шаблоне. Если же у разных товаров возможны разные ситуации с единицами измерения - у каждого товара есть готовые поля, которые очень редко используются на практике в наших реалиях (UPC, EAN и т.п., ISBN например, если книгами не торгуете). Можно их переименовать и у админа будет готовый интерфейс для вписывания туда своих значений единиц измерения для каждого товара. Если поле заполнено - выводите их. Не заполнено - действия по умолчанию (упак/кв.м.)

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

Я ни одного такого не видел. Мы вообще о версиях 1.5.x говорим? По-моему, в 1.4.x это было немного по-другому организовано.

Google: opencart series Google: серии товаров opencart или серии товаров site:opencartforum.com Полно вариантов, разбирайтесь. Гуглом вроде нетрудно пользоваться.

Судя по внутренностям - это не опенкарт. То, что по адресу `/admin/` открывается админка опенкарта, не является доказательством. А по поводу "перекрутиили" -- не вижу, о чём вообще речь. Стандартная структура, никаких перекручиваний не надо. Переверстать страницу (вместо табов - вертикальная простыня), и всё. Длинный список других товаров - либо "похожие товары", либо какими-то из модулей серий товаров.

В новой схеме путь не трогаете, такой же, как в категориях (product/category). Не надо там никакие идентификаторы прописывать. Назовите эту схему как-то понятно, например "Категория - одежда". На общую схему категорий вешаете один модуль (фильтр). На вашу новую схему "Категория - одежда" вешаете оба модуля. В нужных категориях заходите в редактирование и на вкладке "Дизайн" выбираете вместо обычной схемы "Категория" свою альтернативную "Категория - одежда".

Ваш сервер сейчас настроен так, что будет отдавать файл с именем `sitemap.xml`. Вам его надо вручную обновлять и класть туда. Сам он обновляться не будет при внесении изменений в магазин через админку.

У них там по-прежнему в шаблоне дублируются tpl-ки способов оплаты?

Зачем?