MarkE

Thanks guys. I'll make a note not to include the cache folder in deployments.

Brief background: the live site is on a shared hosting service. I started developing on that but decided to continue it off-line. The development site is on W10 machine using Xampp. I had no significant trouble setting that up - importing the database using phpmyadmin. I then added a test environment on a Linux box (actually a Pi) running apache2 which is on the private network. I have done this (not with PW) a several times before and it has worked fine. So I exported and imported the database and copied over the files. After a few problems, I got everything running. However, I am getting one persistent warning, only in the test environment: Warning: touch(): Utime failed: Operation not permitted in /media/main/web/processwire/wire/core/FileCompiler.php on line 391 Any clues as to what is causing this?

That's really helpful, thanks. I've had a play with these and they should work well together. I'm particularly impressed with - it will save a lot of PHP head-scratching.

Just installed this and it looks good except that I am having difficulty adding new pages. I get this message: ProcessWire: ProcessPageAdd: Template Member is not allowed here (/members/) The settings I have used are parent = Members (i.e. url= /members/) and Template = Member. All the children of Members have template Member. If I deselect the Template = Member, the new page modal gives a choice of every template except Member. Am I being dim or what? The field is located on a completely different page (Memberships)

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)

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

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: Parent-child PageTable PageRef - multiple select 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).

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.

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.

Thanks for all the help. I'm still scratching my head over the above question, perhaps better explained by: Any ideas how to do this? Thanks.

Finally got it working after re-installing ProcessWire locally using Bitnami. With that installation (in xampp/apps/processwire) the url needs to be {domain name}/processwire not just {domain name}. The issue as to whether multi-site is a good idea or not remains. I guess if I have problems I can always split them onto different installations.

Having decided to migrate to PW (one at a time) most of the half-dozen sites I manage, I thought that a multi-site (option#1 in https://processwire.com/api/modules/multi-site-support/) installation would be best as I would only have to do one upgrade each time (as well as saving a little space). So I set that up on the hosting service I use (two sites initially) and downloaded everything to my local (Windows 10) machine. Locally, I use XAMPP and PhpStorm. I put the ProcessWire directory (with both sites and Wire) into htdocs. The site in the /site/ directory works fine using the localhost/processwire url, but whatever I try in the index.config.php file, I cannot get the second site to show - it always falls back to /site/ (because of the '*' => 'site', entry). Let's say the second site is in /site-new/ . How do I configure index.config.php to get that to launch locally? At the moment, my work-round is to change the name of the "catch-all" site to be whichever site I am working on, which is a bit clumsy. Or would I have been better not to go multi-site at all? Thanks for any insights.

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!