The solution that the CB team figured out for me was to have a hidden cbsubs plan that cost $0 and had public access. This plan was then associated with the the user group in question. So this plan was not visible to users, but because it was now connected with the user group - the user group was now 'seen' by cbsubs. The plan need to have public access, but disabled for "allow registrations", "allow new subscriptions", and "allow upgrades." (From Paid Subscriptions>Plans on the grid)

Recently (last week or so) my client site is now experiencing this issue. The setup is as follows:

A new user registers for a Paid Child Plan. They correctly get sent a verification email. They click on the link and are taken to PayPal. If they pay, then everything is fine. If for example they refresh the session page, or do not proceed at that moment, then they are blocked the next time they try. If the Administrator unblocks them they get blocked immediately when they next try to log in.

Site is running CB1.9.1, CBSubs GPL 3.0, J2.5.19. CB is set for all registrations to require Admin Approval.

When the user registers they ARE given two groups, REGISTERED and the PLAN Group (the latter clearly ONLY after a successful Payment). However, at this stage they are only set as Registered so I cannot see how the additional groups are affecting this issue. This is a recent issue on a relatively stable live site. The only most recent change activity may have been the Joomla upgrade from J2.5.18. I have checked ACL assets and fixed any orpahn or missing ones (none related to CB/Subs), so these are not related either.


Currently the ONLY manual ways round it are:

1) is to make them a member of a separate FREE Plan (at same level as the Parent of the Paid Plan) which just gives them Registered access, and then unblock them manually. They can then Login and upgrade to the Paid plan via Subscriptions tab.

2) To set CB NOT to require Admin Approval for registrations. This however then creates a problem for the Membership manager as the user is allowed access before being verified as a valid/qualified member.


I tried to create a free hidden plan (as per this an another thread) set to user group "Registered" but this made no difference. I then tried the user group to the "paid access level", and still the issue persists.

I then thought it may be related to the PayPal cart expiring before their next attempt (e.g the user did not click on activation tab for longer than the 3 hr default). I changed this to 24hrs but it made no difference.

Is this the same issue as reported in this thread or something different?

[ADDED: Sometimes they do not get the message but a blank page but the browser path is as follows: ../component/comprofiler/pluginclass?plugin=cbpaidsubscriptions&cbpaccount=expired&user=3251

Is there any reason why this would appear to be occurring now to more users? As, over the past years I don't recall users experiencing this problem. Would the PayPal Baske t timing out be associated?

Hi! I have implemented this solution on our site and it works OK.

A hided SBCUB-plan for each access group that we uses under the group "Registred ( in out case Editor and Publisher)

Our settings for each plan:

Tab Pricing
Regular Price of plan = 0
Renewable in advance by = None
Regular Validity duration = Lifetime

Tab Workflows
Allow registration = No
Allow upgrade to this = No

Tab access
Publicerad = Yes
Allow new subscriptions = No
Allow access from site frontend = No
Visible for Access Level = Public
Visible for Group (and above this group) = Publisher
User Group = Publisher

A question is if Tab Pricing setting "Regular Validity duration" = Lifetime is needed?
What happens if the hided plan expires at the same time as the regular plans (eg New Year for uss)?