An import that adds exactly 25 listings, sits in progress for a while and then fails has not hit a limit inside MLSImport. It has completed the first page of results and then had its process stopped by the server.
MLSImport has no 25 listing limit. Twenty five is the number of listings in one request to the MLS, and an import task is a run of many of those requests inside a single background process.
What is actually happening
Starting an import queues one background job. That job then loops: fetch 25 listings, write them, free memory, fetch the next 25, and so on until the task’s target is reached. All of it happens inside one PHP process.
If the server stops that process part way through, everything already written stays. Nothing restarts it, so the task is left marked as started, and the scheduled action that was running it is eventually recorded as failed. The symptom you see is the count frozen at whatever the last completed page reached.
The number it stopped at is the diagnosis. A multiple of 25 means whole pages completed and the process died in the gap between them, which is almost always the execution time limit. A number that is not a multiple of 25 means it died while writing a page, which points at memory instead.
What to check
- The execution time limit. Ask your host what the maximum run time for a PHP process is on your plan, and whether it can be raised. Some platforms enforce a ceiling that overrides the value in your control panel.
- WordPress cron. If
DISABLE_WP_CRONis set inwp-config.php, the background job depends entirely on a server cron that has to be configured correctly and run often enough. - Failed scheduled actions. Look under Tools, then Scheduled Actions, for the MLSImport job and read its status.
- The import log. Turn logging on from the Tools tab, run the import again, and read the last line. It names the batch it reached and the memory in use at that point.
The PHP error log is often empty in these cases, and that is expected. A process that is killed does not raise a PHP error, so an empty log is evidence rather than a dead end.
What works while you sort the hosting out
Split the feed across several import tasks so each one finishes well inside whatever limit the server allows. Filters are what divide it: by status, by city, by property type, by price band, by agent or office.
Splitting is not a workaround you have to feel bad about. Multiple import tasks are the normal way to run a large feed, and the hourly sync handles them all.
Split on a filter that produces stable, non overlapping groups, such as city or property type. Splitting on price bands works until a listing changes price and moves between two tasks, and splitting by “how many properties to import” does not divide the feed at all, because each run starts again from the beginning of the same result set.
When the environment cannot be adjusted
Across several SiteGround cases we saw the same pattern on different themes and different PHP versions: the first 25 listings imported, the task stayed in progress, then it failed, with nothing useful in the PHP log. Where no server side change resolved it, the customers who solved it did so by moving hosting.
That is not a statement that MLSImport cannot run on SiteGround. It is what the reviewed cases showed, and it is why the recommendation is to test the same site on another environment rather than keep tuning import settings that are not the cause.
Frequently asked questions
Can I make the batch size smaller than 25?
No. The page size is fixed in the plugin. Making the task smaller is done with filters, not with the batch size.
Why does the task say Processing for so long before it fails?
The job it was running has already stopped, and the queue only marks an action as failed once it has been in progress for longer than it should be. The delay is the queue noticing, not the import still trying.
Does the hourly sync have the same problem?
It can. The hourly sync processes every task flagged for auto update inside one run, so a server that cannot finish one manual import will struggle with a sync covering several tasks.
Will re-running the import continue where it stopped?
It starts from the beginning of the result set, and listings already imported are updated rather than duplicated, so nothing breaks. It does not pick up where it left off.
Related
- Memory, batch size and large imports
- WP Engine and the platform execution limit
- Hosting requirements and recommendations
- Cron not working: a checklist
- Turning on logging and reading the log files
Send us today’s import log and the number the run stopped at and we will tell you which limit you hit.