Jump to content

Best method for storing payment transactions


NikNak
 Share

Recommended Posts

EDIT:  The LimitPageTable module seems to offer the ability to remove the trash icon from PageTable. 

I'd still be interested if anyone thinks this approach could be improved though :-)

Hi

I'm looking into using Stripe to take membership payments for a society. ie - once per year, so not lots of transactions.

The process all works fine, but I am not sure of the best way to structure storing the transactions records in PW.

My initial thought was to create a pageTable for payments and add this to the $user template. So each time a payment is made, a new page is created (in a payments folder under admin section) that logs the transaction, and this is then added to the pageTable list in the $user admin page via the API. This way, all transactions for the user are easily visible to the admin. All adjustments to these records would need to be by the API and not by manual editing. I like the idea of each transaction being a page.

The trouble with this method, is that I do not want the administrators to be able to remove these entries from the pageTable, as they can currently via the trash icon. I can set the actual transaction page itself to be un-editable - but this doesn't stop its removal from a pageTable.

If you set the visibility of the pageTable field so it is un-editable (locked), it then only shows you a list of page id's (ie, no pageTable layout) - so the listing becomes meaningless to the administrator.

So my question is....  Does this approach seem to make most sense (if I can remove the trash icons in the pageTable listing) - or should I try a different approach for storing this data. It needs to make life easy for the administrators of the site.

Many thanks 

Nik

 

Edited by NikNak
Link to comment
Share on other sites

Thanks Robin - I was indeed considering this. The RuntimeMarkup module doesn't scope the current $user being edited though - it only works on normal pages. So I think this counts this option out.  I didn't realise that $page wouldn't return the current user being edited.

Kind regards

Nik

Link to comment
Share on other sites

Nik,

Maybe I am missing the point but my example code above is meant to show that ALL ProcessWire variables are available to you. They will just have to be called as if they were in  function, i.e. user wire(). You are not limited to page(s) only :). However, for syntactic convenience, $pages and $page are available without resorting to wire('page'); I don't understand what the current user being edited means. However, to get the current user, you would do, for example...

if(wire('user')->name=='santa') return "Dude, where's my stuff?";
else {
// do something else
}

Instead of typing all that code in there, you can user wireRenderFile() and write all your code and logic in an external php file. 

Link to comment
Share on other sites

Hi again

If you are editing a users page at a url like "/admin/access/users/edit/?id=3718" I was trying to access the id 3718, so I could find other pages related to this id. I wasn't trying to get the current $user

Sorry for not being clear.

Kind regards

Nik

 

 

Link to comment
Share on other sites

Thanks - but if you want to get the id without hard coding it.  In other scenarios you use the $page->id which returns the id of the current page being edited.

How do you return the id of the current user being edited?  

Kind regards

Nik

 

Link to comment
Share on other sites

  1. Add the field to your user template
  2. Do what you want :)...e.g.
$process = wire('process'); 
$u = $process->getPage();// this is an object
$id = $u->id;
return $id;// will return 40 for guest, 41 for superuser, etc...
//return $process->className();// would return ProcessUser. Useful to know if you are using the field elsewhere and want to do different things based on context
// return $u->email;// etc...

Edit:

But that only works when you are actually editing that page, of course

  • Like 3
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...