Using BlockChain

The same pattern works for a data-grid cell: the admin theme provides the wrapper, while the application theme customizes the value:

{# admin_theme.html.twig #}
{% extends 'admin_base.html.twig' %}
{% block cell %}<td class="admin">{{ parent() }}</td>{% endblock %}

{# admin_base.html.twig #}
{% block cell %}{{ block('cell_value') }}{% endblock %}

{# application_theme.html.twig #}
{% block cell_value %}<strong>{{ value }}</strong>{% endblock %}

{# base_theme.html.twig #}
{% block cell_value %}{{ value }}{% endblock %}

Create a chain in order of precedence, then render the block you need:

use Twig\BlockChain;

$defaults = new BlockChain($twig, ['base_theme.html.twig']);
$blocks = new BlockChain($twig, [
    'admin_theme.html.twig',
    'application_theme.html.twig',
    $defaults,
]);

echo $blocks->renderBlock('cell', ['value' => 'Pending']);

The result is <td class="admin"><strong>Pending</strong></td>. Each entry can be a template name, a loaded template or another chain. You can reuse $defaults in other theme stacks.

How Block Lookup Works

The first matching block wins: cell comes from the admin theme, while block('cell_value') picks the application override. parent() stays within the defining template's inheritance hierarchy; it does not jump to the next theme. See the BlockChain documentation for the full lookup rules, context handling and other methods.

The same pattern is useful for form controls, CMS fields and email fragments: your renderer picks the block name, and Twig finds the right theme.

How It Helps Open-Source Projects

Symfony Forms: Symfony's form renderer has long combined blocks from unrelated themes: a form view can have its own theme, inherit themes from its parent view and fall back to the default layout. A form_row block from one theme can call block('form_widget') and find an override in another. Before BlockChain, the Twig Bridge had to walk template parents, merge block maps and pass those maps to Twig's internal rendering API.

The Twig Bridge now uses BlockChain when available.

This integration is available in all currently supported Symfony versions. If you upgrade to Twig 3.29, update the Twig Bridge too.

Beyond Symfony: Other renderers implement similar block composition and could benefit from the same Twig API:

• Ibexa Core selects field-type blocks, such as ibexa_string_field, across local and configured CMS field templates. Its field renderer currently builds the block map itself.
• Prezent Grid layers grid themes and resolves widget blocks for column types. A chain could compose its themes while the grid renderer keeps its column-type fallback logic.
• Listing traverses template parents and merges their blocks before rendering listing and column blocks. A chain could take over that traversal.

The need to compose blocks across independent templates is not specific to Symfony, which is why the API landed in Twig.

Faster AMQP Transport

Contributed by Nicolas Grekas in #65924 and #65168

The AMQP transport asks the broker for one message at a time, which requires a network round trip per message. RabbitMQ considers this the least efficient way to consume messages. Symfony 8.2 adds a prefetch_count option which registers a real consumer on each queue and lets the broker push messages to it in advance:

# .env
MESSENGER_TRANSPORT_DSN=amqp://guest:guest@localhost:5672/%2f/messages?prefetch_count=20

In benchmarks against a local broker, this consumed messages 13 to 18 times faster. Registered consumers also appear in the RabbitMQ management UI. Set prefetch_count higher than the worker's fetch size, which defaults to the --concurrency value.

Prefetching is disabled by default because it changes how messages are consumed: the broker now decides the order across queues, and any prefetched messages still waiting to be handled are redelivered when the worker stops.

Delayed messages also become cheaper to send. AMQP has no native delays, so Symfony creates a delay queue for each distinct delay value. The default retry strategy adds jitter to these delays, resulting in more than a thousand different values. Each retry therefore usually declares and binds a new queue.

In Symfony 8.2, delays are rounded up to two significant digits (e.g. 5234 ms becomes 5300 ms). This reduces the number of delay queues by orders of magnitude, while ensuring that messages are never released before the requested delay and at most 10% later. Use the new delay[granularity] option to round delays to a fixed number of milliseconds instead, or set it to 1 to disable rounding:

# .env
MESSENGER_TRANSPORT_DSN=amqp://guest:guest@localhost:5672/%2f/messages?delay[granularity]=1000

Logging Processing Time and Memory Usage

Contributed by Marie Charles in #64621

This feature won't make your workers faster, but it will help you find which messages are slow. The new optional logging middleware records processing time and memory usage for each message. Enable it on the buses you want to monitor:

# config/packages/messenger.yaml
framework:
    messenger:
        buses:
            messenger.bus.default:
                middleware:
                    - logging

// config/packages/messenger.php
namespace Symfony\Component\DependencyInjection\Loader\Configurator;

return App::config([
    'framework' => [
        'messenger' => [
            'buses' => [
                'messenger.bus.default' => [
                    'middleware' => ['logging'],
                ],
            ],
        ],
    ],
]);

The middleware measures everything that runs after it in the stack. It logs messages in the messenger channel with the class, duration_ms and memory_usage (in bytes) context keys, so you can build dashboards and alerts from them:

messenger.INFO: "App\Message\GenerateInvoice" message successfully handled. {"class":"App\\Message\\GenerateInvoice","duration_ms":1834,"memory_usage":12582912}
messenger.ERROR: Unable to handle "App\Message\SyncCatalog" message. {"class":"App\\Message\\SyncCatalog","duration_ms":30012,"memory_usage":524288,"exception":"..."}

Per-Message Open and Click Tracking

Contributed by Starfox64 and Nicolas Grekas in #65451

Email open and click tracking is usually a global setting in your provider account, so it applies to all your emails. However, privacy regulations may require asking each user for consent before tracking them. The new TrackingHeader lets you override the provider setting for a single email, and each bridge maps it to the provider's native mechanism:

use Symfony\Component\Mailer\Header\TrackingHeader;
use Symfony\Component\Mime\Email;

$email = new Email()
    ->to($user->getEmail())
    // ...
;

$email->getHeaders()->add(new TrackingHeader(
    $user->hasConsentedToOpenTracking(),
    $user->hasConsentedToClickTracking(),
));

Both arguments are optional. When an argument is null, the provider setting is used for that type of tracking.

If an email doesn't add this header (for example, emails sent by third-party bundles), the provider setting applies. To be on the safe side, use the new tracking option to disable tracking by default for all emails. A header added to an individual email always takes precedence over this option:

# config/packages/mailer.yaml
framework:
    mailer:
        tracking:
            opens: false
            clicks: false

// config/packages/mailer.php
return App::config([
    'framework' => [
        'mailer' => [
            'tracking' => ['opens' => false, 'clicks' => false],
        ],
    ],
]);

This feature is supported by AhaSend, Azure, Brevo, Infobip, Mailchimp, MailerSend, Mailgun, Mailjet, Postmark, and SendGrid. With other transports, it's sent as a regular X-Track header and has no effect.

Read the Mailer documentation for all the details about these features, including the specific behavior of each provider.

Using the Schema in Your Editor

Contributed by Jérôme Tamarelle in #62125

When the container is compiled in debug mode and the symfony/yaml package is installed, Symfony 8.2 writes a config/schema.json file. It merges the configuration trees of every registered bundle, including the when@<env> blocks. The file is regenerated each time the container is compiled, so it always matches the bundles installed in your app.

This is the YAML counterpart of the config/reference.php file that Symfony 7.4 introduced for PHP configuration. Your IDE doesn't pick up the new file automatically, so you need to point it to config/schema.json.

Any editor based on yaml-language-server (Visual Studio Code with the YAML extension, Neovim, Emacs, etc.) reads this comment at the top of the file:

# config/packages/framework.yaml
# yaml-language-server: $schema=../schema.json
framework:
    secret: '%env(APP_SECRET)%'
    # ...

The path is relative to the edited file, so use ../../schema.json inside config/packages/<env>/. In Visual Studio Code you can also map the schema to every file in config/packages/ at once in .vscode/settings.json:

{
    "yaml.schemas": {
        "config/schema.json": "config/packages/**/*.yaml"
    }
}

In PhpStorm, add the same mapping in Settings > Languages & Frameworks > Schemas and DTDs > JSON Schema Mappings. Your editor can then autocomplete option names and show their descriptions and default values. It also flags unknown or deprecated options and values with the wrong type.

Validating YAML Files with lint:yaml

Contributed by Jérôme Tamarelle in #65394

The lint:yaml command can now check YAML files against a JSON Schema as well as checking their syntax. You can use this in CI to catch configuration errors. Schema validation requires installing the opis/json-schema library:

$ composer require opis/json-schema

Then, pass the new --check-schema option:

# validate the given files against a specific schema
$ php bin/console lint:yaml config/packages/ --check-schema=config/schema.json

# validate each file against its own schema
$ php bin/console lint:yaml config/ --check-schema

The second command reads the same # yaml-language-server: $schema= comment that editors use. In Symfony applications, files in the usual locations don't even need that comment:

• Files in config/packages/ use the generated config/schema.json.
• Routes, services, serializer and validator files (config/routes.yaml, config/services.yaml, etc.) use their components' schemas.

Files without a schema are reported as valid, so you can run the command on the whole config/ directory.

Wildcards in the Role Hierarchy

Contributed by Nicolas Rigaud in #52099

Role hierarchies list their roles one by one. If your application defines e.g. ROLE_BLOG_AUTHOR, ROLE_BLOG_EDITOR and ROLE_BLOG_MODERATOR, and all of them should include ROLE_BLOG_READER, you need one entry for each of them, plus another one whenever you add a new blog role.

In Symfony 8.2, the keys of the role hierarchy can include the * wildcard to match an entire family of roles:

# config/packages/security.yaml
security:
    # ...

    role_hierarchy:
        ROLE_*:              ROLE_USER
        ROLE_*_MODERATOR:    ROLE_MODERATOR
        ROLE_BLOG_*:         ROLE_BLOG_READER
        ROLE_BLOG_MODERATOR: [ROLE_BLOG_DELETE_POST, ROLE_BLOG_LOCK_POST]

Roles don't need to be listed in the hierarchy to match a wildcard. With this configuration, a user with ROLE_BLOG_COMMENTER also gets ROLE_BLOG_READER and ROLE_USER, even if that role doesn't appear anywhere in the configuration.

The * character is only considered a wildcard when it's wrapped by underscores (ROLE_*_FOO) or placed after an underscore at the end of the role name (ROLE_BAR_*). Keys such as ROLE_BLOG* or ROLE_*BLOG are still regular role names.

Wildcards are patterns, not roles, so you can only use them in the keys of the hierarchy. For example, is_granted('ROLE_BLOG_*') still looks for a role with that exact name and wildcards are never returned by the getReachableRoleNames() and getParentRoleNames() methods.

The debug:roles Command

Contributed by Nicolas Rigaud in #65345

Wildcards simplifies role configuration but can make debugging a bit more difficult. If you need to know the exact roles granted to a user, Symfony 8.2 adds a debug:roles command that does that for you:

# displays the whole role hierarchy
$ php bin/console debug:roles

# displays all the roles granted by the given role(s)
$ php bin/console debug:roles ROLE_BLOG_MODERATOR

 * ROLE_BLOG_MODERATOR
 * ROLE_BLOG_DELETE_POST
 * ROLE_BLOG_LOCK_POST
 * ROLE_USER
 * ROLE_MODERATOR
 * ROLE_BLOG_READER

Add the --tree option to see why each role is granted, including the wildcards that were matched:

$ php bin/console debug:roles ROLE_BLOG_MODERATOR --tree

ROLE_BLOG_MODERATOR
├── ROLE_*
│   └── ROLE_USER
├── ROLE_*_MODERATOR
│   └── ROLE_MODERATOR
├── ROLE_BLOG_*
│   └── ROLE_BLOG_READER
├── ROLE_BLOG_DELETE_POST
└── ROLE_BLOG_LOCK_POST

Role Hierarchy Graph in the Profiler

Contributed by Damien Fernandes in #61786

Symfony 7.4 introduced the debug:security:role-hierarchy command to dump the role hierarchy as a Mermaid chart. In Symfony 8.2, that chart is displayed directly in the Security panel of the profiler, so you can check the roles available in your application without running any command:

UX Pagination, At Last

Contributed by Simon André in #3753

For years, whenever Fabien Potencier teased a new Symfony component, someone in the community guessed "Pagination". It finally exists, though in Symfony UX rather than in Symfony itself.

symfony/ux-pagination paginates arrays, Doctrine ORM and DBAL queries, and any custom data source behind a single request-aware PaginatorInterface. PHP owns the query, Twig renders accessible navigation, and the browser follows ordinary links: no JavaScript, no Stimulus, no Turbo required.

// src/Controller/ProductController.php
#[Route('/products', name: 'product_index')]
public function __invoke(
    ProductRepository $repository,
    PaginatorInterface $paginator,
): Response {
    $products = $paginator
        ->cursor($repository->createQueryBuilder('product'))
        ->orderBy(['createdAt', 'id'], 'DESC')
        ->perPage(20)
        ->paginate();

    return $this->render('product/index.html.twig', ['products' => $products]);
}

{# templates/product/index.html.twig #}
{% for product in products %}
    <article>{{ product.name }}</article>
{% endfor %}

{{ ux_pagination(products) }}

Three strategies are available: numbered pagination for exact totals, lookahead when you only need a reliable next link and want to skip the COUNT query, and bidirectional cursor pagination when rows can move while somebody is browsing.

The <twig:ux:pagination> component ships default, Bootstrap and Tailwind themes, translations in ten locales, JSON serialization, and an optional LiveComponent integration through ComponentWithPaginationTrait. The bundle is experimental, but its own page on the UX website is already live.

Component Attributes Are Now Rendered by Twig

Contributed by Hugo Alliaume in #3820 and #3756

ComponentAttributes used to hand-roll its own attribute rendering: it threw on null, dropped aria-* set to false, rendered a boolean true bare, and threw on arrays, iterables and enums. That was a partial, in places invalid, reimplementation of what Twig has rendered natively since 3.24, when html_attr() landed.

Both {{ attributes }} and attributes.render() now resolve values through that same logic, so a component and a plain Twig template render attributes identically. Twig 3.29 is what made the reuse possible: it exposed the per-value building block behind html_attr().

{# null omits the attribute instead of throwing #}
<twig:Button :title="null" />          {# <button> #}

{# aria-* booleans render "true"/"false", like in Vue and React #}
<twig:Button :aria-expanded="false" /> {# <button aria-expanded="false"> #}

{# arrays, iterables and backed enums are now accepted #}
<twig:Button :class="['btn', 'btn-lg']" :style="{ color: 'red' }" />
<twig:Button :type="buttonType" />      {# a BackedEnum renders its backing value #}

ComponentAttributes#defaults() also understands MergeableInterface from twig/html-extra, which is how the Toolkit now merges Tailwind classes. This needs twig/html-extra ^3.29 and twig/twig ^3.24, and it may break your tests if you assert on the rendered HTML of a component's attributes: boolean, null, aria-* and non-scalar values render differently now.

UX Icons and UX Map Follow the Same Rules

Contributed by Hugo Alliaume in #3821

ux_icon(), <twig:ux:icon>, ux_map() and <twig:ux:map> render their attributes through the same code path, so the typed values of html_attr_type() and tailwind_classes now work there too. The same warning applies: if you assert on the <svg> or map <div> attributes, regenerate those assertions.

The same change fixes a separate bug in UX Icons: an omitted aria-label, aria-labelledby or title used to suppress the automatic aria-hidden="true", leaving the icon neither labelled nor hidden from assistive technology.

Documenting Props and Blocks with Twig Comments

Contributed by Hugo Alliaume in #3795 and #3796

Twig 3.29 introduced documentation comments, and TwigComponent now reads them. Write a ## comment above a prop inside {% props %}, or a {## ... ##} comment above a block, and the description is captured at compile time.

{%- props
    ## 'default'|'sm' Size variant of the card.
    size = 'default'
-%}
<div {{ attributes }}>
    {##- The card content, typically includes `Card:Header` and `Card:Footer`. -#}
    {%- block content %}{% endblock -%}
</div>

PropsNode::getPropDocumentation() exposes it per prop. The UX Toolkit is both the reason this syntax exists and its first consumer: wanting to document the props and blocks of every kit recipe is what pushed for an official Twig syntax instead of inventing another convention. Every kit recipe then dropped its old {# @prop #} and {# @block #} docblocks for it, and the prop tables on the UX website are generated from it.

Dynamic Component Names in the HTML Syntax

Contributed by Sébastien Jean in #3699

{% component %} has accepted a dynamic expression since 3.4. The HTML syntax now does too, through <twig:component> and its is attribute:

<twig:component is="Alert" type="success" />

{# Dynamic component name #}
<twig:component :is="componentName" type="success" />

{# Dynamic in a loop #}
{% set prefix = 'DynamicNameComponent' %}
{% for i in 1..2 %}
    <twig:component :is="prefix ~ i" />
{% endfor %}

Twig 4 Support

Contributed by Hugo Alliaume in #3814

Autocomplete, Cropper.js, Dropzone, Icons, LiveComponent, Map, StimulusBundle, Toolkit, Turbo and TwigComponent now run on Twig 4 as well as Twig 3.

One Twig 4 change affects Turbo templates that pass a fully qualified class name to turbo_stream_from() or <twig:Turbo:Stream:From>. Twig 3 requires escaping backslashes in string literals and silently drops the ones you forget, so 'App\Entity\Book' reached Turbo as the unusable topic AppEntityBook. Twig 4 keeps an unrecognized escape sequence intact, the way PHP does, so the class name now resolves. Templates already using the documented 'App\\Entity\\Book' form behave the same on both versions.

Autocomplete Without Doctrine

Contributed by Francis Hilaire in #3441

UX Autocomplete was tied to Doctrine ORM. Backing a field with an API, a search engine or an in-memory list meant writing a custom endpoint. It now accepts any data source: implement AutocompleterInterface, tag the service with an alias, and the new ux_autocomplete route serves it.

#[AutoconfigureTag('ux.autocompleter', ['alias' => 'food'])]
class FoodAutocompleter implements AutocompleterInterface
{
    public function fetchResults(string $query, int $page): AutocompleteResults
    {
        // ... fetch from wherever your data lives
        return new AutocompleteResults($results, $hasNextPage);
    }

    public function isGranted(Security $security): bool
    {
        return true;
    }
}

{{ path('ux_autocomplete', { alias: 'food' }) }}

The Doctrine API stays fully supported: EntityAutocompleterInterface and the ux.entity_autocompleter tag work exactly as before. The ux_entity_autocomplete route is now an alias of ux_autocomplete, and is deprecated.

Removing a Component, and Downloading a File, from a LiveAction

Contributed by Simon André in #3773 and #3761

A LiveAction can now end its own component. LiveResponse::remove() performs one final render, so emitted events still reach other components, then disconnects the Stimulus controller and takes the element off the page:

#[LiveAction]
public function dismiss(NotificationRepository $repository): LiveResponse
{
    $repository->markAsRead($this->notification);
    $this->emit('notificationDismissed', ['id' => $this->notification->getId()]);

    return LiveResponse::remove();
}

The element carries a data-live-removing attribute until any animation on it finishes, then is dropped: nothing is deleted server-side, only the component leaves the page. LiveResponse::downloadUrl() and LiveResponse::downloadFile() trigger a file download while the component keeps its state and re-renders. Prefer downloadUrl() whenever the file can be served from its own route: the browser downloads it natively, so nothing sits in memory on either side, progress is reported, and range requests and resuming work.

Dropzone Accepts Several Files

Contributed by Dooji and Hugo Alliaume in #3684 and #3843

Pass the standard multiple option inherited from FileType, and the Dropzone accumulates files across successive selections instead of replacing the previous one, previews each of them, and lets the user remove them individually before submitting:

->add('photos', DropzoneType::class, [
    'multiple' => true,
    'remove_label' => 'Delete', // labels the per-file remove button
])

In multiple mode, dropzone:change carries a FileList rather than a single File, a new dropzone:remove event is dispatched with the removed file, and dropzone:clear is not dispatched since there is no clear button. The same release fixes the drop zone appearing empty when the very same file is dropped twice in a row, which Chrome reports without firing a change event.

Cropper.js Runs on Intervention Image 3 and 4

Contributed by Thomas Picquet in #3679

Server-side cropping is powered by Intervention Image, and the package was pinned to version 2, which triggers PHP deprecations. Versions 3 and 4 are now supported, and version 2 keeps working as the lowest supported version.

The image driver is configurable too, which was not possible before:

# config/packages/cropperjs.yaml
cropperjs:
    driver: gd # "gd" (default), "imagick" or "vips"

gd and imagick ship with intervention/image. vips also needs the intervention/image-driver-vips package, the libvips system library and ext-ffi. If you need full control, register your own service implementing DriverInterface and point cropperjs.driver_service at it. Both options require intervention/image 3 or higher.

Custom Icon Finders

Contributed by Pierre du Plessis in #3876

ux:icons:lock scans your Twig templates, which means it cannot find an icon whose name is built at runtime. IconFinderInterface lets you declare those names from any source, a database, an API or a PHP enum:

// src/Icons/AppIconFinder.php
final class AppIconFinder implements IconFinderInterface
{
    public function icons(): array
    {
        $icons = ['tabler:mail'];

        foreach (Status::cases() as $status) {
            $icons[] = $status->icon();
        }

        return $icons;
    }
}

Thanks to autoconfiguration, the finder is registered for you. Its icons are merged with the ones found in your templates, and are used both by ux:icons:lock and when warming the icon cache.

UX Icons Parses SVG with the PHP 8.4 Dom API

Contributed by Hugo Alliaume in #3771

SVG parsing moved from \DOMDocument to the \Dom\XMLDocument API introduced in PHP 8.4. Beyond being the modern API, it fixes a real bug: \DOMDocument dropped the xmlns attribute when rebuilding an icon's attributes, so an icon rendered from a local file came out without it.

That is a markup change. If you assert on the output of ux_icon() or <twig:ux:icon>, regenerate those assertions and clear your icon cache after upgrading.

StimulusHelper Is Autowirable

Contributed by Hugo Alliaume in #3849

The Stimulus attributes the Twig helpers build are also available from PHP, through the StimulusHelper service, which you can now autowire. Reach for it when the element you want to decorate is not written in a template, a form field for instance:

public function __construct(private StimulusHelper $stimulusHelper)
{
}

public function buildForm(FormBuilderInterface $builder, array $options): void
{
    $attributes = $this->stimulusHelper->createStimulusAttributes();
    $attributes->addController('country-picker', ['locale' => 'fr']);
    $attributes->addAction('country-picker', 'refresh', 'change');

    $builder->add('country', CountryType::class, [
        'attr' => $attributes->toArray(),
    ]);
}

The field then renders with data-controller, data-action and the value attributes the Twig helpers would have produced.

UX Toolkit: Blocks

Contributed by Sébastien Jean in #3596

A recipe is a pack of files and dependencies for one component. A block is a whole page section built from a kit's components, installed and previewed as a unit. The Shadcn kit ships the first two, login-01 and login-02:

$ php bin/console ux:install login-01 --kit=shadcn

Installing it pulls in the recipes it is built from, here button, card, input and label, and writes the LoginForm component into your templates. Dashboards, sidebars and other ready-to-use sections are where this goes next.

UX Toolkit: Twenty New Shadcn Recipes

Contributed by Hugo Alliaume , Romain Monteil and Pascal CESCON in #3869 , #3870 , #3855 , #3884 , #3883 , #3806 , #3232 , #3804 , #3483 , #3871 , #3486 , #3889 , #3479 , #3801 , #3487 , #3872 , #3480 , #3805 , #3469 and #3481

The Shadcn kit gained twenty recipes: attachment, bubble, calendar, carousel, date-picker, drawer, dropdown-menu, form, input-otp, marker, menubar, message, native-select, navigation-menu, popover, questionnaire, scroll-area, sheet, sidebar and slider. The typography recipe was removed.

Both Tailwind kits also changed how they merge classes: component variants now go through attributes.defaults({ class: '...'|tailwind_classes }) instead of tailwind_merge, so the classes you pass to a component override its own. This requires symfony/ux-twig-component 3.5.

Browse them all, with a live preview, on ux.symfony.com/toolkit.

UX Toolkit: Accessibility, Documented on Every Recipe

Contributed by Pascal CESCON in #3798

Contributed by Hugo Alliaume in #3887 , #3803 and #3807

Every one of the sixty Shadcn recipes now carries an ## Accessibility section in its README.md, visible on the UX website. It says what the recipe already handles, what it expects from your markup, and what you still have to do yourself.

Writing them surfaced real bugs, now fixed. alert-dialog, dialog, drawer and sheet rendered aria-labelledby and aria-describedby on a roleless wrapper rather than on the <dialog> element, which left the modal without an accessible name. Right-to-left layouts were broken by physical spacing and border utilities, now replaced with their logical counterparts. A dialog focuses its first form field, or the [autofocus] element, when it opens. And button no longer renders type="button" when as is not a button.

The Standalone AssetMapper Bundle

Contributed by Simon André and Hugo Alliaume in #3867 , #3891 and #3892

Symfony 8.2 moves the AssetMapper configuration out of FrameworkBundle and into a standalone AssetMapperBundle. Every UX package that registers assets detects it, so nothing changes for you whether you run Symfony 7.4, 8.0 or 8.2.

A Performance Pass

Contributed by Javier Eguiluz and Hugo Alliaume in #3692 , #3841 , #3775 , #3776 , #3777 , #3779 , #3780 , #3781 , #3782 , #3783 , #3784 , #3785 and #3786

A dozen pull requests went after hot paths across the monorepo, each one measured before and after. TwigComponent absorbed most of the work, on two fronts: its render pipeline and its pre-lexer.

Its render pipeline no longer rebuilds a ComponentMetadata on every call, no longer allocates and dispatches five events per render when nothing listens to them, and now builds its render variables in a single pass. That pipeline was profiled against an EasyAdmin index page, the kind of page that renders hundreds of small components. Its pre-lexer used to copy the whole remaining template on every call to consume(), several times per character, which made pre-lexing quadratic in the size of the template. It now scans the template in place instead.

The rest is smaller and spread out. LiveComponent memoizes its attribute-method lookups per class instead of rebuilding a ReflectionClass on every render, and skips the bracket pipeline for plain model names. UX Icons cuts allocations in IconRenderer::renderIcon(), and UX Map renders each icon once instead of once per marker. In the browser, StimulusBundle stops watching the DOM once every lazy controller is loaded and normalizes controller names faster, while the Translator caches the regular expression compiled by strtr(). The Toolkit stops re-walking the filesystem on every Recipe::getFiles().

Full Changelog

• #3890 [Toolkit][Shadcn] Drop the dead height option from recipe previews (@Kocal)
• #3889 [Toolkit][Shadcn] Add message recipe (@ker0x)
• #3872 [Toolkit][Shadcn] Add questionnaire recipe (@ker0x)
• #3883 [Toolkit][Shadcn] Add date-picker recipe (@ker0x)
• #3888 [Map] Make the Google Maps browser test resilient (@smnandre)
• #3855 [Toolkit][Shadcn] Add calendar recipe (@ker0x)
• #3796 [Toolkit] Read prop and block docs from Twig documentation comments (@Kocal)
• #3814 [Autocomplete][Cropperjs][Dropzone][LiveComponent][StimulusBundle][Toolkit][TwigComponent] Add support for Twig 4.x (@Kocal)
• #3821 [Icons][Map] Render attributes through twig/html-extra's html_attr() logic (@Kocal)
• #3820 [TwigComponent] Render component attributes through twig/html-extra's html_attr() (@Kocal)
• #3870 [Toolkit][Shadcn] Add bubble recipe (@ker0x)
• #3880 [LiveComponent] Handle paths beginning with double slash in LiveUrlSubscriber (@mbuliard)
• #3876 [Icons] Add IconFinderInterface to create custom finders to lock icons (@pierredup)
• #3887 [Toolkit][Shadcn] Document accessibility, fix <dialog>-based recipies accessibility, and improve right-to-left layouts (@Kocal)
• #3871 [Toolkit][Shadcn] Add marker recipe (@ker0x)
• #3869 [Toolkit][Shadcn] Add attachment recipe (@ker0x)
• #3884 [Toolkit][Shadcn] Add carousel recipe (@Kocal)
• #3878 [Toolkit][Shadcn] Fix the rich colors of Sonner recipe (@Kocal)
• #3868 [LiveComponent] Upgrade Idiomorph to 0.7.4 (@smnandre)
• #3858 [Autocomplete] Add a max_options option to control how many options the dropdown displays (@Kocal)
• #3882 [Autocomplete][Chartjs][Cropperjs][Dropzone][LiveComponent][Map][Notify][React][StimulusBundle][Turbo][Vue] Update TypeScript's target to es2022 (@Kocal)
• #3881 [Autocomplete] Make search test fixtures deterministic (fix flakky) (@smnandre)
• #3867 [StimulusBundle] Detect the standalone AssetMapper bundle (@smnandre)
• #3851 [Toolkit] Fix ux:install reporting the source path of the installed files (@ker0x)
• #3860 [Toolkit] Restore the "available since" note on recipe install steps (@Kocal)
• #3849 [StimulusBundle] Make StimulusHelper autowirable and document PHP usage (@Kocal)
• #3847 [Turbo] Fix broadcasting an entity whose identifier is made of associations (@Kocal)
• #3846 [Translator] Cover the parent locale fallback in the dumper tests (@Kocal)
• #3843 [Dropzone] Fix the drop zone appearing empty when the same file is dropped again (@Kocal)
• #3842 [Toolkit][Flowbite] Rename the modal Stimulus controller to avoid a collision with Flowbite (@Kocal)
• #3518 [TwigComponent] Fix PreLexer confusing {# inside output expressions with comments (@Amoifr)
• #3441 [Autocomplete] Decouple from Doctrine ORM - support any data source (@Prometee)
• #3679 [Cropperjs] Upgrade to Intervention Image v4 and make the image driver configurable (@deluxetom)
• #3684 Allow for multiple file uploads at once (@Dooij)
• #3763 [Autocomplete] Translate the optgroup labels returned by the AJAX endpoint (@kira0269)
• #3836 [TwigComponent] Fix null-safe operator in component tag props (@alireza-aminzadeh)
• #3827 [TwigComponent] Treat a prop explicitly passed as null as defined (@Kocal)
• #3823 [LiveComponent] Use test stubs instead of mocks (@smnandre)
• #3832 Remove vulnerable extract-zip dependency (@smnandre)
• #3831 [CI] Pin DOCtor-RST container image (@smnandre)
• #3829 [React] Update E2E dependencies (@smnandre)
• #3753 [Pagination] Add new UX Pagination component (@smnandre)
• #3773 [LiveComponent] Add LiveResponse::remove() to trigger component deletion (@smnandre)
• #3761 [LiveComponent] Add file downloads from a LiveAction (@smnandre)
• #3817 [CalendarLink] Derive a stable ICS UID from the event content (@Kocal)
• #3816 [CalendarLink] Make DTSTAMP deterministic via the Clock component (@Kocal)
• #3818 [CalendarLink] Anchor timed events to their time zone with TZID and VTIMEZONE (@Kocal)
• #3826 [CalendarLink] Make IcsBuilder internal (@Kocal)
• #3819 [Autocomplete] Translated 'Add placeholder' to Italian (@luigif)
• #3469 [Toolkit][Shadcn] Add sidebar recipe (@Amoifr)
• #3804 [Toolkit][Shadcn] Add form recipe (@Kocal)
• #3806 [Toolkit][Shadcn] Add drawer recipe (@Kocal)
• #3805 [Toolkit][Shadcn] Add sheet recipe (@Kocal)
• #3807 [Toolkit][Shadcn] popover: honor [autofocus] and skip hidden inputs when focusing content (@Kocal)
• #3803 [Toolkit][Shadcn] Focus the first form field when a dialog opens (@Kocal)
• #3481 [Toolkit][Shadcn] Add slider recipe (@Kocal)
• #3480 [Toolkit][Shadcn] Add scroll-area recipe (@Kocal)
• #3802 [Toolkit][Shadcn] Remove typography recipe (@Kocal)
• #3479 [Toolkit][Shadcn] Add native-select recipe (@Amoifr)
• #3801 [Toolkit][Shadcn] Add navigation-menu recipe (@Kocal)
• #3232 [Toolkit][Shadcn] Add DropdownMenu component (@Kocal)
• #3487 [Toolkit][Shadcn] Add popover recipe (@Kocal)
• #3791 [LiveComponent] Fix proxy turning "toJSON" and "then" protocol probes into server actions (@Amoifr)
• #3798 [Toolkit][Shadcn] Fix the hover-card usage example crashing on a plain HTML trigger (@Amoifr)
• #3795 [TwigComponent] Capture prop documentation comments (@Kocal)
• #3486 [Toolkit][Shadcn] Add menubar recipe (@Kocal)
• #3483 [Toolkit][Shadcn] Add input-otp recipe (@Kocal)
• #3777 [LiveComponent] Cache the attribute-method lookups per component class (@Kocal)
• #3762 [TwigComponent] Fix twig:blockquote is not a block (@smnandre)
• #3779 [Map] Render each UX icon once instead of once per marker (@Kocal)
• #3783 [StimulusBundle] Stop watching the DOM once every lazy controller is loaded (@Kocal)
• #3776 [TwigComponent] Reduce per-character work in the pre-lexer scan loops (@Kocal)
• #3784 [Translator] Cache the RegExp compiled by strtr() (@Kocal)
• #3786 [LiveComponent] Skip the bracket pipeline for plain model names (@Kocal)
• #3781 [StimulusBundle] Speed up Stimulus name normalization (@Kocal)
• #3841 [TwigComponent] Apply review remarks from #3692 (@Kocal)
• #3692 [TwigComponent] Reduce per-render CPU cost of static components (@javiereguiluz)
• #3775 [TwigComponent] Fix quadratic scanning in TwigPreLexer::consume() (@Kocal)
• #3780 [Toolkit] Stop re-walking the filesystem on every Recipe::getFiles() (@Kocal)
• #3785 [TwigComponent] Build the exposed properties without a generator (@Kocal)
• #3782 [Icons] Cut per-render allocations in IconRenderer::renderIcon() (@Kocal)
• #3764 [TwigComponent] Fix { verbatim } pre-lexing (@smnandre)
• #3771 [Icons] Migrate to modern \Dom\XMLDocument API (@Kocal)
• #3699 [TwigComponent] Add dynamic component support for HTML-syntax (@seb-jean)
• #3596 [Toolkit] Finalize support for Blocks, add Shadcn's login-01 and login-02 blocks (@seb-jean)
• #3760 [Toolkit] Migrate Tailwind kits to the tailwind_classes mergeable idiom (@Kocal)
• #3756 [TwigComponent] Support MergeableInterface in ComponentAttributes (@Kocal)
• #3758 Upgrade pnpm to 11.21.0 (@Kocal)
• #3749 [Toolkit] Restore the filename above installation code blocks (filename code options) (@Kocal)

Symfony UX 3.5.1 followed a few hours later, with two fixes for the standalone AssetMapper bundle that 3.5.0 had missed:

• #3892 [Map] Add missing support for Symfony 8.2's standalone AssetMapperBundle (@Kocal)
• #3891 [Pagination] Add missing support for Symfony 8.2's standalone AssetMapperBundle (@Kocal)

UX Pagination is experimental, which means its API can still change before a stable release. That is exactly when your feedback is worth the most, so try it and open an issue if something does not fit. The same goes for the attribute rendering change: if upgrading broke an assertion in a way this post did not warn you about, we want to hear about it.