Depending on your resource configuration, the breadcrumb element's output might not be ideal, displaying the entity's ID instead of a more user-friendly identifier like the title of the entity.

Fortunately, Sylius provides a straightforward way to configure which field to display, enhancing the user experience. To customize the breadcrumb for your resource, you need to create a new configuration.

For a Talk resource, you would use the sylius_admin.talk.update.content.header Twig Hook to configure the breadcrumbs hookable element. In the configuration for the hookable, you can specify the rendered_field to display a particular property of your entity. For example, to display the title property use the following configuration:

'sylius_admin.talk.update.content.header':
  breadcrumbs:
    template: '@SyliusBootstrapAdminUi/shared/crud/update/content/header/breadcrumbs.html.twig'
    configuration:
      rendered_field: title
    priority: 0

This configuration results in a more intuitive breadcrumb display, showing the title of the entity instead of its ID:

If you want to render static text before the resource name, you can use the rendered_field_prefix configuration. Here's how you can do it:

'sylius_admin.talk.update.content.header':
  breadcrumbs:
    template: '@SyliusBootstrapAdminUi/shared/crud/update/content/header/breadcrumbs.html.twig'
    configuration:
      rendered_field_prefix: '> '
      rendered_field: title
    priority: 0

The rendered breadcrumb element will look like this:

This example demonstrates the customization capabilities of Sylius out of the box, allowing for tailored and user-friendly interfaces without extensive development.

This plugin has been instrumental in configuring "global" variables that merchants can modify without needing to rebuild or restart the Sylius application.

A recent feature request by the merchant required us to implement a document upload and download feature. The merchant needed to upload a document that customers could then download. However, the Settings plugin does not support file uploads by default. Given that the plugin leverages Symfony Forms under the hood, we explored the possibility of integrating into the Symfony Form flow to upload files to a specific location.

Initially, we attempted to use the PRE_SUBMIT and POST_SUBMIT events to develop the requested feature. Unfortunately, this approach did not yield the desired results. The main logic within the Settings entity is designed to work with objects implementing DateTimeInterface or JsonSerializable, but not with file objects directly.

After careful consideration, we discovered a straightforward solution: Using a Data Transformer for the file upload process. A Data Transformer acts as a "translator" between the application's logic and the user's view, converting data from one format to another. Although this might not be the most convenient approach, it effectively addresses our specific use case.

In our DocumentSettingsType class, we configured the file upload field as follows:

<?php

declare(strict_types=1);

namespace App\Form\Type\Settings;

use App\Form\Transformer\UploadedSettingsFileToFilenameTransformer;
use MonsieurBiz\SyliusSettingsPlugin\Form\AbstractSettingsType;
use MonsieurBiz\SyliusSettingsPlugin\Form\SettingsTypeInterface;
use Symfony\Component\Form\Extension\Core\Type\FileType;
use Symfony\Component\Form\FormBuilderInterface;

class DocumentsSettingsType extends AbstractSettingsType implements SettingsTypeInterface
{
    public function __construct(private string $kernelProjectDir)
    {
    }

    public function buildForm(FormBuilderInterface $builder, array $options): void
    {
        $this->addWithDefaultCheckbox($builder, 'file_template', FileType::class, [
            'label' => 'admin.ui.form.settings.file_template',
            'required' => false,
            'data_class' => null,
        ]);

        $builder->get('file_template')->addModelTransformer(
            new UploadedSettingsFileToFilenameTransformer($this->kernelProjectDir),
        );
    }
}

For the file_template form field, we register the UploadedSettingsFileToFilenameTransformer to take care of the file upload logic. The implementation of the UploadedSettingsFileToFilenameTransformer class looks like this:

<?php

declare(strict_types=1);

namespace App\Form\Transformer;

use App\Controller\DocumentsController;
use Symfony\Component\Form\DataTransformerInterface;
use Symfony\Component\HttpFoundation\File\UploadedFile;

final readonly class UploadedSettingsFileToFilenameTransformer implements DataTransformerInterface
{
    public function __construct(private string $kernelProjectDir)
    {
    }

    public function transform($value): mixed
    {
        return null;
    }

    public function reverseTransform($value): mixed
    {
        if (!$value instanceof UploadedFile) {
            return $value;
        }

        $filename = uniqid() . '.' . $value->guessExtension();
        $value->move($this->kernelProjectDir . DocumentsController::STORAGE_DIR, $filename);

        return $filename;
    }
}

In our Data Transformer implementation, the transform() method returns null because we don't need to convert the file name back to an UploadedFile object. The reverseTransform() method handles the file upload and returns the filename afterward.

