Scheduled Events

There are two types of Scheduled Event in MCM. 1) Checking Offers with expiry/reactivation dates and enabling or disabling these accordingly; 2) Send out emails to members who have opted in to receive updates about recent Offers/Wants.

There are two ways Scheduled Events can be triggered.

You can set up a system CRON if your server or CPanel account allows for this. The CRON would then ensure that the RunScheduledEvents script is executed regularly at the specified time. Setting it to run once a day in the early hours of morning is suggested.

Here is an example line of code you could use for your CRON, which uses curl on the server to execute the script (be sure to replace YOUR-WEBSITE-URL with your domain, and PASSWORD with the 'unattended' system password which is defined in your main config file with the variable $config['unattendedPassword']):

curl -X POST https://www.YOUR-WEBSITE-URL/run-scheduled-events -d 'password=PASSWORD'

If you prefer not to use a CRON, the system will decide when is the next appropriate time to execute the RunScheduledEvents script. Each time a page is requested a check is performed to see if the script was last run more than 24 hours ago; if it was then the system runs it and updates the timestamp accordingly.

You can tell the system you are not using a CRON and therefore instruct it to perform this check by setting the following in your config file

$config['useCRONForScheduledEvents'] = false;

.

Not using a Cron is the simpler option but comes with the disadvantages of a) putting a small additional load on the server for each page request, and b) not guaranteeing the RunScheduledEvents script will be run within a particular timeframe (that is, if no-one visits your site for a day, the script will not get triggered until the next page request).

The RunScheduledEvents Script first verifies the Unattended password passed to it (note; if not using a cron, the system will take care of passing the unattended password for you). Then it checks if you have the Admin setting 'enableEmailUpdates' set to On, and runs the processEmailUpdates() function if it is. Then it checks if you have the Admin setting 'enableOfferScheduling' set to On, and runs the following two functions if it is: processExpiringOffers() and processOfferReactivations().

Here are the 'algorithms' for each of the scheduled events functions to give you an idea of the logic flow used for each element:

- Get all Members who are not set to 'inactive' and who have elected to receive email updates - IF Members are found:

1. Loop through list of Members, and for each one:
   1. Get the timestamp of the last Update Email they were sent
   2. Calculate the number of days that have elapsed since the last Update Email, and if this is higher than or equal to their Email Update Frequency preference:
      1. Fetch all Offers and Wants that were added or updated since their last Update Email, and use these to build the content of the Update Email
      2. If at least 1 Offer/Want is found, proceed to send the Email Update and adjust the timestamp of their last sent email accordingly

- Fetch all Offers/Wants with an expiry date set to less than or equal to now - Loop through the Offers/Wants and for each:

1. Deactivate the Offer/Want

- Fetch all currently inactive Offers/Wants with a reactivation date set to less than or equal to now - Loop through the Offers/Wants and for each:

1. Activate the Offer/Want