MODX as basis for subscription-based website

[wpicotte]

By default, MODX supports one to many authors / editors contributing content to a website (i.e. a blog, corporate site, etc.) that acts as a hub for that content.

In contrast to this default set-up, is MODX is a good choice for supporting a subscription-based model, whereby subscribers access private data that is unique to them, utilizing site features available to all users, while the site is maintained and / or progressively enhanced as a single instance?

As a simple clarification, consider a website that provides financial budgeting tools. It exists as a single instance accessed by all users, thereby simplifying maintenance, progressive enhancements, etc. for the site owners, while allowing subscribers to store and access private data in order to utilize the site’s feature set.

In broad strokes (I don’t need detailed specifics), is this possible with MODX and if so, what would be involved?

P.S. I’m aware that content can be stored via media source using static TVs, but this will not adequately support the above example scenario.

P.S.S. Apologies for not having a more succinct way to describe the need - hopefully the example is clear, and also serves a clear contrast to how MODX is set up ‘out of the box’.

Thank you!

[nixitup]

My experiences with modx have been exceptional. Although I have not deployed it in the way you questioned, I do believe it could be utilized as such.

Hope someone with the experience can answer, but my response is biased. I love ModX! It’s so powerful and extendable I wouldn’t doubt that the software your competitors use is comparable.

[jaredfhealy]

This is definitely possible. I’ve built membership sites and paid applications on top of MODX. I think you could potentially utilize the MODX manager as well to deliver the content/experience or app. But, my experience is with building a front end app that is a paid membership.

You would use the MODX Login Extra to allow members to login / create a session with MODX.

You can then use resource groups to control access to any given resource, such as “PremiumContent” as a group. In this case it could be an application running on /app/ or specific content, articles, etc. Any resource in MODX can be added to the resource group.

By default, if anyone tries to access the page who is not logged in, they get sent to the “Error page” which by default is ID 1. There is also a setting for “Unauthorized page” which is defaulted to 1 that you could set to a specific page.

There is a little configuration around the resource groups. So, you may want to create a “GeneralMember” group with Load Only access policy to the protected content. This allows it to see that there is content there, then check the permissions, and redirect to the Unauthorized Page.

To further control the behavior, you could use a minimal Snippet to check authentication and display content based on that. So the resource itself is available to all authenticated users, maybe everything is under the GeneralMember group. Then rather than put the resource group for Premium on the resource, enforce it within the snippet.

[[!MemberCheck &general=`generalChunkTpl` &premium=`premiumChunkTpl`]]

Then the Snippet would have some logic around checking the group membership which is very easy. You would also likely check authentication first.

<?php
// Output to return
$output = $modx->getChunk($scriptProperties['general']);

// Check if they are not a member of the required group
if (!$modx->user->isMember('PremiumContent')) {
   $output = $modx->getChunk($scriptProperties['premium']);
}

// Don't forget to return the output
return $output;

I’ve found that MODX can handle about any scenario you want to throw at it with protected content from simple to very complex partial free partial protected or premium.

Hopefully that helps!

[wpicotte]

@jaredfhealy, thanks for the reply and details!

I’ll clarify my question slightly based on your response:

It’s not permissions I’m concerned with, though your ideas are all spot-on; some have been put into place on the site under development, including user groups and resource group access.

The larger issue seems to be related to how MODX stores user-contributed content and site components (chunks, TVs, permissions, etc) in the same database. Perhaps there’s a simple way to update only those portions that store site components, without affecting tables containing user content – I just don’t know what it is, or how degrees of scale may mean that user is stored altogether separately.

My personal experience is primarily with front-end development, hence I’m a pro at over-complicating backend concepts. The scenario I’m trying to describe () doesn’t seem to fit naturally with MODX’s “default” set-up, but I’m also sure that it’s possible.

[jaredfhealy]

I guess I may need a more specific example or concern.

One other feature I’ve used as a mechanism to separate content is the Contexts. This can be used to run a “Multi-site” instance where a subdomain or a sub directory serves up a different set of resources. You can also have separate settings and behavior per context from a resource perspective.

But, when you get into elements (chunks, snippets, templates). Those don’t seem to have that level of control around them. I haven’t dug into that as far. But it seems like if you grant access to Elements you are granting read write to all chunks, snippets, etc.

