Club website development

[MarkE]

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!

[david vin]

I think it fits. 

[bernhard]

Hi @MarkE and welcome to PW and the forum ? 

I think PW is great for building what you described. But I'm "a little" biased as I build everything with PW from simple websites to complex custom CRM and Feedback Tools...

14 hours ago, MarkE said:

Is PW suitable for the proposed application (pointers to any similar developments would be helpful)?

Yes. Is it a sports club? Then you can have a look at mistelbach-mustangs.at's calendar or the team site.

14 hours ago, MarkE said:

Is my proposal re using the front end for general members and the back end for admin members sensible?

Sounds good to me. But I'd recommend starting in the backend first (more on that later). You'll get an idea of how everything works and you might be better off doing the frist part also in the backend. That's not a general statement, you'll just be able to do a better decision once you know how the system works and it might save you from building a custom frontend once you know how easy it is to build custom backends ? 

14 hours ago, MarkE said:

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?

Not sure about this one. I guess your wording is just a bit different from the PW world. I guess you mean you want to want to modify your data objects, right? So in PW this would mean your objects are pages, and your properties are fields. Classes would be templates, so for example you could have a template (~class) "team", an instance of this class would be the object, in PW this would be a page "Team A", and to modify it you'd simply add/remove/edit such a page.

And yes, you can control anything you want here easily. You can set permissions in the backend and you can even set permissions on a field level. If that still is not enough there are several helper modules out there: https://modules.processwire.com/categories/users-access/

And if that still is not enough control, it's really easy to attach hooks or for reusability and better code organization it's also dead simple to create custom modules.

14 hours ago, MarkE said:

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)?

That does sound strange again. The PW backend is just an application built on top of the PW API to manage it's own data (crazy and genius). Just have a look at the page tree and find your admin's root page (page id = 2). Most of the pages there use the "admin" template, but not all, for example the permissions have their own "permission" template:

Having an "admin" template just makes it possible to assign a ProcessModule to this page. That means visiting this page via its URL calls the selected process module:

So, creating your own admin pages is really nothing else than creating a PW page with template "admin", creating a ProcessModule for it and assigning it to that page.

 

Have fun ?

[MarkE]

Thanks for the encouraging comments and the helpful suggestions.

2 hours ago, bernhard said:

I guess you mean you want to want to modify your data objects, right? So in PW this would mean your objects are pages, and your properties are fields. Classes would be templates,

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?

[MarkE]

3 minutes ago, MarkE said:

with a link back to the member page (and a link on the member page to it)

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.

[fbg13]

1 hour ago, MarkE said:

I'm not sure what the API would be to create a new page directly.

$p = new Page();
$p->template = 'template_name';
$p->parent = $pages->get('/about/');
$p->name = 'mynewpage_url';
$p->title = 'My New Page';
$p->save();

Edit the page

$p = $pages->get('/about/mynewpage_url/');
$p->title = 'My New Page (updated)';
$p->save();

 

[MarkE]

On 11/10/2018 at 7:39 PM, MarkE said:

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) [permissions for access to different admin pages]

Thanks for all the help. I'm still scratching my head over the above question, perhaps better explained by:

On 11/11/2018 at 2:03 PM, MarkE said:

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

Any ideas how to do this?

Thanks.

[fbg13]

@MarkE Have you seen the access tab on templates and fields?

https://processwire.com/api/user-access/ and maybe https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/

[MarkE]

Thanks @fbg13. I have seen those and have been building some process modules using the tutorial - which is working well. Am I to understand that I have to explicitly code the access rights into each process module using the API? I was hoping that PW would allow me to use the users-roles-permissions menu in the normal way.

[bernhard]

You can define access per template, per field, per module, per code block (then, yes, you have to write that one if() else() manually). The pw backend is just a pw application itself. Whatever you can do there is also possible in your own applications.

[MarkE]

20 minutes ago, bernhard said:

per module

Aha! I've worked out how to do that now, by adding the 'permission' item in the getModuleInfo array. I didn't see that in the tutorial ? , which is excellent BTW.

[fbg13]

You can get all fields of a page, that are editable by the current user, like this:

$p = wire("pages")->get(5994);
foreach ($p->getFields() as $pField) {
	foreach($p->getInputfields($pField->name) as $inputfield) {
		if(!$p->editable($inputfield->name, false)) {
			continue;
		};
		// need tracy debugger for bd
		bd("is editable: {$pField->name}");
	}
}

https://github.com/processwire/processwire/blob/96f62b313fca3f48df0521096145b782fa08c0e3/wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module#L815

https://github.com/processwire/processwire/blob/96f62b313fca3f48df0521096145b782fa08c0e3/wire/modules/PagePermissions.module#L118

[MarkE]

I'm starting to make some good progress with this. I'm seriously impressed with the PW API, but there is quite a lot to get to grips with. However the documentation (and support here ? ) is very good.

I've done some simple ProcessModules and that works well. Now I have a bit of a head scratch. My (partial and draft) class diagram looks like this:

New website design - class diagram.pdf

Ignore the colour coding for now. What I am trying to decide is how to implement the relationships. It seems to me that PW provides multiple options:

1. Parent-child
2. PageTable
3. PageRef - multiple select
4. Repeating PageRef fields

From what I can see, 4 doesn't offer any benefits over 3, which has a cleaner interface. PageTables look nice, but you can't add pages that already exist outside the table. (I saw @Macrura's post in 

on Nov 25, 2014, but I'm not clear where that code would go.

Is there some guidance as to what page relationship type to use where? What would others use for the classes in my diagram?

Also, a related issue: when is it best to just use the tree in the back end for admin tasks vs. using admin pages and Process Modules? It seems to me that the tree approach involves less coding, but requires a more tech-savvy user than a custom-coded admin page.

Thanks in anticipation of suggestions (and corrections of any misunderstandings on my part).

[MarkE]

Apologies - that was the wrong diagram attached in the previous post - this is the one I meant to attach:

New website class diagram -Lucidchart.pdf

[MarkE]

Just discovered FieldtypeRuntimeMarkup

So I can include PHP in the page edit - it doesn't have to be on an admin template page. Even more choices ?

(I'll shut up now and wait for a response)

[Robin S]

9 hours ago, MarkE said:

Is there some guidance as to what page relationship type to use where?

Personally speaking, when it comes to page relationships I use...

Page Reference fields: regularly
The Page Field Edit Links module can be very useful for creating new pages or editing pages directly from the field via a modal. And the AsmSelect inputfield option has support for modal page editing built-in. You might find the Connect Page Fields module useful for automatically creating two-way relationships.

Parent/child structure: sometimes, when it makes sense.

PageTable fields: rarely

[MarkE]

That's really helpful, thanks. I've had a play with these and they should work well together. I'm particularly impressed with

21 hours ago, Robin S said:

Connect Page Fields

- it will save a lot of PHP head-scratching.