What is the colum for Finished for in this listing, found nothing in the docs?
subscriptionlisting.jpg
The number of 'Yearly Premium Support' times the member has paid for and finished?
ok thanks, strange because i just created it. no subscribers.
I'm probably wrong then. One of the developers or
@Kindred would be able to tell you for sure.
No, that's what it is supposed to mean..
The subscription is expired at the end of a term...
Quote from: Kindred on December 15, 2023, 09:17:51 AMNo, that's what it is supposed to mean..
The subscription is expired at the end of a term...
Oh ok so it just means "hey you selected not to let the user resubscribe in your settings" lol :) They could have used a better column header text for that lol.. Like ReSub or 1x Only lol
Quote from: durangod on December 15, 2023, 11:32:08 AMOh ok so it just means "hey you selected not to let the user resubscribe in your settings"
No, it's the total of subscriptions that have expired. "Active" is the number of active subscribers currently in the subscription group. "Pending Payment" is the number of subscriptions that have failed because payment wasn't successfully completed.
yes, exactly what Sir Osis said
Quote from: Sir Osis of Liver on December 15, 2023, 12:12:02 PMNo, it's the total of subscriptions that have expired. "Active" is the number of active subscribers currently in the subscription group. "Pending Payment" is the number of subscriptions that have failed because payment wasn't successfully completed.
So that makes me want to ask how does it expire when i just created it and noone has used it. Maybe i need to delete it and recreate it?
Click on the subscription title, it should list you everyone who has ever subscribed. If it doesn't give you any names, that might be a bug of some sort, then again if it does perhaps the name will explain everything?
I deleted it and recreated it... we will see if it does it again... :)
Yep i just refreshed the page, it set finished to 1 again... hmmmm
here is the info, please see if you can duplicate it on your end
Annual Premium Service Contract
desc:
This is a subscription to premium support. Premium support provides extra's that non subscription users do not have access too. The subscription is for premium support for 1 year after the initial purchase subscription has expired.
auto renew checked
active checked
primary dont change
choose some private group for additional
30 days reminder
email:
Your Annual Premium Service Contract Is About To Expire
Hello {NAME},
Thank you for choosing to purchase our premium support subscription service last time. We hope that you found the services provided worth while and that you were happy with the process as well. If not please let us know.
Your subscription is about to expire in the next 30 days. If you want to auto renew the subscription for another 1 year, please choose that option in the subscription opions in your account settings. This is just a friendly reminder that this subscription for premium service will expire soon and your access to the premium subject matter section on the forum will also expire with it.
Again thank you,
{FORUM}
350.00
1 year
Do try seeing the list of subscribed members. This does sound like some sort of counter bug, but just out of curiosity I'd like to know if it lists any members.
If you add a new subscription it should display Pending Payment = 0, Finished = 0, Active = 0. That's what I'm seeing in core install. If you had created the same subscription previously, subscribed a member, then deleted the sub and added it again, it might carry over the count from first sub.
Hi, sorry i had to quickly shut down my computer and clear out everything as my roof started to leak right over the desk, just my day lol
There has never been anyone subscribed to it.
You can look in the log_subscribed table. If there have been no subcribers to any subscription it should be empty.
Quote from: Sir Osis of Liver on December 15, 2023, 08:40:34 PMYou can look in the log_subscribed table. If there have been no subcribers to any subscription it should be empty.
interesting, it appears that admin is subscribed, i am not sure why. I removed the record... that is interesting. im gonna have to start the process over again and find why how admin got subscribed, if i find a problem il let you know here. No news is good news :)
Ok i got it... if you click on the subscription as if you are going to purchase it, when you get to the first paypal screen (no login or anything) just hit the back button (you dont have a cancel option like i add to my stuff) so it must thing its waiting for paypal to finish the transaction.
Yep and finished is now 1 again.
In my forms (and i have my account set up this way too) Once the customer gets to paypal and verifies the order (no login required) then there is a cancel option which takes them back to the site and a special cancel page.
This is how yours should work...
Go here and test it..
webstoresoftware dot com/invest.php
Then click the buy now button for 10 bucks
You will be sent to a paypal screen to confirm the order (no login required yet)
On the next screen on the bottom there is a cancel link. Click it
It takes you back to the site page called
webstoresoftware dot com/cancel.php
But yours does not work that way which is why there is a ghost transaction record left in the db which will never be completed. You need to add the cancel option so that the transaction record in the db is removed if they cancel Otherwise you end up with a bunch of orphaned transaction records that will never be completed.
Yes i think its a bug...
Hmm, I'm not sure what you've done, but that's not how paid subs works in 2.1 core. The "ORDER WITH PAYPAL" button on the subs order page should take you directly to PayPal login, the second screen you see in your setup. The first screen with the cancel button is not normally displayed, you must have changed something on the PP end. If you mess with that, you're changing the way paid subs interacts with the PP API.
It's not as simple as it looks, there are several steps involved in confirming payment and activating the subscription. When the order button is clicked, it takes subscriber to PP where they can log into their PP account or pay with credit card. When payment is successful, PP posts an IPN to subscriptions.php, the form handler on your end. The IPN contains a verification code, which the forum posts back to PP, and if it's correct PP posts a verification to the forum and the sub is activated. All of those things must happen in correct order for the subscription process to complete. If you introduce another step in the sequence (the cancel option) it can have an unexpected effect.
Yes sir i understand exactly how the IPN works, you get 1 shot at it, if it does not pass then the sale process is over and no final transaction information is recorded in the db.
I have a cancel option in my account, if i dont do that i also include a cancel option in the form that is submitted to paypal. That cancel option just give the user a chance to cancel while on paypal. It is a well known option that paypal has processed many many times.
The advantage of a cancel option is that if the customer chooses to cancel the order, the IPN will return that information and then the temporary transaction record is removed from the db during that process. This avoids having partial transactions records (incomplete sales) records that are basically orphaned sitting in the db which will never be processed.
I was thinking that the log_subscription table was possibly a temp transaction storeage table that would keep that from happening. Because the initial temp trans is stored there and then when the customer completes the sale it is moved to a more perm table. And then every once in a while admin would clear the old orphaned transactions from the log_subscription table. That would be ideal but again that is not how the SMF process works that i know of.
If i am correct then over time there could be hundreds or thousands orphaned transactions in that table that are useless and every one of them was just someone that went to paypal and hit the back button because there is no cancel option that would clear that table record out of there when they cancel.
I hope that makes sense. :)
here is one option from
https://developer.paypal.com/beta/apm-beta/additional-information/js-sdk-params-payment-fields/#oncancel
cancel_option.jpg
I usually just put it in the form like so
$form->getElement('cancel')->setValue($cancelreturn);
or even easier
<input type="hidden" name="cancel_return" value="the return url" >
So on a cancel you still get the IPN but its a cancel, then you go from there and remove the record that has that trackingid. I believe you can also add the trackingid to the url of the cancel page and then use the $_GET to grab it and go remove the record, either way works.
Sir Osis you got me with the bug deal when i first joined here, we have those little nats here in texas and i thought i had one one my screen... lol that is an excellent avatar... :0)
Well, if you don't receive an IPN nothing happens, nothing is logged. If you receive an IPN and verification fails, the subscription will be shown as pending payment. You can confirm payment in your PP account and manually activate the subscription. Nothing in the transaction sequence should create an expired subscription, subs are expired by scheduled tasks. Best guess is PP sends something back when subscriber cancels, and it's being misread as a broken IPN.
I've attached two files that you can use for diagnostic purposes. Subscriptions-PayPal.2.1.4.error_mod.php replaces Subscriptions-PayPal.php and contains some additional error handling that's not in core. subscriptions.2.1.4.ipn_log.php replaces subscriptions.php, it will log any IPN sent by PP in error log. Save the originals.
@durangod - is this resolved?