To fully leverage the principles of conference-driven development, I chose to launch a new version of the phpstan-sylius extension.

Key enhancements in the latest release​

The newest version of the extension introduces several notable improvements:

• Supports for the #[AsGrid] attribute: This includes considering the resourceClass configuration option to map grids to their corresponding resource classes
• Check the enum grid filter for the resource class properties

To try out the extension, you can install the latest version via Composer:

composer.phar require --dev bitexpert/phpstan-sylius

This article was particularly helpful as I had just upgraded one of our projects to PHPUnit 13 and needed to test multiple method calls.

However, I found that the article lacked information on managing return values. After testing a few approaches without success, I reached out to Sebastian, who kindly pointed me to the relevant documentation. In return, I promised to write a quick blog post covering my findings.

The newly introduced withParameterSetsInOrder() method allows you to configure a mock object to accept multiple parameter sets. Here's an example:

$issuesMock = $this->createMock(Issues::class);
$issuesMock->expects($this->exactly(2))
    ->method('create')
    ->withParameterSetsInOrder(
        [
            $projectId,
            $title,
            $description,
        ],
        [
            $projectId2,
            $title2,
            $description2,
        ],
    );

If the order of the parameter sets doesn't matter, you can use the withParameterSetsInAnyOrder() method instead.

To define the return values for each call, use the willReturn() method and list all returning values as separate parameters:

$issuesMock = $this->createMock(Issues::class);
$issuesMock->expects($this->exactly(2))
    ->method('create')
    ->withParameterSetsInOrder(
        [
            $projectId,
            $title,
            $description,
        ],
        [
            $projectId2,
            $title2,
            $description2,
        ],
    )
    ->willReturn(
        1,
        2,
    );

This will return the values 1 and 2 for the first and second calls to the mocked create() method, respectively.

In conclusion, the withParameterSetsInOrder() and willReturn() methods in PHPUnit 13 provide a convenient way to configure mock objects for multiple parameter sets and define return values for each call.

I am thrilled to announce that I will be attending and speaking at the summit, where I will share insights on how to speed up development using the Sylius Stack components.

For those unfamiliar, Sylius Stack offers a powerful set of Symfony-based packages that enable developers to create sophisticated UIs and backend logic with minimal effort.

To demonstrate the capabilities of Sylius Stack, my session will take an unconventional approach - no slides!

Instead, I will do a live coding session, providing a hands-on look at how Sylius Stack can streamline development processes. This interactive approach will allow attendees to see firsthand the benefits of using Sylius Stack and how it can revolutionize their development workflow.

See you in Paris!

Whether you're a seasoned developer or just starting out, this is your chance to contribute to Sylius, learn from the experts, and have a blast with like-minded individuals.

Meetup Highlights:

• Tideways Performance Monitoring: Benjamin Außenhofer will share insights on how to optimize your Sylius site's performance
• Laioutr Introduction: Sebastian Langer from Laioutr will introduce us to their innovative platform and demonstrate how to seamlessly connect it to Sylius
• Sylius, but different: I will showcase two exceptional Sylius implementations, highlighting the platform's flexibility and versatility

Hackathon Fun:

• Contribute to Sylius and make a real impact on the community
• Meet fellow developers, share knowledge, and learn from each other
• Who knows? You might even get to meet a member of the Sylius core team!

Don't miss this amazing opportunity to network, learn, and have fun with the Sylius community!

When: April 30th 10:00 (the meetup starts at 18:00)
Where: Mannheim (bitExpert office)
What to expect: Sylius Hackathon, Meetup, and plenty of fun
Sign up here: Meetup

A huge THANK YOU to our amazing sponsors Mollie, Laioutr, bitExpert, and Sylius who make this event possible.

As a long-time user of Hashicorp tools, including Nomad, Vault, and Boundary, I'm passionate about sharing my experiences and learnings with the community. These tools remain a crucial part of our infrastructure, and I'm excited to continue exploring their capabilities.

In the coming months, I'll be publishing a series of blog posts focused on Nomad, so be sure to stay tuned!

I'm honored to receive this recognition and look forward to ongoing knowledge-sharing and collaboration with the community.

This time, we're gathering at the DE-CIX office in Frankfurt, where we have an exciting lineup of talks in store for you.

First up, Stephan Hochdörfer will present "Fellowship of Twig", a comprehensive introduction to Twig, Symfony UX, and Sylius Twig Hooks. Learn how to build interactive UIs with ease and take your development skills to the next level.

