We’re using the Mapping module to show about 2600 items each of which have a single point location. Unfortunately we just get a white screen in the browser and the server error log shows that PHP has hit its default memory limit of 128M. Before I put in request to our sysadmins to increase the limit, I wonder whether there is any guidance on how much memory to allow?
Even so, suppose half of the 128MB is overhead, and 64MB is being used by Mapping, that means that if I am running out of memory for 2500 objects, each point is taking more than 27K. It could be quite a lot more, as I do not know how many of the objects it processed before running out of memory.
That amount of memory seems way out of proportion, and suggests that there are some inefficiencies in there.
I see that the pop-ups for the markers appear direct in the page that hosts the map, as <div> elements. For example:
Some map interfaces handle the pop-ups with a Javascript call to populate the block on demand, which can improve page loading times. But each of those takes about 500 bytes, so it still does not explain why a point takes in excess of 27K.
I don’t want to sound like I am complaining about a very useful module: one which certainly attracted us to Omeka. But I do not want to have to go back to the sysadmins repeatedly to get the limit increase, or risk their criticism if I ask for a limit which is way over the odds!
The browser shows no response from the server: it’s getting nothing back at all.
In the error log there are lots of lines like this (I have added line breaks for readability)
[Tue Dec 16 08:37:17.492213 2025] [proxy_fcgi:error] [pid 720955:tid 720955] [client 10.0.153.63:0] AH01071: Got error ‘PHP message: Doctrine\ORM\ORMInvalidArgumentException: Binding entities to query parameters only allowed for entities that have an identifier. in /var/www/caxton.durham.ac.uk/omeka-s/vendor/doctrine/orm/lib/Doctrine/ORM/ORMInvalidArgumentException.php:202\n
Stack trace:\n #0 /var/www/caxton.durham.ac.uk/omeka-s/vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php(435): Doctrine\ORM\ORMInvalidArgumentException::invalidIdentifierBindingEntity()\n #1 /var/www/caxton.durham.ac.uk/omeka-s/vendor/doctrine/orm/lib/Doctrine/ORM/Query.php(456): Doctrine\ORM\AbstractQuery->processParameterValue()\n #2 /var/www/caxton.durham.ac.uk/omeka-s/vendor/doctrine/orm/lib/Doctrine/ORM/Query.php(400): Doctrine\ORM\Query->resolveParameterValue()\n #3 /var/www/caxton.durham.ac.uk/omeka-s/vendor/doctrine/orm/lib/Doctrine/ORM/Query.php(316): Doctrine\ORM\Query->processParameterMappings()\n #4 /var/www/caxton.durham.ac.uk/omeka-s/vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php(1181): Doctrine\ORM\Query->_doExecute()\n #5 /var/ww…’
and then at the end we have the out of memory error:
[Tue Dec 16 08:37:59.054685 2025] [proxy_fcgi:error] [pid 720142:tid 720142] [client 10.0.153.63:0] AH01071: Got error ‘PHP message: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32768 bytes) in /var/www/caxton.durham.ac.uk/omeka-s/modules/Mapping/view/common/mapping-feature-popup.phtml on line 1PHP message: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 831488 bytes) in Unknown on line 0’, referer: https://caxton.durham.ac.uk/omeka-s/
I wonder, does the mapping module have to load the complete item into memory, in order to have all the fields available to create the HTML for the pop-up <div>? If so, perhaps it does not free that memory till the end of the process, meaning it has to have 2500 complete items in memory at once? Just an idea. Not that the items have very much data to them individually, in our case.
Just to note our experience with both ‘old’ and ‘new’ mapping for reference. We have 10,000 points on our front page which Leaflet handles effortlessly, it’s just the load time that’s an issue.
With Mapping 2.0 which executed the query before the page load it would take a minute to load the page (we had a high memory limit set). We wrote our own custom map block that only outputs the Point coords and the Item number, and have a custom pop-up that calls the API for the Item data to display only when a pin is clicked. This saves sending a lot of unnecessary data and loads in about 3 seconds.
Mapping 2.1 loads the page first, then executes the query via the API. I’ve been holding off the 2.1 upgrade due to lack of time, but this week I tested it and it actually took up to 3.5 minutes to load the query after page load and locked the page while it did. I need to dig deeper as to why this is.
For now, I’ve adapted our map block to the 2.1 internal API changes, but still preload the stub data and then fetch the Item data on click. When I get time I’ll try adopt the post-load data query method with limited return data to get that load time down again.
It would be great if something like this could be incorporated into the core module. The changes in Mapping 2.1 seem to have been sufficient to reduce the memory requirement, which is something. Our current use case only has about 2600 items, but we are certain to need higher numbers of points in future projects.
I’m surprised that you’re experiencing such long load times in version 2.1. After page load, a script iteratively fetches and loads feature data (GeoJSON), and individual popup content is loaded when the user clicks on a feature. This way the page loads data only when needed. This optimization seems similar to your custom implementation.