A PHP file always runs (WordPress back end as well as front end) which has below things in it –
A script whose job is to check auction status(scheduled, live, expired) for each auction and then take appropriate actions like move scheduled auctions to live, live to expired based upon their scheduled and expiry time respectively.
An another script takes all the expired auctions among all the auctions which then checks their meta data to conclude if email for a particular auction is already sent. If sent, then skip them or send email.
In the above approach, no cron was implemented because of following two factors
The WP cron does not give the result smoothly, it is highly dependent upon the page visit on the site. Whereas if we keep all the requests on page visits (without cron), it will at least give latest result as compared to the page visit in case of WP cron.
The system cron is good to go but not suitable for the s/w which which will be served as a plugin where the it will be installed on different servers. We did not want to make the process too cumbersome where the users need to configure some cron through their cPanel or ssh.
Challenges with above implementation:
The above approach was fine for a specific set of no. of requests. But, it was being failed if no. of requests were not manageable by the server config (memory, cpu, mysql). So, we had to overcome this situation by better optimizing the plugin (by new architecture and code).
The auctions are checked again and again until the emails are sent for them. The major problem happens because of this when email functionality is doesn’t work on a site. In that case, since no emails are sent, the auctions are rechecked till emails are send for them.
New Implementation in PRO version 5.0.0
We have now 2 cron jobs for auctions update and emails implemented using ‘Action Scheduler’: check auction status, update them and send email for won auctions.
We have a new DB architecture in the system to queue the requests and then process them periodically. We now maintain some custom tables where we store the reference of each auction, so that we make query to only this much record instead of making query to entire WP post table unlike earlier implementation.
Only specific no. of auctions will be processed instead of all and that too on interval basis.
The auctions for which the emails were not sent were never be checked in future and remove from queue. The user can then resend the email for those auctions from manage auctions pages after configuring their email setup. Also, the new email test feature alert user beforehand to configure the emails set up properly.
New configuratin in PRO 5.0.0
Cron settings: One best thing about this implementation is that we are not keeping a default interval for cron processing and no. of auctions/requests to handle when a cron runs once but we are making the whole process more flexible by providing you a configuration. You can find more instructions at right on the main settings page of the plugin.
Email test: To make users aware that mail functionality is working on his/her site, we have added a new feature for email test (wp_mail()), so that they should first correct/configure their email setup and then create/manage auctions.
There can be many scenarios but I’ll explain with just one example here –
You have 100 auctions which will be expired in next 1 hour.
You set interval for auction status update and email sending as 2 mins and 4 mins respectively.
You set no. of auctions to process as 25 and 20 respectively.
Now, below things will happen –
Both the crons will run as per their schedule. The first one will take 25 auctions which are going to end soon and check each of them if they can be moved from scheduled to live or live to expired and update them accordingly.
Similarly, email expiry cron will perform as per its schedule for 20 auctions.
By this way, within each 6 minutes, only 70 auctions are being checked.