Embedding eForm Instances Inside DocLister Items Safely

Putting a form inside a listing is easy until every rendered instance starts sharing the same state.

This donor showed a practical pattern for embedding an eForm inside a DocLister output loop. The key idea was simple: every rendered form instance needs a unique identifier.

Example

[!eForm?
&formid=`designer-[+id+]`
&subject=`Request for "[+pagetitle+]"`
&tpl=`designerConsult`
&to=`[+tv.email+]`
&report=`designerReport`
&gotoid=`[*id*]`
!]

And in the form itself:

<input type="hidden" name="formid" value="designer-[+id+]" />

Why this matters

Without a unique formid, listed forms can overwrite each other’s state, validation, or submission context. Once a page contains several resources and each one renders its own consultation form, identifiers have to be per-item, not global.

General rule

Whenever you place forms inside loops, make every instance unique: form ID, visible DOM ID, and any hidden identifier the backend uses to distinguish submissions.

Newer post

Assigning Resource Aliases Automatically After Save in Evolution CMS

How to auto-assign a resource alias after the first save by using OnDocFormSave, and when that shortcut is useful for large editorial projects.

Older post

Enabling Captcha in JotX Comment Forms

A small but useful JotX configuration note: how to enable captcha in moderated comment flows to reduce automated spam on legacy Evo sites.