Jump to content
Pixrael

How to properly structure a complex membership system?

Recommended Posts

Hello, I'm building a website with a membership system that allows users to access different tools, each one has different configuration and data according to the user needs. I try to find the best approach to store that customized information in the PW tree, but I don't find any similar situation in the forum.

Ex. the context for each user could be like:

- Tool A
  - Settings
  - Recent results
  - Saved results

- Tool B
  - Settings
  - Saved results
  - Todo list

- Tool C
  - Settings
  - Working list
  - Related "Tool A" saved results

- Globals
  - Entries list (can be access from any tool)

As you can see is a complex interrelated system 😞 My ideas to record all this are:

- Option 1) Add a field to the user template, ex. Repeater matrix to record a JSON or YAML for each tool/task that the user access.

- Option 2) Add a field to the tool template (or to a tool child template) ex. Profield Table (in the tool context the fields are the same) and each row is for one user data.

- Option 3) Create a page tree apart, like "settings", the child template have a field JSON or YAML and 2 Page Reference fields, for tool-customer match.

- Option 3b) Same but different child templates, one for each data type to store, ex. Profield Table for todo/task list, JSON or YAML for settings, etc.

What do you think, some idea? Did your work with something like that before?

Please

PD: Due to the nature of the membership systems (users can in-out constantly) I suppose that is better a solution that can remove the user data from the system easily.

Share this post


Link to post
Share on other sites

@Pixrael here are some of my thoughts

I have worked with membership sites since 2001, after some fooling around I decided to go for amember.com for all the membership and payment stuff, it is a paid solution but as we all know nothing is free, you either pay someone for their work or put in the work yourself.

What I would do based on your setup is two things:

On the amember side I would specify 4 products: tool a, tool b, tool c and globals

Globals could be a product that can be accessed from any of the other products: tool a, b or c (can be easily set within amember)

On the processwire side of things I would just have a top level page, called tool a, also one for tool b etc and a globals thing that is added to all three tool pages.

Now I would add some php to the template of the tool a page template that calls on amember to check whether the user has access to this page.

Same for the other tool pages.

This way you separate the whole membership side of things, including payments etc to amember, a proven tool with a track record that goes back a long time and you use the brilliance of PW for what it does best.

The dabbling around within processwire of all the membership things, IMHO is just a waste of time, why re-invent the wheel when it is already running full on somewhere else and can be easily integrated. For integration I always use the programmers of amember who are available at reasonable fees to write the necessary code, or help you write it yourself.

Amember will take care of the payment side of things, recurring payments is no problem, when a user cancels payment, it automatically blocks access on content on pw pages, you could also allow access to old stuff which was made available until payment cancellation etc.

Just my 2 cents

Share this post


Link to post
Share on other sites

@OllieMackJames Just yesterday I was reviewing the amember.com website, I see it's a hosting solution to install on my server. Anyway this would be for the administration of accesses, permissions and payments (which is very interesting and I will try it for sure) but my problem now is how to save all the information of the tools (which is a lot) for each user to use internally in PW for calculations, analysis, etc.
Thank you very much for your answer

  • Like 1

Share this post


Link to post
Share on other sites

Short answer: RockFinder + RockGrid are exactly built for such tasks and RockTabulator is currently under development. You can PM me if you want to talk about possible collaboration/sponsoring/consulting.

  • Like 1

Share this post


Link to post
Share on other sites

I guess I would try option 3, but of course some more information about these "tasks" and "tools" would be needed.

Maybe I'd use JSON storage only for settings.

This module would perhaps be useful. 

  • Like 1

Share this post


Link to post
Share on other sites
41 minutes ago, dragan said:

I guess I would try option 3, but of course some more information about these "tasks" and "tools" would be needed.

Maybe I'd use JSON storage only for settings.

This module would perhaps be useful. 

Great idea! Thanks

Share this post


Link to post
Share on other sites

@ryan I know you are now traveling, but when you had some time I would like to know your opinion about this, maybe you have been in this situation before. If I implement the option 3, a simple calculation (as example) 5 tools with 3 different types of data to be stored by 3000 users would yield a total of approximately 45,000 pages only to store configurations and data lists, apart from the user's profile data. . it would be correct?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...