I got the IPB plugin to work, but have some questions... 1. When you setup the plugin should the message board login be pointed to the amember login? If not I have alot of other questions of how the expire thing works, because IPB is not subscription aware and what active process will check the exp date vs the current date, etc... 2. If use the login page for amember, does that set a cookie that automatically logs you into the IPB board or do you have to login again? I logged into the amember page with USERX and then went to the IPB board and it did not show me as logged in. 3. Should the IPB register link also be pointed to the amember signup.php file? Alot of this is grey area and is not covered very well... Thanks for any input.
I did find this in a pinned topic in the Plugin forum: Sounds the first option is what I am wanting, but again do I use the aMember login page or Invision? And if I use Invsion login then what process will check to see if the user subscription is expired or not? Invision is not aware of this, is there an include statement I put into the login function of Invision to check this?
The trick there is to create the default level of membership in Invision as one that gives as low a level of access as you do to non-members more or less. When a subscription expires, the access level of a previously paid-up member is changed to the default level. Thus as they expire members who previously had a level of membership associated with whatever product they bought, have that access automatically reduced. People can login using Invision, even if they are already logged in via amember they will still need to login to Invision.
Sounds like this is not a single login solution? New subscriptions are easy, the users are being created in both DB's... But if they only login through Invision what process is running that will change the access when the account expires? I will be using the default "validating" group and "members" group for security of reading etc... The "V" group is a teaser. They can see topic titles, but not read the contents of the posts. Still wondering
I suppose it is not really a single login situation - though maybe there is a way I am unaware of that can allow this. Once the account in aMember - which is keeping tabs on payments - expires they will automatically be returned to the default member level in Invision, in your case "Validating". It is immaterial whether they login to aMember or not. Though obviously they will need to login there to renew payment, and they will be able to so do still.
Yes but my question is.... "what" active process is going out and "expires" the user account? I could understand if there was some kind of include statment that was added to the invision login function. That every time some logs into the site it would check current date against user expire date and deal with it. There is not some service, exe, etc... that evertime the date flips, it goes and changes the security on users that are exipred. So it would have to be some type of php file that is called for also ran to check expire dates and do the work. Am I making any more sense? Yes, I know it's amember doing the work, but "how" is that work kicked off? By running what process? Login? Thanks
Think I answered my own question... I know enough about Unix, that this just hit me. Could this process be the CRON option? Like the following in the Admin / Config / Advanced: "Use External Cron" This would make more sense, because this process would run at X period of time every day, etc... This would be an "active" process to go out and deal with expired accounts. If so, this makes ALOT more sense. And would be what I was looking for to adjust the expired accounts.
The only way I could test this quickly was to go into the DB and update a record to have a expire date of today. Because if I did it through the amember admin it would disable the account. I set the expire date and ran the http://www.yousite.com/amember/cron.php?pass=password and tested the account and nothing had expired. I went to the admin console and the user should as active with an expire date of today. Of course when I hit save in the console it expired the user and updated the record... Any ideas?
You don't have to run cron - just set expiration date to YESTERDAY! and membership level of your customer will be downgraded to default (lets say "Guest" Level, which you have defined as Default level at aMember CP -> Setup -> Invision Board) aMember has internal cron and you won't be able to run it twice in a day. Instead, aMember handles changes in database instantly. Cron used only for expirations.
I had a user with an expire date of the July 25th. That user can still login to the IPB site with "member" access. It is supposed to move them to "Validating" when expired. I looked in amember admin console and it shows the user as "Active", but when you goto the details and the subscription option it shows it as "expired". If I hit OK there it will expire the user. So I did NOT hit OK to expire them and ran some more tests. Logged into amember with the user account and tried IPB again... The user still could login. Checked the admin console and had the same result... Account showed as "Active" but the subscription showed as "expired". Ran the CRON again and nothing changed... So I'm asking the question again... What "active" process is going out and checking the expire date vs the current date?
And I figure the email sending function for expiration, renewal will have the same issue. Don't know how else to explain it, but like this: aMember is a script and nothing else... What runs the script to check for user expiration, email renewal, etc...? aMember is not an active process, but must be "called" by something. Like a cron process that runs a .php scripit that would do the work above. First I have to figure out "what is being run" and then "is it being run". Then if it "is being run", "why is it not doing what is needed". Am I making sense here?
Neo, 1. When you change database records via admin interface, it call corresponding plugin hooks instantly. I hope it is not required to explain it in details. 2. If you have enabled "External Cron" in settings, you have to set cron job, which will call special URL once in a day. This URL will do several tasks. One from tasks is expiring user accounts and corresponding work. If you haven't enabled "External Cron" in settings, aMember has internal mechanics to handle it when it called by visitors. So, first visitor (which visit your site at 00:01 or later, will run cron job).
I ran the cron job and the user was set to expire. Must of screwed it up before, because I thought I had checked it. :unsure: That is what I was wanting to see... I am assuming that emailing of users within X number of days of expiration would occur during this same cron process? It would tend to make sense, but I'm asking for verification. Thanks