Hi,
I am experiencing a major regression with large Excel exports in PHPMaker 2026.
I need to export around 50,000 to 100,000 rows to Excel. The built-in XLS export does not work reliably for this volume. In older versions (PHPMaker 2020–2024) this scenario worked much better.
In PHPMaker 2025, I created a custom extension that overrides the default native Excel export and uses OpenSpout to generate XLSX files. That solution worked well: performance was acceptable and memory usage on the server remained under control.
In PHPMaker 2026, the same customization no longer behaves as expected. Large exports are much slower, and in most cases the request eventually ends with 500 Internal Server Error.
After comparing the generated projects from PHPMaker 2025 and PHPMaker 2026, the problem does not seem to be related to:
-
the underlying database table, which is the same in both versions
-
the XLSX writer library itself, since the custom exporter still uses OpenSpout correctly
-
missing PHP dependencies, because the required Composer packages are installed and autoloaded properly
The main difference appears to be the export pipeline generated by PHPMaker 2026.
Observed behavior in PHPMaker 2025
-
the custom export override is reached early in the export process
-
export behaves more like a result-set / streaming flow
-
the override is able to improve performance effectively
Observed behavior in PHPMaker 2026
-
export is routed through the
/api/export/...pipeline -
the generated flow appears to be more container/service-driven
-
before the custom XLSX writer is reached, PHPMaker already spends significant time preparing export rows
-
records seem to be loaded into arrays first, then processed row by row through the standard rendering logic
-
this rendering step repeatedly resolves lookup/display values for fields such as
user table -
as a result, most of the execution time is spent before the custom Excel writer even starts
In my tests, the custom debug log inside ExportExcelNativeFast was not even created during the slow/failing runs. This strongly suggests that the request is stalling or failing before the override actually begins writing the XLSX file.
Because of this, in PHPMaker 2026 the bottleneck no longer seems to be the XLSX writing phase itself, but the earlier export preparation/rendering phase. Due to this architectural difference, the same override strategy that worked in PHPMaker 2025 is no longer sufficient in PHPMaker 2026.
There is also a secondary issue: when the export fails with HTTP 500, the UI tries to show the error using toast components with inline styles, and those styles are blocked by CSP. However, this seems to be only a side effect of the export failure, not the root cause.
Summary
-
the same table and use case work well in PHPMaker 2025
-
the same custom override no longer gives the same results in PHPMaker 2026
-
the likely reason is that PHPMaker 2026 performs much more row preparation and lookup rendering before the custom exporter is reached
My conclusion is that PHPMaker 2026 changed the export execution flow in a way that makes the previous override pattern ineffective for large Excel exports.
Has anyone else seen this behavior in PHPMaker 2026?
Is there a recommended way to bypass or optimize the row preparation/rendering stage for large custom Excel exports?
Thanks