Blog Sections Open
Fixing eForm #LIST Validation Errors When a Select Field Is Filled by JavaScript
A troubleshooting guide for eForm select fields that look correct in the browser but fail server-side validation because the options were added only on the client.
eForm can validate a select field successfully only if the server knows which values are valid. That is why JavaScript-driven selects sometimes fail with the classic error:
Error: #LIST rule declared but no list values supplied: #LIST
In the donor case, the select existed in the markup, but its options were injected dynamically with JavaScript and even hidden in the initial layout. From the browser’s point of view the field looked populated. From the server’s point of view the allowed value list never existed.
Why this happens
- eForm validates against the rules defined server-side.
- Client-side option injection does not automatically update that rule set.
- A visually correct select can still be invalid at validation time.
Practical fix
Define the accepted values on the server or transform the dynamic field into a validation flow the backend understands. If the select must be built with JavaScript, then the same allowed values need to be known to the server before validation runs.
This is a useful reminder that frontend behavior and backend validation are two separate contracts. eForm will only trust the second one.
Diagnosing config.inc.php Corruption After an Evolution CMS Update
How to troubleshoot broken manager behavior caused by corrupted or partially overwritten config.inc.php data after an Evolution CMS update.
Cleaning Up Ditto Pagination URLs by Removing ?start=0
How to remove redundant ?start=0 pagination URLs from Ditto output to keep Evolution CMS listing pages cleaner for users and search engines.