My "Free Registration" option isn't selectable on new user registration

Thanks much for your follow-up and suggestions.

So assume I were to reconfigure the parent/child relationships for my plans, moving it to your recommended structure where most Plans are at the top level:

"Free Membership" (exclusive) ... the default account for new users.

Sponsor (exclusive) ... and hidden

- Gold Sponsor (non-exclusive) ... and hidden, except for Sponsor

Institution (exclusive) ... and hidden

- Gold Institution (non-exclusive) ... and hidden, except for Institution

Subscriber (exclusive) ... visible during registration, and an Upgrade option in the Profile

- Gold Subscriber (non-exclusive) ... visible during registration, and an Upgrade option in the Profile


How would reconfiguring parents for existing Plans affect their existing subscriptions or users? Will there be any issues if I move things around? Would this change the automatic "fall back" relationship already working, say, when a Subscriber subscription expires, it automatically reverts to Free Membership?

Nearly all of my users are currently in the Free Membership category, so it wouldn't be the end of the world if I had to migrate Sponsors, Institutions, Subscribers, etc. (Preferred not to do this, of course.)

I think part of my confusion about configuration needs were that I assumed that a CBSubs plan would need to have a Parent-Child relationship in order to allow for this automatically "promotion"/upgrade and falling back to the original Plan. I didn't realize they could all be listed at the same level, but still have specific promotion/demotion relationships not related to the Plan parent/child hierarchy.

Thanks again. I'll wait to see what you say about any "gotchas" and what you might recommend.

OK, after thinking about all of this, and looking over your replies and the documentation again, I'm going to start by moving my Subscriber and Gold Subscriber plans to the top level.

My schema calls for no user to be able to simultaneously be subscribed to more than one plan. However, my "Institution" and "Sponsor" tiers are invitation-only ... I pull entities into these plans from an existing Free Membership, then I send them the link with the Plan in the basket.

I didn't get an answer yet about the consequences of changing Plan parent/child hierarchy for Plans with currently active subscriptions; I'm going to try this out for Plans with small numbers of subscribers and then test ...

