excalibur

Сделал, чтобы после успешного нажатия "отправить" кнопка исчезала, в fast_order.js после <a onclick="$(window).colorbox.close();">Закрыть</a> это окно?</span>'); дописал $('.fast_order_button').remove(); Но еще интересует все-таки защита от спам-атаки. Вы конечно можете рассказывать, что магазин реально работает столько то месяцев или лет и ни разу такого не было, но тут как повезет, может попасться какой-нибудь малолетний кулхацкер, которому не вреда ради, а просто из интереса захочется написать скрипт и завалить почту тысячами быстрых заказов. Оно надо? Поэтому считаю необходимым сделать какое-то ограничение, например поставить интервал для выполения скрипта с одного ip / сессии в 1-3 минуты хотя бы.. Кто-нибудь подскажет как это прописать, может еще идеи будут?...

Только что решил этот вопрос одной малюсенькой строчкой)) Все элементарно) В catalog/controller/module/featured.php в 21 строке перед $products = array_slice($products, 0, (int)$setting['limit']); Вставляем замечательную функцию перемешивания массива в случайном порядке :-) shuffle ($products); Вуаля! Теперь, если у вас задано хоть 20 товаров в рекомендуемые, а выводится лишь 3 - то каждый раз они будут разные и постепенно обязательно покажутся все. Еще можно подумать над тем, чтобы сделать в модулях акционных, рекомендуемых товаров "карусель", чтобы можно было прокручивать например 10 товаров, при отображаемых 3-4.

И почему-то никто нигде не упоминает, что если у вас где-либо в файлах прописаны статические ссылки, или в модулях, или в шаблонах, то в них придется всё вручную править

.... Ситуация конечно гипотетическая, но не невероятная, и поэтому защиту от дурака исключать не стоит. И поэтому опенкарт пошел по такому пути. Можете поделиться решением своим?.. Я о этой самой дополнительной проверке? Сам же разобрался - server_url - ответ от сервера приходит тогда, когда на счет поступила оплата. Соответственно самое разумное решение - по возврату клиента (return_url) - подтвердить с помощью confirm заказ и поставить ему статус "ожидание оплаты". А вот для server_url вписать скрипт, который сверяет цифровую подпись и затем присваивает заказу статус оплаченого, после чего клиенту на почту высылается уведомление (если прописать его в вызове функции update). Но нужно учесть еще такой момент - клиент мог не нажать кнопку возврата из магазина либо отвлечься, а в это время при оплате с карты например server_url ответ придет раньше, чем вернется клиент по ссылке result_url. Поэтому для сервера добавил проверку - если статус заказа нулевой - сперва он подтверждается со статусом "ожидание оплаты", отправляется уведомление админу и клиенту, а затем сразу же меняется его статус) Запутанно может немного написал, но кто вникал в логику работы платежного модуля, думаю поймет :) Поправьте или подскажите, если чего-то не учёл. Да, еще при ответе сервера, после сверения цифровой подписи проверяется чтобы статус ответа был success.

Столкнулся с проблемой в модуле Liqpay. Там используется 1-й вариант - ссылка передается в форме. Точнее две ссылке. result_url - страница на которую вернется клиент и server_url - адрес куда посылает ответ сервер. Так указано в API документации к Liq&Buy 1.2. Так вот, в xml форме server_url был указан как обращение к функции callback() в контроллере liqpay ( $this->url->link('payment/liqpay/callback', '', 'SSL') ). В этой функции производится проверка подписей мерчанта по заданным правилам, и в случае совпадения вызывается функция confirm из модели checkout/order - создается заказ со статусом указанным в настройках модуля Liqpay после успешной оплаты. А в result_url была указана страница $this->url->link('checkout/success', '', 'SSL'). В итоге что получалось - создавался заказ с нулевым статусом (по-умолчанию). Тыцаешь на кнопку вернутся в магазин после оплаты ( к слову, создание счета для оплаты в терминале - pay_way - delayed) - высвечивается уведомление, мол ваш заказ № такой-то оформлен, можете смотреть в личном кабинете, ссылка, все дела. Но реально статус заказа не изменялся. Т.е. функция callback вообще не срабатывала. Пробовал убирать проверку сигнатуры, на случай каких-то ошибок - даже без проверки функция не обрабатывалась. Как вывод -то ли сервер не посылает этот запрос до РЕАЛЬНОЙ оплаты счета через терминал, либо я не знаю в чем причина. В итоге я вопрос решил тем что в result_url вписал ссылку не checkout/success, а payment/liqpay/callback и затем redirect на checkout/success - тогда всё стало обрабатываться корректно после нажатия на сайте LIQPAY кнопки "в магазин" после оформления счета для оплаты в терминале самообслуживания. Конечно в процессе тестов обнаружил еще одну любопытную вещь - что при каждом обновлении страницы checkout либо возврате к предыдущим шагам для изменения способа оплаты, способа доставки либо даже написания комментария - КАЖДЫЙ раз создается новый заказ, а предыдущий будет "валяться" в базе данных как "утерянный". В итоге может оказываться огромнейшее количество дублей брошенных заказов, который клиент реально таки оформил, оплатил и вы его выполнили. А в базе у вас останутся эти самые дубли. Т.е. клиент начал оформлять заказ под номером 54 к примеру, а потом или страницу обновил или просто ему понравилось пощелкать "шаги оформления" кнопкой "изменить, ну вот прикольно, типа как скользит вверх-вниз - а в базу пишутся новые заказы и оформит он это всё уже под номером, скажем 70. А вы будете выводить себе статистику потом ложную, что из 100 набранных корзин заказы сделало 2 человека, хотя реально может оказаться 20. (условно). Эта проблема решилась очень легко с помощью бесплатного файла vqmod ttp://forum.opencart.com/viewtopic.php?t=9192 - вот ссылка на описание данного бага, кому нужно, можете скачать, установить.

Сделал vqmod xml для OpenCart 1.5.х.х, кому интересно - скачайте, попробуйте, должно работать :) special.xml

Хм, все сделал только теперь есть проблема - поиск не срабатывает по нажатию enter :( Не пойму в чем может быть причина

Корзина хранится примерно в течении 20 минут бездействия для гостевого посещения, затем самоочищается, как это исправить? Уже делал запрос у провайдера на увеличение gc.session_maxlifetime со стандартных 1440 (24 минуты), поменяли - не помогло.

Ну так будьте добры, написать как решили, в чём проблема? Не подумали о том, что у других могут быть такие же вопросы?