Wild

16 минут назад, nikifalex сказал:

Вот хотя бы эту тему почитайте с начала

Не подскажете ссылку на "вот эту тему"?

Поиск особых результатов не дал.

1. Есть методы оплаты:

    A) Наличными

    В) Картой

    C) Наложенный платеж.

    Можно ли в вашем модуле задисаблить варианты A и C, если клиент положил в корзину ТОЛЬКО подарочный сертификат?

    Ведь в этой ситуации они нафиг не нужны.

    И оставить их, если в корзине есть другие товары.

2. С симплой конфликтует?

Спасибо, понял.

Грустно...

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

В магазине есть  метода оплаты:

1. Наличными.

2. Кредитной картой.

3. Наложенным платежом.

При покупке сертификата на фронте, некоторые методы оплаты лишние, как их исключить?

К примеру наложенный платеж при доставке почтой НАФИГ не нужен.

Оплата наличными тоже.

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

Как оставить только оплату картой?

Это ваще это как-то конфигурируется?

P.S. OC 2.0.3.1

Я так понял, что достаточно прописать нужные инструкции через PHP.INI и закоментировать код в скрипте, верно?

Залил сайт на хостинг, получаю сабжевые варнинги в /system/library/session.php на строках

ini_set('session.use_only_cookies', 'On');
ini_set('session.use_trans_sid', 'Off');
ini_set('session.cookie_httponly', 'On');

и еще в некоторых модулях, где используется ini_set().

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

Хостеру написал, но интересует чем грозит включение этой инструкции с точки зрения безопасности?

Из бесплатных неплох Fast edit of products.

Заканчиваем рекламу сторонних продуктов! )))

12 часов назад, pimur сказал:

Спасибо. Обязательно добавлю. Все руки не доходят. В планах было запилить ещё ajax подгрузку, без перехода в выборе товара.

Хорошая идея.

С нетерпением жду обновления.

12 часов назад, pimur сказал:

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

На примере батч едитор, можно легко и быстро обработать 100-200 товаров. Раскрывая полный список, отсортирововая их по параметрам. Там же есть и присвоение id в функции сеогенератор, вроде так она называется по памяти.

Я так и делаю.

Еще неплох Admin Quick Edit PRO, но БАТЧ - вне конкуренции, несмотря на спорное удобство некоторых моментов.

Вдогонку...

И еще было бы круто для цвета иметь возможность выбирать не только hex, но и картинку.
Для цветов типа "золото", "медь", "хром", или текстур типа "дерево", "узор" и т.п.
Хранить значение ссылки в том же поле.

Если начинается с "#", значит HEX, иначе - фотка.

Еще хотелось бы видеть список всех товаров с выбранным ID и возможностью быстро открыть их на редактирование.

Есть еще пара мыслей, по фишкам и юзабилити. )))

Просто и со вкусом.
А с учетом его бесплатности - просто ОТЛИЧНО!
Давно руки чесались сделать нечто подобное, но все было некогда! ))

Спасибо.
"Класс" и отзыв оставил.
Проверил на OC 2.0.3.1 - работает без проблем.

Пара пожеланий...
Не хватает поиска товара с автозаполнением как рекомендуемые и интерактивного выбора цвета.
Было бы вашпе ШИКАРНО!

Версия OC 2.0.3.1.

Каковы ваши условия?
Можно в личку.

Есть файл в xls (большой, около 10k записей).
В нем 3 колонки: id, name, price.
Мне нужно обновить только эти данные (в дальнейшем вместо name и price могут быть другие поля).
Не хочется городить огород с полной выгрузкой/загрузкой, это слишком гемморно.
Как максимально просто и без особых заморочек можно сделать сабж (без связей, только таблица products)?

12 часов назад, 1san4ik сказал:

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

Хм, странновато конечно...
У меня просто все работало корректно сразу, по этому не тестировал на подобный косяк.
Просто временные зоны настраиваются не только в PHP, но и в MySql.
Может при определенных обстоятельствах и происходит рассинхронизация.
В идеале нужно попросить хостера проверить эти 2 настройки.
Как вариант попробуйте этот вариант настройки для PHP через htaccess.
Для настройки MySql можно добавить пару строк в код так.
Так же можно попробовать установить это расширение "PHP and Database Timezone" (не тестировал) или "PHP.ini Mini Settings" (у себя ставил, вроде работает, есть доп. настройки для других опций PHP).