[wpicotte]

@jaredfhealy

But, when you get into elements (chunks, snippets, templates). Those don’t seem to have that level of control around them. I haven’t dug into that as far. But it seems like if you grant access to Elements you are granting read write to all chunks, snippets, etc.

I can try to clarify this way:

A site has 1,000 users (a nice, round number), each of whom submit content to the same set of components (chunks, TVs, etc.) that comprise the feature set of (for example) a financial budgeting website.

The content each user submits is private. In essence, you need a 1,000 instances of the site to service 1,000 users.

For many reasons, this isn’t feasible. The question then becomes how MODX can support this - or even whether it’s a good choice for doing so?

It seems obvious that content and components would need to be stored separately, thereby allowing progressive site enhancements without impact existing user data, but this isn’t the default MODX set-up.

[jaredfhealy]

Can you clarify what content type they would create? Would they actually create an Element (Chunk, TV definition, or template)? Or are they just creating resources or data that would be displayed within predefined Chunks, Templates, etc. So they would create a resource and populate TV values. But that doesn’t create TVs, it creates data rows related to the resource to store those values.

You can create ACLs that limit what contexts a user sees, what Categories they can see, thereby limiting the Templates they can select from. I’m not sure if 1000 contexts is any more practical though.

When you start to have that many people it sounds more like an application that you are selling access to, from there, you should likely isolate their data into a custom table within MODX. You could create your own component with tables to house budget data.

Like if you’re storing transactional data in MODX such as budget categories, and amount budgeted.

---

Updated:
Maybe what you’re asking is should the front end website be completely separate from the Membership area which is more like an application? I’ve typically kept those separate by using two separate MODX instances. So for instance:

1. https://budgetbetter.com
   • Main marketing site, content and details about the membership
2. https://app.budgetbetter.com
   • Separate MODX site that holds all the members, member data, etc.

This way you can change, update, backup etc. your main site without any fear of impacting the Membership/App MODX instance.

[wpicotte]

@jaredfhealy

When you start to have that many people it sounds more like an application that you are selling access to, from there, you should likely isolate their data into a custom table within MODX. You could create your own component with tables to house budget data.

Like if you’re storing transactional data in MODX such as budget categories, and amount budgeted.

Yes. A budgeting calculator is just an example, but thinking along the lines of an application sounds right.

In short, though, it also sounds like this one (website instance) to many (subscribers) paradigm is possible with MODX, using a non-generic database set-up.

[jaredfhealy]

Yes, definitely. I built an app where dental offices could sign up for access to a dental procedure library. So on sign up it would create a copy of the standard library specific to them. Then they could add, remove or modify steps in the procedure, upload images, etc.

Offices could use it as a training tool to confirm steps were completed. But you could theoretically have 100s of offices signed up. All their data was stored in a few custom tables and associated to their company. Each dental company could have multiple dental offices using the application.

[snowcreative]

@jaredfhealy

When you start to have that many people it sounds more like an application that you are selling access to, from there, you should likely isolate their data into a custom table within MODX

Exactly what I was thinking. I’ve created a number of websites with login access to stored user-specific data, even systems to open up access to certain pages after a user has completed certain tasks, for example.

[snowcreative]

@wpicotte

but this isn’t the default MODX set-up.

It’s sometimes useful to think of MODX as a framework, rather than a “system”. So, when you install MODX, you get a base setup (not really a “default setup” as you put it), upon which you can build whatever you want. Truly. There hasn’t been one single request from a client in the past 10 years that I haven’t been able to make happen in MODX.

[digitalpenguin]

I’ve built a subscription based MODX web app using Stripe’s “Billing” service before. I stored user data in a related custom table via extending modUser.

Stripe Billing: Manage subscriptions, recurring payments and billing

The downside to this is you’re limited to payments via Stripe (if that’s a deal-breaker for you).

I realise this probably won’t be relevant for the time frame of your current project, but at modmore we’re currently laying the groundwork for subscription based payments in Commerce. So once that’s complete, it’ll open the gates to having easy-to-setup subscription based MODX sites, that can accept payments through any of the supported methods.