With Dynamic Field Translations enabled, Product Duplicate runs until the PHP-FPM/Nginx timeout

[Martin Soluce]

Enabling Configuration → System Settings → General Settings → Localisation 

With Dynamic Field Translations enabled, Product Duplicate runs until the PHP-FPM/Nginx timeout.

PHP-FPM slowlog shows execution repeatedly inside WHMCS core classes: WHMCS\Language\Loader\DatabaseLoader, DynamicTranslation, Sanitize::purifyHtml(), and HTMLPurifier.

With it disabled, the exact same operation completes within seconds.
 

WHMCS Admin:
Configuration → System Settings → Products/Services
Action: Duplicate Product

Dynamic Field Translations ENABLED:
- request runs >300 seconds
- ends in 504 Gateway Timeout

Dynamic Field Translations DISABLED:
- same product duplicates within seconds

PHP-FPM slowlog:
script_filename = .../ordadmin/configproducts.php

Stack:
convertFromUTF8()
HTMLPurifier::purify()
WHMCS\Input\Sanitize::purifyHtml()
WHMCS\Language\DynamicTranslation::getTranslationAttribute()
WHMCS\Language\Loader\DatabaseLoader::load()
Symfony Translation\Translator...

[Waqas Ahmed Waseer]

Your slowlog pretty much tells the story. With Dynamic Field Translations on, every product field read goes through DynamicTranslation, which loads the stored translations and runs them through HTMLPurifier. A duplicate copies a lot of translatable fields (name, description, configurable options, custom fields), and from that trace it looks like it purifies the same translated HTML over and over. With long HTML descriptions or several languages that easily runs past 300 seconds. Since the same action takes seconds with the setting off, it's a core issue, not something in your Nginx or FPM config.

What I'd do while you wait for a fix:

1. Workaround: switch Dynamic Field Translations off under Localisation, duplicate the product, then switch it back on. The translations live in the database (tbldynamic_translations), so turning the setting off doesn't delete them, it just stops WHMCS reading them. Afterwards, check whether the new product picked up the translated name and description. If it didn't, add them on the copy by hand.

2. See how big the translation data is. Run SELECT COUNT(*) FROM tbldynamic_translations; and look at the size of the longest translation values. If you find thousands of rows, or descriptions with big pasted HTML (inline styles, base64 images), that's what HTMLPurifier is choking on. Cleaning up that HTML in the base language and the translations can bring the time down a lot. Take a DB backup before touching that table.

3. If you want to confirm it's slow rather than stuck, raise request_terminate_timeout in the pool and fastcgi_read_timeout in Nginx to something like 900 for one test run. If it eventually finishes, you know it's the per-field purification cost and not a loop.

4. Open a ticket with WHMCS support and attach that slowlog trace plus the two timings (more than 300s with the setting on, a few seconds with it off). That's an easy reproduction for them, and it's the only way it ends up in a maintenance release.