I'd note that your statement that "Exclusive = Mandatory" regarding Parent/Child Plan relationships is the first I've seen this stated anywhere in CBSubs, its documentation or support materials. This is the thing that screwed me up: After reading all the documentation admonishments about carefully planning my Plan setup, I thought that building a hierarchy would add more versatility ... and didn't realize this would require that the "parent" plan be subscribed at the same time as the "child" plan. It also wasn't clear that this was just a two-tier system (versus Joomla's standard of unlimited tiers/subcategories).

Perhaps you can consider adding some material toward this in your next round of documentation. (Those Joomla 1.5 graphics are getting pretty long in the tooth, too.) There are a number of places where Plan structure and planning is addressed, but perhaps some ideas for "guidance" or best practices can also be introduced.

For example, encouraging people to keep things simple and start out with one level, more explicitly explaining that a Parent plan must also be subscribed when a Child plan is selected, and also discussing the relationship between "upgrading" and "falling back" to an original subscription plan ... I assumed that the Parent/Child Plan hierarchy was part of defining this relationship. and didn't understand it was a different process.

I think, too, especially since this concept overlaps with how Joomla User Groups can be set up in a hierarchy, it's confusing, because there's a natural tendency to assume similar operations for a similar type of thing. Perhaps the documentation can explicitly state how CBSubs' hierarchy and promotion/demotion exists as its own system, and how plan promotion/demotion works.

This is just some feedback: I'm loving the product overall, and it delivers a very high value. I think polishing up some of the support materials (including things like "best practices for configuration") could go a long way toward helping users and making CBSubs even better.

I'll report back with progress. Thanks!

OK, I now see the Tool Tip on Edit Plan > Parent Plan, which refers to the mandatory nature of the parent-child relationship. So it is mentioned: Sorry I overlooked it!

I've gotten some of the functionality I'm seeking by going with the following schema:

Free Membership (exclusive, default plan, lifetime, visible at registration)
-- Institution (non-exclusive, hidden, child of Free Membership)
-- Sponsoring Institution (non-exclusive, hidden, child of Free Membership)
-- Sponsor (non-exclusive, hidden, child of Free Membership)
-- Gold Sponsor (non-exclusive, hidden, child of Free Membership)
Subscriber (exclusive, visible at registration and upgradeable in profile)
Gold Subscriber (exclusive, visible at registration and upgradeable in profile)

Before moving the Subscriber and Gold Subscriber plans to the Top of the hierarchy, I manually demoted the couple accounts assigned to them to Free Membership (deleting their Subscriber subscription), then manually re-assigned the Subscriber subscription from the back end for these accounts after I moved its Plan to Top of the hierarchy.

I wanted to confirm expected account behavior for Subscriber and Gold Subscriber expirations, especially when these are selected at registration: When these expire, will they still automatically "fall back" to the default Free Membership subscription?

Also, I'd ideally want institution and sponsor accounts to be parent/child plans as you suggested:
Institution (top level, exclusive, hidden)
-- Sponsoring Institution (child, non-exclusive, visible to Institutions)
Sponsor (top level, exclusive, hidden)
-- Gold Sponsor (child, non-exclusive, visible to Sponsor)

Given that there are a number of Sponsor and Institution accounts, I likely don't want to move their plan hierarchies around while accounts are associated with them, no? Is it best to migrate users to a different Plan (e.g. revert to Free Membership), delete all of the Plan subscription records for each affected account, change the hierarchy of the Plan, and then reassign the members to it)?

Because both Institutions and Sponsors require direct touch when signing up (for qualification et al), the hierarchy we have is working and will work. But I think I'd like to get everything set up properly now, so I don't paint myself into any more corners.

If you have any feedback or suggestions about Plan (and subscriber users) migration/changes, please let me know. Thanks!

Moving plans out of their parent will impact existing subscriptions. You'll need to edit the _cbsubs_subscriptions database table and change parent_plan column to the new parent plan id. If it has no parent (root plan) set this to 0. Re-assigning the subscription also works of course.

I wanted to confirm expected account behavior for Subscriber and Gold Subscriber expirations, especially when these are selected at registration: When these expire, will they still automatically "fall back" to the default Free Membership subscription?

If they upgraded from the free membership and it has time remaining on it then yes they should.

The most simple plan structure I can suggest based off your needs is the following.

Free (exclusive)
Sponsor (exclusive)
- Gold Sponsor (non-exclusive)
Institution (exclusive)
- Gold Institution (non-exclusive)
Subscriber (exclusive)
- Gold Subscriber (non-exclusive)

Is there a reason you need to parent them all to the free plan? The above structure avoids needing to use conditions or any further checks to limit plan combinations as it'll just work right out of the box. Parenting them does allow inheriting access permissions, but complicates everything else for your usage.

So I'm finally getting back to this response. Why the long delay? After the fixes, CBSubs is working great, and I've been super busy working on my website, which is now starting to generate revenue, thanks to your great software.

However, I did want to reply to this about how I went down this road, and to suggest making some changes and improvements to your documentation.

Actually, it was the scary nature of the documentation that made me make the wrong decision to add more complexity than I needed. The section of documentation explaining Plans (e.g. 7.5.7) really should also explain what the Parent>Child relationship is intended to support.

I mistakenly assumed that this Parent>Child relationship tied into how members would have their Plan status "fall back" to the parent: I assumed that a Plan needed to be a Child of another in order for this to take place. But I've now learned that a separate process manages how Plans are promoted/demoted through subscriptions, expiry, etc.

The documentation for Plans (or the documentation in general) should explain this better, I think, to prevent confusion. I think the documentation should also encourage users to start with only one level of Plan to keep things simple, and explain exactly what the Plan parent>child relationship does or does not do.

It is now my understanding that Plan parent>child is more for enabling a "variant" option when a member has to choose one or more selections from the parent plan.

For example, say you want to be a "Superhero" (parent plan). But you can't be just a generic superhero: You have to choose to be either Batman (child of "Superhero," exclusive), Spiderman (child of "Superhero," exclusive), or Wonder Woman (child of "Superhero," exclusive).

Or for example, say you want to be a "Superhero" (parent plan), and you have to choose at least one superpower: You can choose "Flight" (child of "Superhero," non-exclusive) and/or "X-Ray Vision" (child of "Superhero," non-exclusive) and/or "Invisibility" (child of "Superhero," non-exclusive).

So parent>child in Plans seems to be more about forcing a choice among variants for members, and it does not have anything to do with the back-end mechanics of plan adoption/promotion/demotion, etc. Do I now understand it correctly?

This was confusing also in terms of how Joomla handles inheritance of permissions et al in ACL and User Groups ... I figured the same type of thing was being enabled in CBSubs, as it said no different.

I'd recommend you consider adding some more information to your documentation about Plans for your next documentation release. Feel free to use any of the above if useful.

This took me a while to figure out, but it is now working well, thanks to both your great product and your timely and helpful support. Thanks so much for the assistance: I'm implementing subscription systems for my online news outlet that match or beat the technology of big, mainstream media publishers and newspapers.