Ngsymfonytools Laravel Package

Getting Started

This is an eZ Publish 4 (legacy) extension, not a modern Composer library. You install it by dropping it into extension/ and activating it — there is no composer require path that will do anything useful on its own.

Prerequisites

• eZ Publish 4.4+ legacy stack (the kernel that runs .tpl templates and fetch()).
• A Symfony 2 HttpKernel wired into the same process (this extension was built for Netgen's eZ Publish 4 + Symfony 2 integration; it is not a standalone bridge to Symfony 3/4/5).
• PHP 5.x-era runtime and Twig 1.x. Do not expect this to run cleanly on modern PHP/Twig without patching.

Minimal install

git clone https://github.com/netgen/ngsymfonytools extension/ngsymfonytools

Activate it in settings/override/site.ini.append.php:

[ExtensionSettings]
ActiveExtensions[]=ngsymfonytools

Then regenerate autoloads and clear caches (both sides matter — legacy and Symfony):

php bin/php/ezpgenerateautoloads.php
php bin/php/ezcache.php --clear-all --purge

Where to look first

1. The extension's settings/ngsymfonytools.ini (and any .append.php override) — this is where template paths, Twig environment options, and sub-request settings live. Read the shipped INI before writing any override.
2. classes/ and autoloads/ — the template operators are registered here; confirm the exact operator names against the source rather than trusting blog posts (historically these are ngsymfonytools_render_twig and ngsymfonytools_subrequest).
3. ezinfo.php / README — version compatibility notes.

First use case

The intended first use is "replace one chunk of legacy markup with a Twig partial." Put a Twig template in the path configured in ngsymfonytools.ini, then call the render operator from a legacy template:

{def $data = hash(
    'title', $node.name|wash(),
    'items', fetch('content', 'list', hash('parent_node_id', $node.node_id))
)}
{ngsymfonytools_render_twig('AcmeSiteBundle:Parts:teaser.html.twig', $data)}

<section class="teaser">
    <h2>{{ title }}</h2>
    <ul>
        {% for item in items %}
            <li>{{ item.name }}</li>
        {% endfor %}
    </ul>
</section>

If that renders, the environment is wired correctly and you can start scaling the pattern.

Implementation Patterns

Treat it as a migration seam, not a replacement engine

The strongest day-to-day pattern is incremental: keep the legacy pagelayout and fetch() logic, and carve out leaf components (teasers, widgets, forms, search results) as Twig templates or Symfony sub-requests. Page assembly stays in eZ; presentation moves to Twig one component at a time. This is also the lowest-risk way to introduce it into an existing site.

Explicit data handoff is the contract

Nothing is shared implicitly. Build a hash() in the legacy template, hand it to the operator, and let Twig consume named keys. Keep the shape flat and serializable — no passing content objects whose methods you then call from Twig with assumptions about the legacy attribute API. If you need rich objects, convert them in PHP (a small helper/extension function) rather than in the template.

Sub-requests for controller-backed components

Use the sub-request operator when the component already has real logic behind it (a Symfony controller, a service, form handling) and you do not want to duplicate that in legacy fetch() calls:

{ngsymfonytools_subrequest('acme_search', hash('q', $search_string))}

Keep sub-requests at the "one per page region" level. Each one is a full kernel round-trip through the Symfony stack, so putting them inside a foreach over a content list is a performance trap.

Configuration over hardcoding

Drive template locations and any Twig option flags through ngsymfonytools.ini.append.php in settings/override/ or per siteaccess, not by editing the shipped INI. That keeps the extension directory updatable and lets staging/production diverge only in configuration.

Debugging workflow

When an operator call silently renders nothing:

1. Check that the extension is in ActiveExtensions for the current siteaccess — eZ merges site.ini across overrides.
2. Regenerate autoloads after any file added to classes/;
3. Clear the legacy template cache and the Twig cache — they are separate and both can serve stale output;
4. Tail var/log/error.log (legacy) and the Symfony log — exceptions from Twig or the kernel surface there, not in the browser.

Extension points

The realistic extension points are the Symfony side: register Twig extensions/functions through your bundle's service configuration, and add helper operators by following the pattern in the extension's classes/. Anything you add there should be treated as a fork you maintain, given the package's age.

Gotchas and Tips

• It is effectively unmaintained. Last release was 2015, eZ Publish 4 is EOL, and Twig 1.x is out of support. Pin PHP and Twig versions in your environment; do not plan an upgrade path through this package. If you are on eZ Publish 5+/Ibexa, you do not need it — Twig is already native.
• Two caches, two failure modes. Legacy .tpl compilation and Twig compilation are independent. A change to a Twig template that "doesn't show up" is usually the legacy view cache holding the rendered fragment; a broken Twig template may keep serving the last good compiled version until the Twig cache is cleared.
• Operator names are not guaranteed by documentation. Confirm against autoloads/ in the checked-out version before writing templates; operator registration is the most common reason a copied example throws "unknown operator."
• Escaping boundaries. Twig autoescaping applies inside Twig, but output emitted by the operator into the legacy template is not re-escaped by eZ. Keep |wash() on values you pass in where they originate from user or content data, and let Twig handle output escaping.
• Sub-request context loss. A sub-request created from a legacy template often does not inherit the full original request context (locale, base URL, authenticated user details) unless your integration explicitly forwards it. Test locale- and permission-sensitive components specifically.
• Exception behavior is ugly. An uncaught exception in Twig or the sub-request kernel typically degrades to a blank region or a broken page rather than a clean error. Wrap risky component renders during development and watch the logs.
• Avoid loops of sub-requests. One sub-request per region is fine; N sub-requests for an N-item list will dominate your page time. For lists, fetch in legacy/PHP once and pass the data into a Twig partial instead.
• Session and request-stack duplication. Sub-requests run through the kernel again; code that mutates the session or assumes it is the master request can behave unexpectedly. Keep sub-request controllers read-only where possible.
• Siteaccess awareness. INI overrides and active extensions can differ per siteaccess — verify behavior in the actual siteaccess you are debugging, not just the default one.