The (int) declares that the value being assigned is an integer, however the value is actually a float, therefore the float is converted into an integer resulting in the decimal places being cut off. E.g 6.95 declared as an integer is actually 6. This is then inserted into the database, but due to MySQL column settings the .00 is reappended during the insert.
So the pending problem has to do with the other problem of the amounts not being equal? If that is the case and the fix is so simple I would be blown away that they script owner would not have fixed this?
Simple bugs are often the hardest to fix, no this one was not particularly difficult for me because I have several years experience in tracking and fixing bugs in open source apps. I am sure David will fix the issue when he is made aware of the fix. Note that I didn't post the fix to the phpLD forums because Fastian created the thread in the support section which I do not have access to. No point paying for support and fixing the bugs yourself So if someone could post the fix over in Fastian's thread (if it hasn't been already) I would appreciate it.
Still there is more things in 3.2 to be corrected for showing payments list. CONFIRMATION in table can have values of -1,0,1. We don't know what for value 3 is checked... This doesn't correspond to array created for showing payment status.Think idea was OK, however not finished ? Payment Pending status is not supported by ipn data retrieved by the script. In previous 3.xx - showing payments seems to be ok, however found more things to be corrected after payment function: checkin' payment amount, setting date expire... and some more.
Sorry dargre but I am finding it difficult to understand what you mean. The 'CONFIRMATION' is checked within the same function where the line of code I edited is located. This line: $pdata['CONFIRMED'] = ($success ? 1 : 0); Code (markup): Checks the value of $success which is a true or false and determines whether to set a 0 or 1 value for CONFIRMED. Then this if block: if ((float) $pdata['PAYED_TOTAL'] < (float) $pdata['TOTAL']) { $pdata['CONFIRMED'] = -1; } Code (markup): Checks to see if the amount paid was less than the actual charge, and if so sets CONFIRMED to be -1. That takes care of all three options? Or did I completely misunderstand your post
'CONFIRMED' can be: -1 (if payed amount is lower to declared (can be pending or whatever) 0 (payment not succesfull) 1 (succesfull) And now look at Admin conf_payment.tpl how it is checked to show payment status. 3 = Canceled (wonder when value '3' can be set for 'CONFIRMED' ) Uncleared? - So this will be set if payment not succesfull !? Do you still think it's correct? In 3.1 we have in tpl file: And that was OK. But there are other things in 3.1 to be changed:
Ok, I understand what you are talking about now I don't think there is anything wrong with those two additional options being available in the template. It certainly won't affect the functionality to any degree. The fact that the options are not available in the programming just means it is something that is a work in progress. So I would assume that David and co are still working on adding those two options to the system. I would imagine Canceled is for payments which are reversed, charged back etc and the Uncleared status is for payments made via echeck. Obviously the only person who can confirm that is David, but I don't see any problem there.
Ok, made the change and I hope the next payment will go properly. I guess I will take your word on it that simple bugs can go unnoticed but I still think if a script owner puts some resources into fixing something it should not be that hard. Also I don't know why they were getting people to do a fix that did not work, you would think they would test it?
Do also think it is something that is a work in progress. However if found could be corrected. 'uncleared' shouldn't mean 'cancelled' Still there is more things in payment system which we can't call a 'bug', but can cause (for 80%) unwanted link behaviour that I'm sure most of people do not know.
Thanks a lot dargre & SilkySmooth I wasn't aware of discussion going on here and I responded to the post in phpLD forum. See Here (PS. Silkey, looks like you got access to supporters forum ) Now, following dargre post, that's what i was saying in start that it is something to do with "Confirmed" values. In v3.1 we had -1 (if payed amount is lower to declared = pending) 0 (payment not successful) 1 (Paid = Successful ) with 3.2, its acting like this -1 (if payed amount is lower to declared = pending) 0 (payment not successful ~ Shows Uncleared) 1 (Uncleared ) 2 (Paid) 3 (Cancelled) Now, I am not really sure how they have devised the new value for "Paid" coz I think its wrong. (All previous link having Paid status are now "Unclear" if you are upgrading from v3.1) Anyway, if you go to templates/core/admin/conf_payment.tpl and change to It shows "Paid" like the it should be .... I am not really sure if that is the mistake so Please DO NOT use it. Let dargre or SilkySmooth confirm this. Edited: No. This probably isn't the right way. (It was a bad attempt from me.) If you manually change a status to "Paid", the DB gets the value of "2" and then you will be seeing "Uncleared". ---> 2 is the right value for "Paid" But with normal submitting, every successful payment, its get value "1" .... "weird" PS. There is a new function "SetNewPaymentStatus" in Admin/dirdb_admin.php that might be playing a role here.
I guess it is that rounding error, I am seeing it very obviously in my new bid directory. All the payments that have come through with even amounts (no cents) are showing paid and the ones that paid $8.50 are showing pending. So taking out that 'int' will fix that right?
so you took out 'int' and it is not working? On the phpld forums dawzz was saying it should say 'float' instead of 'int'.
Fastian, Yes, I got access to the forums now First off your change, no, as per your edit this isn't the right way to do this. All you would achieve is fixing the display for your payments prior to your update and all newer payments would have the problems. Have you now got it sorted, Dawzz is saying his function update is installed and running on your site now without problems? @jg123, no declaring it as a float would be the same as not declaring it. It is unnecessary and just bloats the code.
Now the thread over there has been changed again and they are saying to take out all 'int' and 'float'????
Seems like you are getting confused with all that "int" and "float" talk Ok let me help you here and to those who don't have access to phpLD support forum. (As always, Backup your admin/functions.php file first) Find (Line 1793/1794/1795 if you haven't changed your function.php) $pdata['PAYED_TOTAL'] = (int) $data['total']; $pdata['PAYED_QUANTITY'] = (float) $data['quantity']; $pdata['CONFIRMED'] = ($success ? 1 : 0); PHP: Change it to $pdata['PAYED_TOTAL'] = $data['total']; $pdata['PAYED_QUANTITY'] = $data['quantity']; $pdata['CONFIRMED'] = ($success ? 2 : 0); PHP: Find (Line 1799 if you haven't changed your function.php) if ((float) $pdata['PAYED_TOTAL'] < (float) $pdata['TOTAL']) PHP: Change it to if ($pdata['PAYED_TOTAL'] < $pdata['TOTAL']) PHP: Find (Line 1812 if you haven't changed your function.php) if ($pdata['CONFIRMED'] != 1 || (float) $pdata['PAYED_TOTAL'] < (float) $pdata['TOTAL']) PHP: Change it to if ($pdata['CONFIRMED'] != 1 || $pdata['PAYED_TOTAL'] < $pdata['TOTAL']) PHP: I believe the most important change is Since that is the new value in phpLD v3.2 as compare to v3.1 value of 1. I confirmed it, it works fine now Hope it will help other users as well
Ok, all I did is take out that one 'int' as recommended first and I just got a payment of $8.99 (odd number) and it is showing paid not pending. So I guess I am not going to change anything else unless it stops working or something else does not work properly.