5

Access Expiration Options

In DAP 4.7, we have added a new feature to the hourly dap cron where once every day (it’s hardcoded to run ONCE between 10:00 PM – 11:00 PM PDT) the cron will look for users whose access expired that day.

You can configure the Cancellation Options in DAP Products page -> Cancellation & Expiration tab.

Then based on these settings, the DAP Hourly Cron will check if the current time is between 10:00 – 11:00 pm PDT (Server time), and if yes, it will take a look at each product, pick up the ‘Expiration Action’ setting for that product, then get a list of ALL users whose access to that product has expired and apply the ‘Expiration Action’ to that user->product record in DAP users -> manage page.

The reason the DAP Cron checks the current time and runs the ‘expiration job’ only once a day is because running it too often will burden your server/resources as this job needs to pick up all products and then apply the cancellation rule to all users whose access has expired.

The main thing is to make sure it only runs once.. does not matter if that’s between 10 – 11 or 11 – 12 etc. We just picked the time to be between 10 – 11 PM (server time).

1) No Action

User’s access will auto-expire at the end of current recurring cycle. If the user re-signs, they will start from where they left off instead of starting over at day 1.
Infact this is how all older versions of dap already work.

If a user cancelled access to a subscription product before and say that the same user now wants to start back after a couple of months break.
If you have selected NO ACTION as this product’s expiration setting (in dap products page -> cancellation & expiration tab),
then when the user re-signs, they will start their dripping from where they left off and will not start fresh again from day 1.

Say a user’s access start date is 07/01/2014 and access end date is 07/30/2014, when the cron runs on 07/31/2012
and finds the user’s access has expired, it wont do anything.

If the same user re-signs for the same product on 08/30/2014 using the same email id, their access start date will be what it was before (07/01/2014) and their new access end date will simply be extended from what it was before. It will be set to previous access end date (07/30) + 30 days instead of new signup date (08/30) + 30 days. User’s access to product will remain expired. You will have to set post-expiry access to “Y” in dap setup->config page for access to ‘paid-for content’.

See this for more details: Cancellation

2) Remove From Product

If selected, dap will automatically find users whose access to this product has expired and remove user’s access to product completely for those users.
You will need this setting to prevent access for expired users. Users will completely lose access to product.
If these users signs up again, they will start over like a new member.

3) Set end date to previous day

To enable this option, you will have to first enter the following in /dap/dap-config.php file.

Please ftp to your site, find dap-config.php file, edit it and add this to your /dap/dap-config.php file:

Add it towards the top after php start tag (<?php) :

if(!defined(‘EXPIREACCESS’)) define(‘EXPIREACCESS’,’Y’);

IMPORTANT:  Replace all occurrences of backticks in the line above with single or double quote character.

Then upload back to your site (under dap folder).

We are forcing the dap-config.php setup in DAP 4.7 so users do not pick this option by mistake. We also want this feature to be BETA tested fully (in DAP 4.7) and then we will remove the extra steps (to add lines to the dap-config.php).(

After you set this in dap-config.php, this dropdown option will be available in the ‘expiration action’ dropdown.

If you pick this option for a product, then DAP CRON will automatically find a list of expired users (whose access has expired to this product) nightly and move the expired user’s access start and end day (set the access end date to the previous date).

When the cron wakes up and runs this job once once every night at 10:00 PM, it will move the user’s access start / end date forward in such a way that user’s access will remain expired but the access end date will not be stuck somewhere in past. It will be always set to the previous date (from current date).

Say a user’s access start date is 07/15/2014 and access end date is 08/15/2014.

When the cron runs on 08/16/2014 and finds the user’s access has expired, it will set the access end date to previous date.

So first time when the cron runs after the user’s access expires, nothing will happen. The access end date will remain 08/15 as it’s already set to previous date.

When cron runs on 8/17, it will move forward the the access start and access end window, so the new access start date will be 07/16 (moved forward by 1 day) and end date will be 8/16 (moved forward by 1 day).

This way the user’s access is still expired (as it’s always set to previous date) but the access dates are not stuck in the past.

If they re-sign, when DAP extends access, the access end date will be in the future instead of being expired.

If the cancelled user re-signs, the user’s access will not remain expired as their access will be extended from the current access end date to a date in future and the dripping will continue from where they left off.

IMPORTANT:  ADDITIONAL INFORMATION

1)  EXPIRATION: SET ACCESS TO PREVIOUS DATE

We recommend that you enable this option ON a test product first. DO NOT use this option on an actual live product. Add a few test users to the test product. Move their access start/end date manually to a date in the past .Make a note of it. Enable the admin option to ‘move date to previous date’ for this product. Then run the cron manually. Go back to dap manage users page and check the new access start / end dates for these users. If all looks good, then use it for live products.

2) CRON JOB:

The dap cron (dap-cron.php) runs once every hour at the top of the hour… but it will only do the expiration job between 10- 11 PM (server time). The expiration part of the cron only executes once a day.

To force run the cron, run this command in a browser (dont run cron too close to the top of the hour as it will collide with the normal running of cron ).

http://yoursite.com/dap/dap-cron.php?forcerun=Y (replace yoursite.com with the name of your site)

 

Click Here to Leave a Comment Below 5 comments
Kyle - February 6, 2013

If we choose ‘2) Remove From Product’ for the expiry action, will that call any plugins we have specified to be called upon product removal?

Reply
Veena Prashanth - February 12, 2013

No, it will not call any plugins upon removal. The removal is limited to dap and completely internal to dap currently.

Reply
Patty Newbold - April 29, 2013

We chose option 1 (No action) and set post-expiry access to “Y.” Users have access to the protected posts they paid for, but [DAP has_access_to…] does not display protected content on pages to post-expiry users. Is there a way to continue to display this content to them without making it public?

Reply
Veena Prashanth - May 5, 2013

Hi Patty,

Are you on LiveLinks 1.8.3.2? If not, please upgrade to dap 4.4.3 / LL 1.8.3.2 and has_access_to should work in the dap shortcode. If user’s access to product has expired but post-expiry access is set to “Y.”, then [DAP has_access_to…] should display content to these users.

Thanks,
Veena

Reply
Patty Newbold - May 5, 2013

I am using those versions. Will try some more testing this week.

As it happens, my typo in the comment (has_access_to instead of hasAccessTo) works fine for the expired user (as does the default isLoggedIn=”Y”), but does not exclude users of other products who are logged in, which is what I need.

Reply

Leave a Reply: