Repository navigation
logs/images/add: a locked or unlimited memory_limit no longer refuses every image - #682
Merged
hxdimpf merged 1 commit intoOct 27, 2026
Conversation
…uses every image as 'too large (0 megapixels)' OKAPI raises memory_limit to 512M in init_internals() and estimates the processable image size from what is left. When the server doesn't allow the raise (php_admin_value), memory_limit stays at the server's value. At -1 (unlimited) the estimate became negative, and every image, however small, was refused as 'too large (0 megapixels)'. - An unlimited memory_limit counts as the 512M OKAPI asks for (huge images are still refused before GD runs out of memory). - An image that would fit into 512M but not into the server's limit is a server problem: the admins get a mail naming the limit and the fix, the client gets 'can't process images at the moment because of a server problem', not 'your image is too large'. - 'too large' shows the real size (one decimal, megapixels of 10^6).
hxdimpf
added a commit
to OpencachingDeutschland/okapi
that referenced
this pull request
Oct 27, 2026
Sync with opencaching/okapi: opencaching#682 (image uploads with a locked memory_limit)
This was referenced Oct 27, 2026
hxdimpf
added a commit
that referenced
this pull request
Nov 2, 2026
Entries in `etc/changes.xml` for the changes merged since the last changelog PR (#665) that matter to client developers or site admins: #649, #654, #646, #651, #682, #680, #666, #676, #672, #671, #667. Version numbers and times were filled in by `etc/update_changes.php`. #652 has no visible change for clients, so it has no entry.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #681.
logs/images/addestimates the processable image size frommemory_limit. When the server locksmemory_limit(php_admin_value), OKAPI's raise to 512M ininit_internals()has no effect; at-1the estimate was negative, and every image was refused as "too large (0 megapixels)". This happens on opencaching.de since a PHP update.Change (
services/logs/images/addonly):-1(unlimited) counts as the 512M OKAPI asks for, so huge images are still refused before GD runs out of the machine's memory.Okapi::mail_admins()(rate-limited as usual) names the limit, the memory in use and the fix (php_valueinstead ofphp_admin_value), and the client gets "%s can't process images at the moment because of a server problem. Please try again later or upload the image on the website." (new translatable string).No change for servers that let OKAPI raise the limit.
Tested on the dev VM, with the limit locked in the PHP-FPM pool:
memory_limit-1(– = not run with the old code.)
Suite (
--write): OCDE (opencaching.de website, currentdevelopment) 13 passed; OCPL on MariaDB 10.11 and 10.0: 18 passed each. PHP 8.2 lint OK.Merged right away as a bug fix (like #671 and #676): image uploads from apps are broken on opencaching.de until this or the server workaround is in place.