After a short break, Thomas Bley will take the stage to share his expertise on "How to run LLMs locally".

Join us in Frankfurt for an evening of learning, networking, and fun! Secure your spot by signing up here: https://www.phpugffm.de/veranstaltungen/phpugffm-ii-2026/

We look forward to seeing you there!

Initially, I thought updating the OIDC config only required sending the changed properties, specifically the OIDCClientSecret property. Unfortunately, this approach didn't work as expected.

It turns out that even for an update, you need to send the complete OIDC config to Nomad again. This means creating a new OIDC config and updating your existing one to include the new secret.

Here's an example of what the updated config might look like:

{
  "OIDCDiscoveryURL": "https://login.microsoftonline.com/[TENANT_ID]]/v2.0",
  "OIDCClientID": "[CLIENT_ID]",
  "OIDCClientSecret": "[CLIENT_SECRET]",
  "BoundAudiences": ["[CLIENT_ID]"],
  "AllowedRedirectURIs": [
    "https://example.com/oidc/callback",
    "https://example.com/ui/settings/tokens"
  ],
  "ListClaimMappings": {
    "groups": "groups"
  }
}

Once you have your updated config, you can run the auth-method update command for the auth method oidc2 (or whatever name you chose when creating the auth method):

nomad acl auth-method update -config=@./config.json oidc2

This plugin was created to address a need that arose in a recent project, where the existing two-factor authentication plugins for Sylius were either incompatible with the latest Sylius version or no longer maintained.

The plugin is built on top of the SchebTwoFactorBundle, which is widely regarded as the de facto standard for two-factor authentication in the Symfony ecosystem. By leveraging this established bundle, we aimed to provide a reliable and secure solution for Sylius users.

Features​

• Compatible with Sylius 2.0 and higher
• Admin users and shop users can enable two-factor authentication for their accounts
• Choose between Google Authenticator or email as an authentication method
• During login users can choose which authentication method to use

Setting up two-factor authentication with our plugin is straightforward, thanks to a 3-step wizard:

During the login process, users can choose which configured authentication method to use:

Installation​

Install the plugin via Composer and follow the setup instructions:

composer require bitexpert/sylius-2fa-plugin

Let us know what you think about the plugin. We are happy to hear your feedback!

We're thankful to October Labs GmbH for hosting us once again.

Interested in attending? Simply sign up on our meetup page to secure your spot!

For those who may not be familiar, our TechRadar is a tool that helps us assess our technology portfolio objectively. It's divided into four key focus areas: Languages & Frameworks, Methods & Patterns, Tools, and Platforms & Operations.

In the "Languages & Frameworks" quadrant, the following changes occurred:

• Magento: We've moved Magento, Hyvä Themes, and TechDivision Pacemaker to the "hold" state. This doesn't mean we won't be working on Magento projects anymore, but it's no longer a core focus for us.
• Sylius Stack and Symfony UX: We've moved these technologies to the "trial" state, as we've seen promising results in recent projects and plan to invest more in them.
• Symfony AI: We've added Symfony AI to the "assess" state, recognizing the growing importance of AI in our projects and the potential benefits of having a tool from the Symfony ecosystem.
• Spring Boot: After years of using Spring Boot, we've finally moved it to the "adopt" state, reflecting our confidence in its capabilities

In the "Tools" quadrant, the following changes happened:

• Bun and Playwright: We've moved these tools to the "trial" state for further evaluation.
• Documenso: We've added Documenso to the "assess" state, recognizing its potential value for us.
• JetBrains AI: We've decided to drop JetBrains AI, as it didn't meet our expectations.
• OpenCode: We've added OpenCode to the "assess" state as a potential replacement for JetBrains AI.
• Onyx: We're evaluating Oynx as a promising replacement for our current OpenWebUI stack.

These changes reflect our ongoing efforts to stay up-to-date with the latest technologies and trends, and to ensure that our tech stack remains aligned with our goals and priorities. We're excited to see how these changes will impact our projects and look forward to sharing more updates in the future.

In addition to attending the conference, I've been invited by our partner SCHUFA to speak at their booth about the benefits of Gally, our AI-powered searchandising solution. I'll be sharing how Gally can help merchants strategically increase sales and drive business growth.

You can catch my talks at the SCHUFA booth on:

• February 17th at 14:00
• February 18th at 11:00

I'm looking forward to meeting you there! Don't miss out on the opportunity to learn more about how Gally can boost your sales - see you at the SCHUFA booth!

A recent project sparked an interesting question: Is it possible to use a single OpenSearch cluster for multiple environments, such as test, staging, and production instances, instead of deploying a separate instance for each setup.

