MarkE

Actually I guess this is unnecessary if subscription pages are children of member pages, but that explicit links would be necessary for, say, a "subscription type" relationship, if that is a page.

Thanks for the encouraging comments and the helpful suggestions. Correct. I was starting with an OO design and realised that classes could map to templates and objects to pages. I found https://processwire.com/docs/tutorials/using-custom-page-types-in-processwire/ which shows exactly how to do this mapping. This would allow me to add template/class-specific methods too. But I'm not sure if this is over-engineering things. Since my OP I found that you can in fact assign the "process" built-in field to any template, which I guess would give me a page-based equivalent of a method without having to code a Class structure? I'm assuming such a process would operate in the back-end whenever the page was accessed, just like the admin template - in which case I could use the basic roles/permissions linked with the templates. So, for example, I could have a template "Member" and a template "Subscription" with page instances of each and a one-many relationship. The Member template would define the basic member fields (email, name, address etc) and a table for that member's subscriptions. The process field for Member would point to a process which displayed a form to create a new subscription which, when submitted, would create a new page instance of Subscription with a link back to the member page (and a link on the member page to it). A "Membership secretary" role would then have the relevant permissions for the Member template. Do I understand correctly? I'm not sure what the API would be to create a new page directly. With the custom pages / class - based approach, I would just do something like: $sub = new Subscription(); $sub->title = $subRef; //$subRef and field values entered in form $sub->field1 = etc... $sub->save(); My query about the admin template was that it wouldn't allow me to set up different permissions for the different objects as they would all use the same template - or would the approach be to code the permissions in each processmodule, in which case is that better/worse than the approach I outlined above?

I’m fairly new to ProcessWire, so please excuse any dumb questions. As a test (but also for real) I built a simple static site very easily and really liked the way PW worked. Now I’d like to build a more complex site. A brief description of the proposed site first: It will be a site for a local club which has 100-200 members who subscribe (and pay) annually. There are a number of events during the year – mostly free to members, but some which require payment and some which are open to the public. Payments will either be off-system (cash, cheque or bank transfer) and recorded manually on the system by the Treasurer or via GoCardless (which seems to have a well-documented API). Stripe or Paypal may be added later, but not at first. I propose that emails will be drafted on the site (and linked to mailing lists) then sent via MailChimp (which again seems to have a good API). The site will also have static pages relating to the group’s activities. Users fall into two classes: 1. General members who will normally just view the site but will occasionally need access to (a) view their own details (and update certain fields), (b) book on events (if booking is required) or (c) setup/access their GoCardless account via redirect and the API. For these members, I do not want a user/password system, but rather just email them a one-time URL to carry out their requested task. 2. Admin members (with various roles, e.g. membership secretary, treasurer, event organiser) who will have normal user profiles with logon ids and passwords. I built a draft class diagram for the application. Then, after reading quite a few (like a lot!) of tutorials and forum posts, I felt that the best way forward would be to deal with (1) in the “front end” and (2) in the “back end”. In particular, I found https://processwire.com/docs/tutorials/using-custom-page-types-in-processwire/ and https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/ to be very informative. There is still a lot I don’t understand, however, as PW is clearly a very powerful and complex (although very logical and well-designed) tool, so I am sure that I will have further questions as I get stuck into the detail. For now, my questions are fairly high-level: 1. Is PW suitable for the proposed application (pointers to any similar developments would be helpful)? 2. Is my proposal re using the front end for general members and the back end for admin members sensible? 3. In particular, is it feasible/sensible to implement a reasonably fine-grained permissions system in the back end for the admin functions that will create/read/update/delete class instances/pages? 4. Am I right in thinking that all admin pages need to use the same admin template? If so, what is the approach for achieving (3)? Any comments ranging from “you must be daft” to “this is how to do it” will be gratefully received!