White Screen on "Modify Payments" in Batch Payments — Fix for Large Encounter Lists

Management and Administration
1

OpenEMR Version: 7.0.4 Server Environment: Ubuntu, Apache, PHP-FPM 8.2 Module Affected: Fees → Batch Payments → Edit/Modify Payments

The Problem

When attempting to allocate or modify a payment for a patient with a large number of charges/encounters, clicking Modify Payments results in a solid white screen with only the “Modify Payments” and “Finish Payments” buttons visible. The payment does not post and no allocation is written to the database.

This can also affect the initial batch payment posting — the payment session is created and the dollar amount is saved, but nothing is allocated to the encounters. The money sits in the Undistributed (red) field when the payment is later searched.

Root Cause

PHP has a default limit of 1,000 input variables per request (max_input_vars = 1000 in php.ini). When a patient has many charges and encounters displayed in the Batch Payment screen, the form submission exceeds this limit. PHP silently truncates the POST data, stripping critical variables including payment_id. Without payment_id, edit_payment.php cannot process the request and renders a blank page.

This was confirmed in the Apache error log:

PHP Warning: PHP Request Startup: Input variables exceeded 1000.
To increase the limit change max_input_vars in php.ini.

PHP Warning: Undefined array key "payment_id" in
/var/www/html/openemr/interface/billing/edit_payment.php on line 391

The Fix

Increase max_input_vars in your PHP-FPM php.ini file.

Step 1 — Identify your active PHP-FPM version:

bash

ps aux | grep php-fpm | grep master

Note the version (e.g., 8.2).

Step 2 — Back up your php.ini:

bash

sudo cp /etc/php/8.2/fpm/php.ini /etc/php/8.2/fpm/php.ini.bak.$(date +%F)

Step 3 — Increase max_input_vars:

bash

sudo sed -i 's/^;*max_input_vars.*/max_input_vars = 5000/' /etc/php/8.2/fpm/php.ini

Step 4 — Verify the change:

bash

grep "max_input_vars" /etc/php/8.2/fpm/php.ini

Should return: max_input_vars = 5000

Step 5 — Restart PHP-FPM:

bash

sudo systemctl restart php8.2-fpm

Result

After applying the fix, Modify Payments processes correctly for patients with large encounter lists and the white screen no longer occurs.

Notes

  • Adjust the PHP version number in the paths to match your server (8.2, 8.3, etc.)
  • If you run Apache with mod_php instead of PHP-FPM, the file to edit may be /etc/php/8.x/apache2/php.ini instead
  • A value of 5000 provides substantial headroom for even the largest patient encounter lists
  • This fix applies to all users hitting the same patient — it is a server-wide setting

Reported and resolved at NP Health Clinic, Lumberton TX. Running OpenEMR 7.0.4 on Ubuntu with Apache + PHP-FPM 8.2.

1 Like
2

confirmed this appears to still be an issue in OpenEMR 8 and opened a ticket for it in github.

1 Like
3

Yes, there’s several things that should always be tweaked in the php.ini for a working OpenEMR install.

max_input_vars , as discussed here, should be bumped up to at least 5000, and sometimes 10000 or more is necessary.

date.timezone - Make sure your local time zone is set correctly, this should also be checked for your SQL back end (MySQL or MariaDB)

upload_max_filesize - most linux distros default this to 2MB, which is quite small, adjust to your needs, if the practice needs to upload scanned PDF files, you’re storing data from diagnostic or imaging devices, it might need to be as much as 256MB, or even larger.

post_max_size - related to above, this value may need to be adjusted upwards for sending data to your OpenEMR instance from client browsers.

max_execution_time , max_input_time, memory_limit - All 3 of these may need to be adjusted upward from the relatively low default values, but be careful not to set them too high, or it leaves the potential for certain activities to tie up huge amounts of server resources for long periods of time. If you’re experiencing log file errors relating to PHP running out of memory, adjust the memory_limit value upward by 64M to 128M at a time until the error is resolved. Don’t just bump it up to an unnecessarily large value like 2G in order to clear the error.

mysqli.allow_local_infile - this value needs to be set to “On’“ in order for the system to be able to load data from source files on disk, like ICD-10 code updates, RxNorm or SNOMED source data, etc. There is some risk to leaving it enabled, but remember to turn it On when doing external data loads.

error_reporting - the default OpenEMR application code throws a lot of information into the log files if the default error reporting settings in PHP are enabled. This can make it difficult to troubleshoot when you’re diagnosing a specific problem. Suppressing Warnings & Notices will help make it easier to when you have to put eyeballs on the file and look for things.