Calling FormLister from Blade on Evolution CMS 2.0.3

Calling classic snippets from Blade-based templates can expose two kinds of issues at once: old asset paths that no longer exist in the expected place, and parser assumptions inherited from pre-Blade integrations. the discussion for this article hit both with a single FormLister setup on Evolution CMS 2.0.3.

One error came from modxCaptcha looking for legacy noise images. The second came from FormLister.abstract.php expecting parser methods that were not available in that rendering path.

The original Blade call

{!! $modx->runSnippet('FormLister',[
  'formid' => 'basic',
  'captcha' => 'modxCaptcha',
  'errorClass' => 'has-error',
  'requiredClass' => 'has-warning',
  'subject' => 'New message',
  'formTpl' => '@B_CODE:<form class="jsForm row" method="post">...</form>'
]) !!}

What to check first

• verify that the captcha assets and noise images exist for the configured captcha driver
• test the same FormLister call without Blade-specific wrappers to isolate parser issues
• keep classic snippet templates in chunks when the parser path becomes unstable inside inline Blade code
• upgrade the package or integration layer if the snippet expects parser methods that changed between branches

Safer integration pattern

When you integrate an older extra in a Blade-based project, move as much of the snippet presentation as possible into chunks or dedicated templates. Let Blade handle layout, and let the extra render its own form markup through a stable snippet template. That reduces parser mismatches and keeps debugging simpler.

Why this article matters

This is a useful migration lesson for Evolution CMS 2.x and 3.x projects alike: not every classic snippet was written with Blade rendering in mind. If a package throws parser errors, check the rendering layer before assuming the business logic is broken.