MLSImport runs on the WordPress schedule, and WordPress only checks its schedule when someone loads a page. On a site with steady traffic that is fine. On a new site, a staging site, or one with quiet nights, it means the hourly sync and the daily cleanup fire late or not at all.
A real server cron fixes it by driving the schedule on a clock instead of on visitors.
What has to run
Two scheduled events do the work that matters, and both are ordinary WordPress cron events.
event_mls_import_auto, hourly. Checks each import task with auto update enabled for listings changed in the last two hours and updates them. A missed hour is not recovered later.mlsimport_reconciliation_event, daily. Compares your site against the full MLS feed and removes listings that should no longer be there.
A third event, mlsimport_daily_telemetry_event, runs daily and only reports usage. It has no effect on your listings.
Imports themselves are queued through Action Scheduler, which also depends on the WordPress schedule. That is why a site with broken cron shows all three symptoms at once: imports that never finish, listings that never update, and old listings that are never removed.
The recommended setup
Run the schedule through WP-CLI. It executes in the shell, so no web server request timeout applies, which matters because a single import action can legitimately run for many minutes.
- Add
define('DISABLE_WP_CRON', true);towp-config.php, so page views stop trying to run the schedule as well. - Add a system cron entry that runs due events every five minutes:
*/5 * * * * wp cron event run --due-now --path=/path/to/wordpress - Add a second command in the same entry to work the import queue:
*/5 * * * * wp action-scheduler run --path=/path/to/wordpress - Wrap both in a lock so runs cannot pile up on each other:
flock -n /tmp/mlsimport-cron.lock -c 'wp cron event run --due-now --path=/path/to/wordpress'
Most managed hosts have WP-CLI available on the account. Ask your host if you are not sure, and ask them to add the entries if you have no shell access.
The lock is not optional on a site with large imports. Without it, a five minute schedule starts a second runner while the first is still working through a task, and two runners updating the same properties produce database deadlocks.
If WP-CLI is not available
The fallback is a system cron that requests wp-cron.php over HTTP every five minutes:
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron >/dev/nullKnow its limit before relying on it. That request goes through your web server, so it is subject to the same request timeout as any page. On stacks that cap requests at 300 seconds, a long import is killed at 300 seconds whether a visitor triggered it or your cron did. It keeps the hourly sync and the daily cleanup honest, and it does not rescue an import that is too large for the host.
Keep the schedule steady
Whatever method you choose, run it consistently. The hourly sync asks the MLS for listings changed in the last two hours, so a schedule that skips several hours leaves a gap that no later run fills. If a gap happens, run each import task manually once to bring the site current.
After adding server cron, confirm it worked rather than assuming. Install WP Crontrol, open Tools, then Cron Events, and search for mls. Both events should be listed with a next run time in the near future.
Frequently asked questions
The Tools tab mentions a URL ending in mlsimport_cron=yes. Should I use that?
No. That URL does not start a sync of its own: requesting it writes a line to the server cron log and nothing else. Any listings that do get updated when you call it are updated because the request is an ordinary page view, and a page view is what makes WordPress check its own schedule. Drive the WordPress schedule itself with one of the methods above, since that is what both plugin events are registered on. If you have already added a cron entry for that URL, replace it rather than adding to it.
Is five minutes too often?
No. A run with nothing due exits almost immediately, so the cost is negligible. Checking often is what keeps an hourly event close to hourly, since a schedule checked once an hour drifts.
Do I still need DISABLE_WP_CRON if my host already added a cron job?
Yes, if that job drives the schedule. Leaving both active means page views and your cron entry can start runs at the same time, which is exactly the overlap the lock is there to prevent.
Will server cron make my imports faster?
It makes them start on time and, through WP-CLI, lets them run without a web request timeout. It does not make your server process listings faster, so a task too large for the host still needs splitting into narrower tasks.
Related
- Cron not working: a checklist
- Checking that auto update is running
- How the hourly auto update works
- How daily reconciliation works
Send us your host name and whether WP-CLI is available, and we will write the exact cron entry for your setup.