[Assigned] Maps cache rebuild too slow

[Author]

Posts

[Warren Chandler]

For some reason, over the past few days the website ( hidden link ) using Maps has been painfully slow. The autosuggest took 3 seconds or more to load location suggestions and the map pins were missing.

For example, this page only shows 15 pins since the rebuild started 24 hours ago, when there should be 41. -- hidden link

After checking, it appeared the cache data for maps was incomplete.

However, trying to rebuild the cache is not really working. It shows:

"890 missing cache entries found. 1 cache entries processed. Remaining cache entries will be processed automatically using cron."

After a day, only a handful of new entries have been processed, around 1 per hour. The site is a live site that relies on these maps, so I need to know how to populate the cache with the new entries at a much faster rate. They certainly can't wait 890 hours (37 days) for their site to be working properly.

I'd appreciate any help you can give to speed this up. The client can't have a non-working site for over a month.

Kind regards
Warren

[Christopher Amirian]

Hello,

With OpenStreetMap, the rebuild processes one address per run. If an address can't be found, the next run waits one hour.

After each successful address, the queue starts again from the top. So a few addresses that can't be found can hold up everything behind them.

To speed it up, please add this code in Toolset > Settings > Custom Code and activate it:

<?php
add_action( 'toolset_maps_cache_cron_hook', function () {
	if ( time() > strtotime( '2026-11-12' ) ) {
		return;
	}
	$next = wp_next_scheduled( 'toolset_maps_cache_cron_hook' );
	if ( $next && $next - time() > 60 ) {
		wp_clear_scheduled_hook( 'toolset_maps_cache_cron_hook' );
		wp_schedule_single_event( time() + 20, 'toolset_maps_cache_cron_hook' );
	}
}, 99 );

It keeps the rebuild running every 20 seconds, even after a failed address. 890 addresses should take around 5 hours. It stops by itself on November 12, and you can remove it after that.

When it finishes, click "Check for missing cache entries" in Toolset > Settings > Maps. Any addresses still missing are ones the service can't find, so they need editing, for example to the town and postcode.

Could you also tell me if WP-Cron is disabled on this site and replaced by a server cron? If that cron runs hourly, the code above will not help and it needs to run more often.

The custom code suggested above is not part of our official support policy. We will not be able to maintain or guarantee that it will work. It is an attempt to help you understand what should be done for scenarios where the built-in Toolset features are not there to handle your request.

Thanks.

[Warren Chandler]

Thank you. I added the code, but the problem persists. WP CRON is enabled and seems to work in every other instance.

Originally I was using Nominatim, but many addresses returned no data, especially for partial addresses... []

I switched to Photon to see if that helped, and the partial data was better in returning cache entries, but it was STILL at 1 per hour. What should have taken 5 hours has taken 3 days and only processed 144 entries, so naturally my client is not happy.

I've now deleted the cache again and will report back to you.

Appreciate the help!

[Christopher Amirian]

Hi,

Thanks. The issue has already been reported to the development team. I will get back to you as soon as I have news.

Thanks.

[Warren Chandler]

Thanks Christopher.

I think I have found the issue which may help others in a similar situation.

The site had over 1,000 entries that were originally created in the cache database by Google maps.

Switching to OpenStreetMaps seemed to keep the Google cache entries in the database with the co-ordinates for the pins. The site still functioned find at this point.

However, upon seeing the message in the Dashboard I believe one of the admins switched from Nominatim to Photon to see what would happen.

( "Toolset Maps: OpenStreetMap geocoding now uses Photon, which understands partially typed addresses. It powers both the address autocomplete and the addresses your site geocodes in the background. Your site relays the requests, so the service never sees your visitors. The public Photon server is a free community service with a fair-use expectation; a busy site should host its own instance. You can switch back to Nominatim or set your own server URL in the Maps settings." )

This emptied the cache.

When the cache was trying to rebuild, the addresses used to generate pins successfully using Google maps weren't being found by OSM. For example:

West Titchberry Farm, Hartland, Bideford, UK works fine on Google maps, but didn't generate co-ordinates from OSM. The response came back as [ ] .

Only after I removed the "UK" part from that address or added "England" instead of "UK" did it give any suggestions and once I saved the address using that new address it generated the cache entry as it should.

I found this by displaying the response in the PHP error log which for a correctly found location showed:

[12-Nov-2026 03:15:32 UTC] [PHOTON DEBUG] Address: Anglesey AONB, Holyhead, Isle of Anglesey, UK | HTTP: 200 | Results: 1 | Response length: 545

... and for an address not found showed:

[12-Nov-2026 03:15:40 UTC] [PHOTON DEBUG] Address: 1 Mill Lane, Tregony, Truro, Cornwall TR2 5RX, UK | HTTP: 200 | Results: 0 | Response length: 42

Unfortunately, most addresses were not found and after each not found response the "Rebuild cache entries" reverted to just looking for one entry an hour later after the failure and stopped again if the next address was not found.

As far as I can tell, that's the issue. Once they had fixed 100 addresses in their database, those got cached correctly and quickly using the script that was provided in this thread, until it got to the next failed response, which then delayed the cache again.

** SO IN SUMMARY **

They still have 800 addresses to update, but at least the issue seems to have been located. It's not so much a Toolset issue though workarounds need to be in place, but is more a limitation of OSM which does not read the original Google Maps addresses easily.