I am back to update this and finally close this thread as it has been resolved after some testing. I will leave a detailed summary for my own future reference and for other people who may find this helpful.
But first:
“The subscription expiration and activation determines the role that the user has” – this is exactly what I wanted, so that when the subscription expires, the user loses the user role that came with the subscription and have to purchase the subscription again in order to get access to whatever that user role gives them access to, eg a menu button, and now that I got it working, it is exactly what is happening.
Thank you @alexandrubodea very much for your help!
Here is the summary:
A lot of people want a way to allocate a user a single user role when they register, and charge for this process. The default method with Paid Membership Subscription (PMS) is that, you create a virtual subscription product that a user can pay for to have. When a user buys the subscription, they will become a registered user of your site. You set it so that the subscription allocates the user a wordpress user role (you can set the role to anything you want), then, when the user buys the subscription, the user will gain that user role. The issue for some of us is that PMS allocates a user the role the subscription is set to allocate, but the user also gains the wordpress default user role as well, meaning they get 2 user roles. This is an issue if we use methods that give permission to users based only on their user role – so we want PMS to give the purchasers a single user role only.
That is where the code at the start of this thread comes in: As of WordPress version 6.6.2 and PMS version 2.12.9, this code will make the user gain only one user role, and that is the user role the subscription gives them. When the subscription expires*, the purchased user role will be lost, and the user will get the site’s default user role.
*When the subscription expires depends on the chron job setting of your site (hosting back end), which “checks” something as often as you set it (eg once per minute, hour, day, month). This took some posts in support threads here and questioning with my hosting provider to find out. Ultimately, I had to wait for a while for the time to run out naturally due to complicated issues I won’t discuss here. Basically: the cron job needs to be set so it is in sync with the unit of time your subscriptions is set to expire/work in. Eg: if your subscription is valid for and expires after 1 DAY(S), like day passes on some sites, then your chron job probably needs to run every minute so it can check every minute whether exactly 24 hours have passed. If it is set to run once every 24 hours, then you could have a situation where the subscription runs a full 23 hours and 59 minutes longer than you intend it to, causing some people to lose subscription revenue (eg: if it is set to run once every 24 hours at 12 am midnight, but a user signs up for a day pass one minute later at 12:01am, they will get access right away, but the cron job won’t check for new registrations until the next 12am exactly, which is 23 hours and 59 minutes later. Then, the user will be given the 24 hour/1 day access they purchased, so they will get 23 hours and 59 minutes plus the 24 hours they purchased, leading to a total of 47 hours and 59 minutes. So initially when I checked back after 24 hours (for testing purposes I set it to 1 day’s subscription as opposed to 30 day’s subscription), none of the purchased subscriptions expired and the user never lost their role.