Это настройки сервера.
Проконсультируйтесь с техподдержкой хостера.
Они помогут настроить корректный часовой пояс.

Уже присматривался.
В маркете есть еще аналоги.
А что-либо от отечественного производителя?

У клиента есть желание организовать нечто подобное сабжу.
Несколько менеджеров должны иметь возможность максимально просто и быстро создавать заказы для клиентов с планшета.
Т.е. типа из списка/прайса набросал нужных товаров в корзину, указал вид доставки/оплаты, получателя и сформировал заказ.
Если делать это штатными средствами, то очень громоздко и не оперативно получается.
Кто что видел подобное?

Спасибо что не поленились проверить.
Костыль, конечно, но самое простое решение проблемы.
Результатом доволен, применю у клиента.
Не уверен, но для уважаемого @piklas похоже именно это и сделали.
Тупо исправили количество знаков после запятой в поле БД (работы - 5 секунд).
Хотя он писал про некий модификатор...
Может он "пустышка"? ))
@piklas, не поделитесь на посмотреть?
Мне чисто из спортивного интереса.
Уверяю вас, он не представляет особой ценности.
Особенно если в магазине НЕ ИСПОЛЬЗУЕТСЯ многовалютный учет с фишками типа автообновление курса и т.п.
Вдруг выяснится что можно предъявить претензии разработчику за "фуфел"? ))

Кстати вопрос...
Не проверял (пока лениво), но если в таблице объявлено 2 знака после запятой, то при записи туда значения 10.00517 туда запишется значение 10.01 (с математическим округлением) или 10.00 (остальные знаки обрежутся)?

15 часов назад, piklas сказал:

Я честно не знаю что сделал программист, но он сделал именно то что мне надо.

Просто когда вы начинаете пост фразой типа "...Отписываюсь о решении вопроса...", то предполагается, что вы нашли решение и опубликуете его в паблик для других.
Даже если вы сделали это с помощью стороннего программера.
Если же вы тупо заплатили кому-то, решили свою проблему, но не собираетесь опубликовывать его, то успокойтесь и не пишите пафосных постов.
Это решение знают ВСЕ 100% людей сидящих на этом форуме.
Причем не только вашей, но и ВООБЩЕ ВСЕХ ПРОБЛЕМ (заплати и тебе сделают)!
Вы не догадывались об этом?

Спасибо, буду пробовать.
Немного настораживает фраза "...при некоторых условиях...".
Какие могут быть подводные камни?

Не понял...
Мне не нужна цена без скидки (или нужна?), нужно просто вывести какая скидка применялась.
Пример - есть товар, который стоит 10 руб., а при покупке 5 шт. цена = 9,50.
На другой товар скидка при заказе 3 шт. и т.д.
В корзину все ложится правильно, итоговая сумма верная, в уведомлениях тоже все корректно.
Просто для бухгалтерии нужно видеть в письмах какая цена от какого количества применялась.
Т.е. что-то типа:
 

Мда...
Так можно описывать любое решение проблемы:
"Была проблема - бла-бла-бла. Нашел решение - заплатил программеру, он сделал для меня модуль!"
А что, так можно было? Ж8-(  )

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

Спасибо за разъяснения.
Избавление от лишних запросов это хорошо, но в данном случае вопрос не в этом.
Суть вопроса в индексации и продвижении.
Эти 2 варианта равнозначны или поисковые роботы отдадут предпочтение варианту с транслитерацией?
Есть какие-либо изыскания на эту тему?

Вопрос по поводу применения транслитерации названия или чего-то типа product_id, category_id в качестве SEO ссылки.
Транслитерация имени выглядит для юзера более понятной, но возникают нюансы при необходимости к примеру изменить имя категории или ее вложенность и т.п., из-за которых смысловая нагрузка старого URL утрачивается или меняется.
Приходится делать редиректы.

В варианте product_id, category_id не нужно особо париться с подобными заморочками, но возникает вопрос - имеет ли некое преимущество тот или иной вариант для индексации и продвижения?