Wonderful Reply Cristian!
Learned a lot from it — much appreciated.
OK, so I’m thinking I’m getting close to a spec, that I can hand over to someone to handle the chunk(s) that will need to be built… but with your excellent knowledge of S2Member, I have to know what’s even possible so that I can start my contractor in a “doable direction”.
Please be on the “lookout” for that “what the hell stuff — we can’t do that”… because my impression in going through the documentation and watching the videos… is leading me to believe that all my steps below can be reasonably easily accomplished with some effort… that nothing I’ve put as a step… is a modification crusher, causing a complete rethink of the way to process these “automatically date sensitive, auto expiring Paid Posts”.
To review and clarify… old stuff is not bold, new stuff — is…
My last two entries were:
9) That Post always has an unique ‘tag_id=xxxxx’ and that number is also associated with this member.
No, posts are not associated to users in WP, unless you’re talking about a customization you’d create for this?
‘tag_id=xxxxx’ is associated with the user… I’ve dug into this… and when I go to the member user history, it shows all the posts that are associated with that member, when I click on the “number of posts” it expands and shows all posts… so the question #10 “seems” like it would be possible… see below.
10) In S2member’s Transaction History… I want to ADD that ‘tag_id=xxxx’ to that single paid transaction in the transaction flow — passed along so the other items retrieved by the s2_payment_notification API and stored — so that I know when the expiration date of the transaction is — associated with that particular Post — are all related. “Payment” = “Post stays up for that length of time” (but I’ll need to create a script to do that housekeeping)
s2Member doesn’t have a transaction history. You could create one with the Payment Notification and a custom script, though.
GREAT!! Payment Notification and Custom script can create the Transaction History — super!!! If I actually clarify what I hope can happen — by studying your answers… I’ll summarize the concept below and you can let me know if S2member is able to pass the information forward, through PayPal so that it will come full circle when the API finds out that a time sensitive transaction has expired.
14) I’m guessing that S2member passes $user_id to PayPal and that is why the s2_payment_notification API is actually able to return the information. (yes/no?)
When the user is logged in at the time he loads the page with the pro-form, the pro-form will include the user’s ID so s2Member knows to upgrade that account after checkout.
Your answer to #14 gives me hope… but the critical data point… that will make this “really work” is detailed in my spec below…
Again, your insight and suggestions are truly appreciated — feel free to intersperse per each line as before… that worked really well !!
The Summary for my contractor:
1) As the Member — registers — WordPress will automatically assign a standard WP Role.
2) Registered Members — are assigned Author Role and when they create a Post — they are still a S2 Level 0
3) The Member finishes the post and then S2Member prompts for payment for that Post
4) The Post/S2 contains a way to select from dedicated buttons (3 days, 5 days, 10 days, 20 days, etc…)
5) Member selects from Payment Options, Pays and becomes a S2 Level 1
6) The Transfer of information to PayPal includes the usual information but ALSO includes the Post_ID#
7) PayPal hangs onto the Custom Field passed to them — that field being the Post_ID#
8) When the s2_payment_notification API gets information from PayPal, the MemberID, it includes the Custom Field Post_ID# and the normal EOT Notificiation information typically returned.
9) Whether the s2_payment_notification API needs to write to the MySQL database, or to a new text file… it seems like the “actionable set” of data… the critical ones being just the date that the “post needs to change from Published to Pending Review” and the “Post_ID#” will be available for a script to act upon.
10) That script, reads the Text File or scans the MySQL database, and updates the Published Status of every Post that has the expired date in the records.
11) If the Member decides to extend the Post by paying again, with their Role as Author, they would be able to edit the Post and “repay” by changing anything in the Post at all.
12) When the Post Publishes — just like in Step #3 happens again — S2Member would prompt for payment again… so this would indicate that the Transaction_ID# from PayPal, would change to be able to track this “new transaction”.
13) Unless it’s better handled by S2Member, to Update that original charge — which is beyond my understanding of the interoperability between S2Member and PayPal Pro with Recurring Charges Account.
I’m trying hard to define this accurately for the best result and think this is going to be an excellent feature for future S2Member Pro users…
Thanks again for your thoughts and the time taken to think this through with me!!
R