How a PHP config change and libary update eliminated every PDF failure on a 27-module SaaS

When I started working with THSP on their MyTHSP compliance platform, one of the first issues I heard about was PDF failures. Consultants in the field would try to generate a compliance report — a fire risk assessment, a COSHH record, a workplace inspection — and it would fail. Sometimes it worked fine. Sometimes it didn't. No consistent pattern, no clear error message presented to the user, just a broken workflow at the worst possible time.

This is the kind of bug that's easy to dismiss as a one-off. Until it happens again. And again.

What the platform was doing

MyTHSP is a custom PHP/MySQL SaaS application with 27 integrated compliance modules. One of its core functions is generating PDF reports for clients — structured documents covering everything from risk assessments to training records. These reports are built using mPDF, a PHP library that renders HTML/CSS into PDF output.

Some of these reports are simple. Others — particularly the multi-section assessments covering complex compliance areas — are substantial documents with tables, formatted content, and significant rendering work to do.

Finding the root cause

The first thing I did was check the PHP error logs. The failures weren't silent — they were generating errors, but the logging setup at the time was producing so much noise that the genuine issues were buried. Once I cleaned up the logging configuration to surface actionable errors clearly, the picture became much clearer.

The errors pointed to memory exhaustion. PHP was running out of memory mid-render on the more complex reports. The server's PHP memory limit had been set conservatively — well below what mPDF needed to process the most demanding document types. On simple reports, it was fine. On complex ones, it hit the ceiling and failed.

The fix was straightforward once diagnosed: increase the PHP memory limit to give mPDF the headroom it needed, and update the mPDF library itself — it was running an outdated version that had known memory efficiency improvements in later releases.

The result

PDF failures went to zero. Not reduced, eliminated. The consultants who had been hitting intermittent failures in the field stopped seeing them entirely. The fix had been a targeted PHP configuration change and a library update, but finding it required proper error logging, a systematic approach to diagnosis, and an understanding of how PHP memory management interacts with memory-intensive rendering tasks.

The wider lesson

A few things stand out from this that apply to most production PHP platforms:

• Conservative defaults are not always safe defaults. PHP's default memory limit is set for general-purpose use. If your application does anything memory-intensive — PDF generation, image processing, large data exports — you need to understand your actual requirements and configure accordingly.

• Noisy logging hides real problems. If your error logs are full of warnings and notices you've learned to ignore, you will miss the errors that actually matter. Getting logging right — suppressing noise, surfacing genuine issues — is infrastructure work that pays for itself immediately.

• Intermittent bugs are not random. When something fails sometimes but not always, there's always a reason. In this case it was report complexity driving memory usage past the limit. Finding the pattern is the job — and that requires being able to see what's actually happening on the server.

• Dependencies go out of date silently. The mPDF library had been running an old version for a long time. Nobody had noticed because the obvious functionality still worked. Outdated dependencies accumulate risk — security vulnerabilities, missing bug fixes, incompatibilities — and they're easy to overlook without regular maintenance.

Dealing with something similar?

If your PHP platform has intermittent failures that nobody's been able to pin down, or if you're running on infrastructure that hasn't been properly reviewed since it was first set up, it's worth taking a look. These issues rarely resolve themselves — and they tend to get worse as usage grows.

You can read more about the full scope of work we did for THSP in the MyTHSP platform support case study. Or if you'd like to talk through what's going on with your platform, get in touch — no jargon, no pressure, just a straight conversation about what you're dealing with.