Fortunately, the answer is yes.

To achieve this, you can define an index prefix in the config/packages/gally.yaml configuration file like so:

gally:
  indices_settings:
    prefix: test_

Alternatively, you can utilize the new backoffice functionality in Gally 2.2 to define index prefixes. To do so, follow these steps:

• Go to the Settings page.
• Navigate to Configurations > Index.
• In the Index prefix field, enter your preferred prefix.

This approach is particularly beneficial for smaller setups, as it allows you to manage just one OpenSearch instance, streamlining your searchandising infrastructure.

SpeaKonf – an idea I had 10 years ago, but never found the time to develop it further.

Thanks to JUG Darmstadt and Falk Sippach, the event is taking place for the fourth time in Darmstadt, Germany on the 20th of March 2026. And once again we are supporting the event.

Sounds interesting? Secure your spot at SpeaKonf by getting your tickets here. We look forward to seeing you in Darmstadt in March!

In contrast to traditional Twig Components, which require both a class and a template, anonymous template components are self-contained templates that define the component directly within the template itself.

Consider a file named templates/components/Button/Primary.html.twig with the following content:

<button {{ attributes.defaults({class: 'primary'}) }}>
    {% block content %}{% endblock %}
</button>

The file's location and directory structure allow us to reference this component as Button:Primary. To include this component in a template, you can use the following syntax:

<div>
   <twig:Button:Primary>I am a button!</twig:Button:Primary>
</div>

In the context of anonymous template components, the component name is tightly coupled with the directory structure. However, Sylius provides a flexible solution to this constraint. With Sylius, you can:

• define custom prefixes for your components
• specify a custom directory structure where these components are stored

This feature allows for greater control and organization of your components, making it easier to manage and maintain your template components.

To take advantage of Sylius's anonymous template component feature, you need to define a prefix and its corresponding directory structure in your configuration. For example, you can add the following configuration:

sylius_ui:
    twig_ux:
        anonymous_component_template_prefixes:
            my_shop: 'shop/shared/my_components'

This configuration tells Sylius to look for templates with the my_shop prefix in the shop/shared/my_components directory.

Once you've defined the prefix and directory structure, you can create a template in the specified directory. For instance, you can create a my_button.html.twig template in the shop/shared/my_components directory.

To use this template in your Twig template, reference it using the component file name and the defined prefix:

{{ component('my_shop:my_button') }}

By using anonymous component prefixes, you can keep your templates organized and structured in a way that makes sense for your Sylius application, making it easier to maintain and manage your codebase.

While checking the docs, I realized that Renovate Bot does not apply language constraints to upgrades at all.

Fortunately, Renovate Bot allows you to define language constraints for dependency upgrades, providing a solution to this problem. To resolve the issue, we added the following configuration to the renovate.json file:

{
  "constraints": {
    "php": "8.4.x",
    "composer": "2.x"
  } 
}

By implementing this constraint configuration, we can ensure that Renovate Bot consistently uses PHP 8.4 and Composer 2 for dependency updates.

However, this setup has a trade-off: once PHP 8.4 and Composer 2 become outdated, Renovate will no longer automatically update them. Instead, you will need to manually update these versions to keep them current.

Two of my talk proposals have been accepted. In the first talk, I'll be talking about how Gally is enhancing your customers' search experience.

What is Gally? Gally is a highly advanced searchandising engine built on top of Symfony, API Platform, and Elasticsearch that allows you to build an API-first e-commerce search engine with ease. I will walk you through the process of setting up and configuring Gally as well as the Gally bundle for Sylius.

The second talk is brand new talk with the title "The Fellowship of Twig".

This talk explores the powerful combination of Twig, Twig Hooks, and Live Components, enabling backend developers to create highly interactive and reusable frontend components without relying on a complex JavaScript framework.

See you in February!

We're excited to introduce a new feature that makes it easier for you to find what you're looking for: a search function. You can now search all our blog posts using the search bar located in the top right corner of this page.

Initially, we're using the docusaurus-search-local package to power our search. As we continue to improve, we may upgrade to a more advanced search engine in the future.

We'd love to hear your thoughts on this new feature. Let us know what you think!

Following some research and testing, I discovered the necessary commands to complete the task.

To generate the image cache for each file in the public/media/image directory, you can use the Symfony Console command liip:imagine:cache:resolve, which takes a file as an argument and updates its corresponding cache:

cd public/media
find image -type f -print0 | xargs -0 -I {} php ../../bin/console liip:imagine:cache:resolve {}