С помощью модуля "категорий", который я заливал несколькими сообщениями ранее. Возможно придется немножко подправить шаблон вывода категорий на главную, там же только метка картинок и ссылка на саму категорию, а так же вывод по 3 картинки в ряду. Допустимые метки гляньте в мануале вамшоп, а вывод необходимого количества картинок в ряд - это html и css.
Vam Shop
- Автор темы lash
- Дата начала
- Статус
svot
Постоялец
- Регистрация
- 6 Сен 2007
- Сообщения
- 70
- Реакции
- 1
к сожалению я незнаю как это делать
palec
Профессор
- Регистрация
- 6 Дек 2006
- Сообщения
- 282
- Реакции
- 49
Как же утомило обтёсывать этот магазин напильником! Начиная с Oscommerce, продолжая Oscommerce Vam Edition, ну и заканчивая Vamshop...
Как только будет время на передышку - буду переходить на какой-нибудь другой движок.
Вот, последние сюрпризы (Vamshop v.1.68)
В магазине 2 валюты: для примера, пусть будут RUR и EUR. Курс 1 к 1,5 (1 RUR= 1.5 EUR). Основная - RUR.
Покупатель делает заказ на 10 EUR. В админке, на закладке ТОВАРЫ/ДОСТАВКА видим следующее:
СТОИМОСТЬ ТОВАРА: 10 EUR
ВСЕГО: 10 EUR
В этот момент, в базу данных, в таблицу `orders_total`, в поля `txt` и `value` попадают значения:
`txt` = "10 EUR"
`value` = "10.0000"
При редактировании этого заказа, на закладке ОПЛАТА, в разделе ВАЛЮТА, не дай бог поменять валюту на другую, с курсом, отличным от один к одному... В данном случае, меняя валюту на RUR, происходит авто-перерасчет стоимости заказа.
В итоге, после перерасчета, на закладке ТОВАРЫ/ДОСТАВКА видим следующее:
СТОИМОСТЬ ТОВАРА: 10 RUR
ВСЕГО: 10 RUR
В таблице `orders_total`, в поля `txt` и `value` теперь значения:
`txt` = "10 RUR"
`value` = "10.0000"
Т.е суммы не пересчитались, а код валюты поменялся!!! У кого-то будет убыток, кратный разнице курсов валют!!!
Если после этого, вернуть валюту заказа обратно в EUR, то получим волшебное:
СТОИМОСТЬ ТОВАРА: 10 EUR
ВСЕГО: 15 EUR
В таблице `orders_total`, в поля `txt` и `value` теперь значения:
`txt` = "15 EUR"
`value` = "10.0000"
Т.е. модуль расчета "Итоговой Суммы Товаров" (ot_subtotal), не перерасчитывает ее, а просто меняет значок валюты, оставляя значение не тронутым.
А вот модуль расчета "Итоговой Суммы Заказа" (ot_total), берет в расчет результат вычислений модуля "Итоговой Суммы Товаров" (ot_subtotal).
Покупателю уходит майл с неверной суммой.
Но на бланках СЧЕТ и НАКЛАДНАЯ, все цифры правильные....
Я еще могу смириться с косяками визуальными, ошибки сортировок или выборки товаров из базы, или присваиванием текстовой метки БЕСПЛАТНО всем ценникам, которые равны нулю или не заданы совсем - их можно, постепенно, исправить или замаскировать. Но, косяки, убивающие основные функции магазина (выяснение отношений с покупателями, отказ от покупок в "нечистом на руку ларьке", прием угроз из Общества По Защите Прав Потребителей, и прочее) - это уже брак. На все 100%.
Я, конечно, понимаю, какова роль в этом проекте автора сборки - VAMa: он лишь вносит дополнения в opensource. Так же, мне понятно, насколько сложно полноценно протестировать работу каждого модуля, во всех возможных программных окружениях.
Его заслуга, в деле трансформации исходного Oscommerce, немалая. Одна документация чего стоит!
Но, я уже задолбался...
Прощай, Vamshop...
-------------------------------------------------
Вопрос: не мог бы кто-нибудь подтвердить наличие или отсутствие такого дефекта на своих версиях кода?
На онлайн-демо у Vama установлена только одна валюта - проверить нет возможности.
Может я перестарался, копаясь в коде? Хотя, демо, свежеустановленное, у меня, локально, так же, дает такой же сбой...
Как только будет время на передышку - буду переходить на какой-нибудь другой движок.
Вот, последние сюрпризы (Vamshop v.1.68)
В магазине 2 валюты: для примера, пусть будут RUR и EUR. Курс 1 к 1,5 (1 RUR= 1.5 EUR). Основная - RUR.
Покупатель делает заказ на 10 EUR. В админке, на закладке ТОВАРЫ/ДОСТАВКА видим следующее:
СТОИМОСТЬ ТОВАРА: 10 EUR
ВСЕГО: 10 EUR
В этот момент, в базу данных, в таблицу `orders_total`, в поля `txt` и `value` попадают значения:
`txt` = "10 EUR"
`value` = "10.0000"
При редактировании этого заказа, на закладке ОПЛАТА, в разделе ВАЛЮТА, не дай бог поменять валюту на другую, с курсом, отличным от один к одному... В данном случае, меняя валюту на RUR, происходит авто-перерасчет стоимости заказа.
В итоге, после перерасчета, на закладке ТОВАРЫ/ДОСТАВКА видим следующее:
СТОИМОСТЬ ТОВАРА: 10 RUR
ВСЕГО: 10 RUR
В таблице `orders_total`, в поля `txt` и `value` теперь значения:
`txt` = "10 RUR"
`value` = "10.0000"
Т.е суммы не пересчитались, а код валюты поменялся!!! У кого-то будет убыток, кратный разнице курсов валют!!!
Если после этого, вернуть валюту заказа обратно в EUR, то получим волшебное:
СТОИМОСТЬ ТОВАРА: 10 EUR
ВСЕГО: 15 EUR
В таблице `orders_total`, в поля `txt` и `value` теперь значения:
`txt` = "15 EUR"
`value` = "10.0000"
Т.е. модуль расчета "Итоговой Суммы Товаров" (ot_subtotal), не перерасчитывает ее, а просто меняет значок валюты, оставляя значение не тронутым.
А вот модуль расчета "Итоговой Суммы Заказа" (ot_total), берет в расчет результат вычислений модуля "Итоговой Суммы Товаров" (ot_subtotal).
Покупателю уходит майл с неверной суммой.
Но на бланках СЧЕТ и НАКЛАДНАЯ, все цифры правильные....
Я еще могу смириться с косяками визуальными, ошибки сортировок или выборки товаров из базы, или присваиванием текстовой метки БЕСПЛАТНО всем ценникам, которые равны нулю или не заданы совсем - их можно, постепенно, исправить или замаскировать. Но, косяки, убивающие основные функции магазина (выяснение отношений с покупателями, отказ от покупок в "нечистом на руку ларьке", прием угроз из Общества По Защите Прав Потребителей, и прочее) - это уже брак. На все 100%.
Я, конечно, понимаю, какова роль в этом проекте автора сборки - VAMa: он лишь вносит дополнения в opensource. Так же, мне понятно, насколько сложно полноценно протестировать работу каждого модуля, во всех возможных программных окружениях.
Его заслуга, в деле трансформации исходного Oscommerce, немалая. Одна документация чего стоит!
Но, я уже задолбался...
Прощай, Vamshop...
-------------------------------------------------
Вопрос: не мог бы кто-нибудь подтвердить наличие или отсутствие такого дефекта на своих версиях кода?
На онлайн-демо у Vama установлена только одна валюта - проверить нет возможности.
Может я перестарался, копаясь в коде? Хотя, демо, свежеустановленное, у меня, локально, так же, дает такой же сбой...
Добавил сейчас на своем 1.63-м вторую валюту, тот же баг, подтверждаю. Честно, никогда б не подумал, что существует такая проблема, если б Вы не запостили.
palec
Профессор
- Регистрация
- 6 Дек 2006
- Сообщения
- 282
- Реакции
- 49
Ну, вот, воспользовался свободной минуткой, и разобрался в причинах такого косяка.
При отрытии, из админки, заказа на редактирование ( /admin/edit_orders.php ), на закладке ТОВАРЫ/ДОСТАВКА, скрипт показывает, построчно, стоимость каждого заказанного товара, и его цену, В ТОЙ ВАЛЮТЕ, В КОТОРОЙ БЫЛ СДЕЛАН ЗАКАЗ ПОКУПАТЕЛЕМ.
В конце таблицы, идет строка, выводимая модулем "Стоимость Товара" (Модули ИТОГО -> Стоимость Товара [ot_subtotal]).
Затем идет строка, выводимая модулем "Всего" (Модули ИТОГО -> Всего [ot_total]).
Модуль "Стоимость Товара" суммирует стоимости всех товаров в заказе.
Модуль "Всего" суммирует налоги, стоимость доставки, с суммой, посчитанной модулем "Стоимость Товара".
При переключении валюты, на закладке ОПЛАТА, в разделе ВАЛЮТА, значения стоимостей каждого товара в заказе не пересчитываются, и остаются В ТОЙ ВАЛЮТЕ, В КОТОРОЙ БЫЛ СДЕЛАН ЗАКАЗ ПОКУПАТЕЛЕМ.
Затем, модуль "Стоимость Товара" просто суммирует эти "старые" значения, и подставляет к ним символ другой валюты.
А вот модуль "Всего" - самый умный: он единственный, кто помнит о том, что был выбран режим отображения в другой валюте. Поэтому он берет сумму, посчитанную модулем "Стоимость Товара", и умножает ее на курс выбранной валюты.
В итоге, получаем две разные итоговые суммы.
Поскольку, в дальнейшем, и покупатель и продавец, сумму, требуемую к оплате, видят именно ту, которая генерируется модулем "Всего"...
Падла...
Было бы разумней это умножение делать первым в цепочке модулем. Или же - поскольку это, все-таки, страница редактирования данных заказа - умножать на курс выбранной валюты стоимости каждого товара из заказа. А модулям суммирования не заниматься ничем посторонним, кроме суммирования!
Ну, или же, тут косячит скрипт редактора заказов. Косяк присутствует, как при включенном новом AJAX-редакторе, так и при выключенном.
Поверхностное решение - отключение в админке модуля "Стоимость Товара" (ot_subtotal).
Вдруг, кто уже сталкивался с этим, и располагает готовым велосипедом? Поделитесь, плз - чтоб не нырять снова, с головой, в PHP...
Если никто ничем полезным не поделится, то буду искать самостоятельно. Результатом, соответственно, поделюсь.
При отрытии, из админки, заказа на редактирование ( /admin/edit_orders.php ), на закладке ТОВАРЫ/ДОСТАВКА, скрипт показывает, построчно, стоимость каждого заказанного товара, и его цену, В ТОЙ ВАЛЮТЕ, В КОТОРОЙ БЫЛ СДЕЛАН ЗАКАЗ ПОКУПАТЕЛЕМ.
В конце таблицы, идет строка, выводимая модулем "Стоимость Товара" (Модули ИТОГО -> Стоимость Товара [ot_subtotal]).
Затем идет строка, выводимая модулем "Всего" (Модули ИТОГО -> Всего [ot_total]).
Модуль "Стоимость Товара" суммирует стоимости всех товаров в заказе.
Модуль "Всего" суммирует налоги, стоимость доставки, с суммой, посчитанной модулем "Стоимость Товара".
При переключении валюты, на закладке ОПЛАТА, в разделе ВАЛЮТА, значения стоимостей каждого товара в заказе не пересчитываются, и остаются В ТОЙ ВАЛЮТЕ, В КОТОРОЙ БЫЛ СДЕЛАН ЗАКАЗ ПОКУПАТЕЛЕМ.
Затем, модуль "Стоимость Товара" просто суммирует эти "старые" значения, и подставляет к ним символ другой валюты.
А вот модуль "Всего" - самый умный: он единственный, кто помнит о том, что был выбран режим отображения в другой валюте. Поэтому он берет сумму, посчитанную модулем "Стоимость Товара", и умножает ее на курс выбранной валюты.
В итоге, получаем две разные итоговые суммы.
Поскольку, в дальнейшем, и покупатель и продавец, сумму, требуемую к оплате, видят именно ту, которая генерируется модулем "Всего"...
Падла...
Было бы разумней это умножение делать первым в цепочке модулем. Или же - поскольку это, все-таки, страница редактирования данных заказа - умножать на курс выбранной валюты стоимости каждого товара из заказа. А модулям суммирования не заниматься ничем посторонним, кроме суммирования!
Ну, или же, тут косячит скрипт редактора заказов. Косяк присутствует, как при включенном новом AJAX-редакторе, так и при выключенном.
Поверхностное решение - отключение в админке модуля "Стоимость Товара" (ot_subtotal).
Вдруг, кто уже сталкивался с этим, и располагает готовым велосипедом? Поделитесь, плз - чтоб не нырять снова, с головой, в PHP...
Спасибо за отзывчивость!
Если никто ничем полезным не поделится, то буду искать самостоятельно. Результатом, соответственно, поделюсь.
palec
Профессор
- Регистрация
- 6 Дек 2006
- Сообщения
- 282
- Реакции
- 49
Думаю, что бесполезно патчить - я пробовал свежую демку с сайта VAMa установить для теста. Результат тот же.
Проблема эта, из разряда "просто не предусмотрели".
Нужно учить редактор заказов самостоятельно умножать цены на товары, и отучать от умножения, в этом редакторе, модуль ot_total.
Ну, или, как вариант, просто отключить из админки модуль ot_subtotal: в моем случае, налог, непосредственно в магазине, не начисляется, и стоимость доставки, так же, расчитывается индивидуально в каждом случае.
Но это, разумеется, не решение...
Проблема эта, из разряда "просто не предусмотрели".
Нужно учить редактор заказов самостоятельно умножать цены на товары, и отучать от умножения, в этом редакторе, модуль ot_total.
Ну, или, как вариант, просто отключить из админки модуль ot_subtotal: в моем случае, налог, непосредственно в магазине, не начисляется, и стоимость доставки, так же, расчитывается индивидуально в каждом случае.
Но это, разумеется, не решение...
Ergoline
madao
- Регистрация
- 28 Июл 2006
- Сообщения
- 21
- Реакции
- 469
Я выкладывал 1.65 целый.пару страниц назад Для просмотра ссылки ВойдиНе за что
Я сейчас пошел дальше - пропатчил двиг до 1.64-го - тот же результат. Жесть! Пропатчу-ка до 1.65-го, посмотрим, что будет.
palec
Профессор
- Регистрация
- 6 Дек 2006
- Сообщения
- 282
- Реакции
- 49
На всякослучай, попробую взять редактор заказов из Вашего архива.
Спасибо!
- Статус