CBSubs membership plan disappears after unsubscribing

Hello,

I noticed an issue with CBSubs:

I have a "free membership" plan which users are subscribed to by default when creating an account. Users who already had an account prior to the introduction of this free plan simply had no subscription and have at all times the ability to subscribe to the free plan.

In addition, I have a few paid plans to which users can upgrade if they want. When the upgrade expires after 1 or 2 years, they are reverted back to the free plan.

Everything has been working well so far, until a user on the free plan brought up the problem of not being able to access a URL that is restricted with "folder access" with all plans (including the free one, so only without any plan subscription it's not possible to access that URL). The user did subscribe to the "free membership" plan and should have been able to access the URL.

Unable to figure out what could have caused this (with my test account, it worked), I decided to try to unsubscribe the user from the "free membership" plan, and then resubscribing (in the backend, CB user management). That is when I discovered the issue that the "free membership" plan disappeared!

The plan is still visible when I look at CBSubs plans, and all other subscribed members of that plan are still subscribed to it. However, when I look at the list of plans in the "upgrade" tab of the user's account in the backend, the "free membership" plan is simply not there!

Next, I tried to make a copy of the "free membership" plan. The copied version does show up, but when subscribing and then unsubscribing, it also disappears. I am unable to remove the copied version of the plan, because CBSubs keeps saying there is a user still subscribed to it, even though I unsubscribed that user. Since the plan does not appear listed in the user's profile, I am unable to try unsubscribing/removing that user from it again.

The problem is not restricted to that user only. I tried to do the same with a test account of mine, and the issue appears there as well. When I try to access the "free membership" plan's direct link front-end when logged in with the test account, it simply shows nothing.

I already looked at the settings of the plan, but I can't find any setting that could cause this. Did I overlook something, or could this be a bug?

Thanks!

Bit of an update:

Through CBSubs > Subscriptions I was able to add the user's account and my test account back to the "free membership" plan. After that, I was able to remove the copy of the plan.

When I try to upgrade my test account to a higher plan now, and then unsubscribe, they are reverted back to the free plan as it should be.

However, the problem with folder access is still not resolved. It appears that the ht-files aren't being written/updated. Even when I create a new test folder with restriction, within the Joomla directory, no htaccess or password files are being created.

I tried both absolute and joomla type for path, but it keeps saying "No path defined yet. Please define then apply setting to get result of check."

Users that had already been added to the access in the past, can still access it with their username and password. New users apparently can't. This is weird, because it worked in the past and I haven't changed anything to it as far as I am aware. allow_url_fopen is enabled.

If your free plan is a lifetime plan ensure free lifetime plans are configured to create subscriptions within CBSubs > Settings > Global (this really needs to become the default at some point).

Regarding CBSubs Folder Access it looks like you've configured it to use Absolute pathing. Are you intending on using a path outside of Joomla? That can be a bit tricky when it comes to proper permissions as generally the site won't have permission to do anything outside of Joomla root. Typically I recommend just using a sub-folder of /images (e.g. /images/files) then setting Type to Joomla.

Hello,

The setting "Create Subscriptions also for free lifetime plans" is indeed set to "yes".

In regards to the folder access: yes, the folde is located outside of Joomla, and it never gave me issues in the past.

Not that I have an issue with moving it inside the Joomla folder, if that would resolve the issue. Unfortunately, that's not the case: I created a test map (without anything in it) within Joomla's path, configured it in the CBSubs plan and tested it to see if a htaccess and password file would be created in that folder. But nothing happened.

In regards to the folder access: yes, the folde is located outside of Joomla, and it never gave me issues in the past.

There's no guarantee external folder access won't be lost by permission changes on the server.

Unfortunately, that's not the case: I created a test map (without anything in it) within Joomla's path, configured it in the CBSubs plan and tested it to see if a htaccess and password file would be created in that folder. But nothing happened.

Subscriptions trigger the creation of the htaccess and htpasswd files. It does not create them on plan save. Once you've set the Type to Joomla ensure the Path is set correctly (e.g. /images/files) then subscribe a user to the plan (could be your own user just to generate the files).

In addition to this is there a particular reason you need to use old list directory usage to access files? A download manager would be significantly easier to protect with CBSubs and significantly easier for your users. For example CB Gallery could even be used for managing files or CB Package Builder. Both can be protected with CBSubs perfectly fine with CB Package Builder having a specific integration for doing so.

Does that mean I have to subscribe a test user first, and then navigate with that test user to the protected folder?
I assumed that it was enough that the test user was already subscribed, and only had to log in and navigate to that folder.

The reason why I'm using the folder access is because the folder contains a wiki. In the past, this wiki was simply open to the public, but aggressive bots kept indexing the wiki (despite robots.txt asking not to) and causing a heavy strain on the server frequently, due to the fact that a Wiki has many links.