Alexander M. Turek will share his insights on designing Symfony applications that can adapt to change without major disruptions. He will explore architectural choices that keep core business logic stable while technology evolves, giving your application a powerful long-term advantage.

Stiven Llupa will discuss how to apply traditional software engineering principles to AI-powered platforms that offer limited support for these practices. He will take you through a real-world example, following a small function from start to finish, to demonstrate the challenges and opportunities of working with these platforms.

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

What is the Symfony Security Auditor?​

The Symfony Security Auditor is a multi-agent security auditor for Symfony applications. It uses an adversarial Attacker and Reviewer loop to catch application-level flaws that other tools might miss. Built on top of the symfony/ai platform, it's provider-agnostic, which is a significant advantage for us since we self-host models or use those provided by the IONOS AI Model Hub.

The Auditor consists of two parts:

• An adversarial Attacker agent that hunts for vulnerabilities.
• A skeptical Reviewer agent that culls false positives over up to three iterations and then emits a validated report in various formats (console, JSON, SARIF, HTML, or Markdown).

How to install​

You can install the Auditor as a standalone tool or add it as a dev dependency to your project. For testing purposes, I chose the latter.

composer require --dev vinceamstoutz/symfony-security-auditor

Since we run our own AI gateway, I also installed the symfony/ai-generic-platform bundle to ensure the Auditor can communicate properly with our AI gateway.

Next, I configured the AI gateway URL and access token in the config/packages/ai_generic_platform.yaml config file:

ai:
    platform:
        generic:
            default:
                base_url: 'https://ai-gateway.loc'
                api_key: 'my-random-api-key'

Note that the base URL should not include the /v1 postfix, just the base url.

I also configured which model to use in the config/packages/symfony_security_auditor.yaml file:

when@dev: &symfony_security_auditor
  symfony_security_auditor:
    model: 'qwen3.8-28b'

For my first test, I used the Qwen 3.8 28B model, which worked fine.

How to run the Auditor​

Once everything is configured, you can run the Auditor with this command:

./bin/console audit:run --format markdown --output report.md

Running the Auditor takes some time, depending on your project size and complexity. My first test ran for about 35 minutes.

The generated Markdown file contains all findings ranked by severity (e.g., critical, high, medium, or low). A finding looks like this:

### 🟠 HIGH — Open redirect in OAuthAuthenticator base class (third occurrence)

- **Type:** `open_redirect` (OWASP A01:2025 - Broken Access Control, CWE-601)
- **Location:** `src/Security/OAuth/OAuthAuthenticator.php:43-48`
- **Confidence:** 70%

OAuthAuthenticator::onAuthenticationSuccess retrieves the target path from the session using getTargetPath()
and returns a RedirectResponse to it without validation. Since OAuth flows are triggered via route matching
and may involve user redirection after login, an attacker could manipulate the _target_path parameter to 
redirect the user to an external site after OAuth authentication succeeds.

**Vulnerable code:**
if (($targetPath = $this->getTargetPath($request->getSession(), $firewallName)) !== null) {
  return new RedirectResponse($targetPath);
}

return new RedirectResponse($this->router->generate('app_index'));

**Attack vector:** 
1. Attacker initiates OAuth flow with a manipulated redirect state (e.g., via session poisoning or pre-filled _target_path).
2. User completes OAuth authentication.
3. OAuthAuthenticator::onAuthenticationSuccess retrieves the unsanitized $targetPath.
4. User is redirected to an external domain, enabling phishing or session theft.

You can then feed these findings into your coding agent and let the agent work on this task.

You can then feed these findings into your coding agent and let it work on this task.

After running the Auditor multiple times, I encountered some OpenSSL SSL_read. I prepared a Pull Request with some changes and increased the retry limit (symfony_security_auditor.audit.retry.max_attempts) to 5 to make the Auditor work again.

Conclusion​

The initial report proved to be very valuable. I ran it against a legacy code base, and it was helpful to get these findings back. Feeding the results into my coding agent (running a different model) and letting the coding agent judge and provide feedback helped understand which of the mentioned issues needed to be solved and which were reported as false positives.

In modern JavaScript tooling, Hot Module Replacement (HMR) is the standard. The frontend refreshes automatically when files change, simplifying development.

In traditional PHP, we didn't have this workflow, but with FrankenPHP's hot reloading, the server watches for filesystem changes and pushes Mercure updates to the browser. Depending on your setup, the DOM will be morphed (this needs Idiomorph to be available) or as fallback, the page gets reloaded.

Important: Hot reload is for development environments only and should not be enabled in production, as it's not secure and slows down the application.

How to enable Hot Reload (server side)​

To enable the hot reload feature in FrankenPHP, you need to:

1. Enable Mercure in your Caddyfile:

mercure {
    anonymous
}

2. Enable hot_reload in the php_server configuration section:

php_server {
    hot_reload
}

By default, the server process watches all files with specific extensions ./**/*.{css,env,gif,htm,html,jpg,jpeg,js,mjs,php,png,svg,twig,webp,xml,yaml,yml} in the current working directory.

You can explicitly configure a file list by passing a list to the hot_reload configuration:

php_server {
    hot_reload src/**/*{.php,.js} config/**/*.yaml
}

How to enable Hot Reload (client side)​

To make the browser aware of hot reload, include the following snippet in your templates:

Generic PHP Application​

<?php if (isset($_SERVER['FRANKENPHP_HOT_RELOAD'])): ?>
<meta name="frankenphp-hot-reload:url" content="<?=$_SERVER['FRANKENPHP_HOT_RELOAD']?>">
<script src="https://cdn.jsdelivr.net/npm/idiomorph/dist/idiomorph.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/frankenphp-hot-reload/+esm" type="module"></script>
<?php endif ?>

Symfony/Twig​

{% if app.request.server.has('FRANKENPHP_HOT_RELOAD') %}
    <meta name="frankenphp-hot-reload:url" content="{{ app.request.server.get('FRANKENPHP_HOT_RELOAD') }}">
    <script src="https://cdn.jsdelivr.net/npm/idiomorph/dist/idiomorph.min.js"></script>
    <script src="https://cdn.jsdelivr.net/npm/frankenphp-hot-reload/+esm" type="module"></script>
{% endif %}

Sylius​

Add this to your templates/shop/javascripts.html.twig template file:

{% if app.request.server.has('FRANKENPHP_HOT_RELOAD') %}
    <meta name="frankenphp-hot-reload:url" content="{{ app.request.server.get('FRANKENPHP_HOT_RELOAD') }}">
    <script src="https://cdn.jsdelivr.net/npm/idiomorph/dist/idiomorph.min.js"></script>
    <script src="https://cdn.jsdelivr.net/npm/frankenphp-hot-reload/+esm" type="module"></script>
{% endif %}
{{ encore_entry_script_tags('app-shop-entry', null, 'app.shop') }}

In conclusion, FrankenPHP's hot reload feature simplifies development by automatically refreshing the frontend when files change. Remember to only use this feature in development environments, as it's not secure for production.

To avoid adding extra components to our stack, I looked for a solution that would integrate easily with our existing Traefik Proxy setup. I came across the Traefik OIDC plugin which supports a wide range of Identity Providers, including Google, Azure, Auth0, Okta, Keycloak, Cognito, GitLab, and GitHub, making it perfect for our use case.

To install the plugin, add the following lines to your static Traefik configuration:

experimental:
  plugins:
    traefikoidc:
      moduleName: github.com/lukaszraczylo/traefikoidc
      version: v1.0.29

In your dynamic Traefik configuration, add the plugin configuration for the traefikoidc middleware that will be referenced later in your application Traefik configuration. In case of Entra ID as Identity Provider, configure your TenantId, ClientId, Client Secret, and the session encryption key accordingly:

http:
  middlewares:
    entra-oidc:
      plugin:
        traefikoidc:
          providerURL: "https://login.microsoftonline.com/<TENANT_ID>/v2.0"
          clientID: ""
          clientSecret: ""
          sessionEncryptionKey: ""
          callbackURL: "/oauth2/callback"
          logoutURL: "/oauth2/logout"
          postLogoutRedirectURI: "/"
          forceHTTPS: true
          sessionMaxAge: 28800

Now, in your application configuration for Traefik, add the label referencing the entra-oidc@file middleware defined above and Traefik will handle the whole authentication flow for you:

traefik.http.routers.my-app.middlewares=entra-oidc@file

The whole Docker service definition looks like this:

services:
  my-app:
    image: traefik/whoami
    expose:
      - "80"
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.my-app.rule=Host(`foo.bar`)"
      - "traefik.http.routers.my-app.entrypoints=websecure"
      - "traefik.http.routers.my-app.tls=true"
      - "traefik.http.routers.my-app.tls.certresolver=letsencrypt"
      - "traefik.http.routers.my-app.middlewares=entra-oidc@file"
      - "traefik.http.services.my-app.loadbalancer.server.port=80"

Using the Traefik OIDC plugin made perfect sense for us. It was easy to integrate, supports a variety of Identity Providers, and allows us to still rely on Traefik for all routing rules. This solution efficiently secures our application without adding unnecessary complexity to our stack.

By accident, I came across this GitHub repo that had already done the heavy lifting for fine-tuning Qwen 3.8 with vLLM on a NVIDIA DGX Spark. The task left to do was to convert the configuration from a shell script to our Nomad job file.

First, I launched a new Docker container and downloaded the Qwen 3.8 model from Hugging Face using the following commands:

docker run -it -v /var/nomad/data/host_volumes/da12a803-152e-83d4-049d-81e11d4adf5a/:/opt/vllm nvcr.io/nvidia/vllm:26.06-py3 bash

hf download unsloth--Qwen3.8-27B-NVFP4

After completing the model download, I submitted the Nomad job file to our cluster:

job "vllm.prod" {
  datacenters = ["dc1"]
  type        = "service"
  node_pool   = "gpu"

  group "vllm" {
    count = 1

    network {
      port "app" {
        to = 8000
        host_network = "vpn"
      }
    }

    volume "vllm.prod" {
      type            = "host"
      source          = "vllm.prod"
      access_mode     = "single-node-writer"
      attachment_mode = "file-system"
    }

    restart {
      attempts = 3
      interval = "30m"
      delay    = "45s"
      mode     = "fail"
    }

    task "server" {
      driver = "docker"

      vault {
        change_mode   = "signal"
        change_signal = "SIGUSR1"
      }

      template {
        data        = <<EOH
HUGGING_FACE_HUB_TOKEN=YOUR_TOKEN_HERE
HF_HOME=/opt/vllm/hf
HF_HUB_CACHE=/opt/vllm/hf/hub
VLLM_FLOAT32_MATMUL_PRECISION=high
VLLM_ALLOW_LONG_MAX_MODEL_LEN=1
UCX_RCACHE_MAX_UNRELEASED=1024
CUTE_DSL_ARCH=sm_121a
TRITON_CACHE_DIR=/opt/vllm/.triton
EOH
        destination = ".env"
        env         = true
      }

      config {
        image      = "nvcr.io/nvidia/vllm:26.06-py3"
        force_pull = true
        ports      = ["app"]
        args = [
          "vllm",
          "serve",
          "/opt/nim/.cache/hf/hub/models--unsloth--Qwen3.8-27B-NVFP4/snapshots/7d6f8d4d72f56b92b3cdbf22f156b90e1bab0108",
          "--served-model-name",
          "Qwen/Qwen3.8",
          "--tensor-parallel-size",
          "1",
          "--quantization",
          "compressed-tensors",
          "--attention-backend",
          "triton_attn",
          "--trust-remote-code",
          "--enable-auto-tool-choice",
          "--tool-call-parser",
          "qwen3_coder",
          "--reasoning-parser",
          "qwen3",
          "--skip-mm-profiling",
          "--default-chat-template-kwargs",
          jsonencode({
            enable_thinking = false
          }),
          "--enable-prefix-caching",
          "--enable-chunked-prefill",
          "--block-size",
          "64",
          "--gpu_memory_utilization",
          "0.84",
          "--max-num-seqs",
          "4",
          "--max-num-batched-tokens",
          "8192",
          "--max-model-len",
          "1000000",
          "--speculative-config",
          jsonencode({
            "method": "mtp",
            "num_speculative_tokens": 2
          }),
          "--hf-overrides",
          jsonencode({
            "text_config": {
              "rope_parameters": {
                "mrope_interleaved": true,
                "mrope_section": [11, 11, 10],
                "rope_type": "yarn",
                "rope_theta": 10000000,
                "partial_rotary_factor": 0.25,
                "factor": 4.0,
                "original_max_position_embeddings": 262144
              }
            }
          }),
          "--api-key",
          "some_api_key",
        ]

        runtime = "nvidia"
        ipc_mode = "host"
        ulimit {
          memlock = "-1:-1"
          stack   = "67108864:67108864"
        }
      }

      volume_mount {
        volume      = "vllm.prod"
        destination = "/opt/vllm"
        read_only   = false
      }

      resources {
        cpu    = 45000
        memory = 100000
        device "nvidia/gpu" {
          count = 1
        }
      }

      service {
        name     = "vllm-prod"
        provider = "nomad"
        port     = "app"

        check {
          name     = "alive"
          type     = "tcp"
          interval = "10s"
          timeout  = "2s"

          check_restart {
            limit           = 3
            grace           = "55m"
            ignore_warnings = false
          }
        }
      }
    }
  }
}

By leveraging existing configurations and converting them for our Nomad setup, we were able to efficiently deploy the Qwen 3.8 model on our NVIDIA DGX Spark device. This approach not only saved time but also ensured compatibility and optimal performance.

The catch?​

Just 10 days of time. When I learned about the hackathon last Sunday, I only had 4 days left to come up with a project idea and the implementation. Still, I decided to take the challenge.

What is WebMCP?​

WebMCP enables web applications to provide JavaScript-based tools to AI agents, allowing them to easily interact with the web application. Without WebMCP, AI agents have to parse HTML code to understand site structure and functionality. WebMCP simplifies this process by specifying callable functions and their arguments, enabling faster interaction with web applications.

The plan?​

Being an e-commerce enthusiast, I wanted to create some kind of e-commerce integration. However, not the usual boring "let's add a product to a cart" feature. And being sold on the Sylius platform, I knew I wanted to build a Sylius plugin.

The first thing I did was to brainstorm with my AI coding agent about what to build. We toyed around with several ideas, but one stood out:

The Wishlist Concierge is an agent + human co-curation themed, budget-aware wishlist solution for Sylius. Instead of clicking 30 filters, customers can tell their agents “birthday for my nephew” and the AI agent will search taxonomies, build a wishlist, optimize for budget, and move the best fit to cart.

The initial prototype was quickly built. However, running the first tests was challenging since this is still an experimental feature hidden behind a feature flag in the Chrome browser. At first, I tried using playwright-cli in combination with the Playwright skill, but that did not properly work for some reason. I then moved on to install the ChatGPT desktop application, and that made testing quite smooth.

In the end, the Sylius plugin exposes about 12 WebMCP tools to the AI agent, from product search to creating wishlists, adding and removing products from a wishlist, and converting a wishlist into a cart.

I managed to sneak in a few nice features, e.g. the plugin is using a custom #[ModelContextTool] attribute to annotate controller methods. Via a separate endpoint, the data is collected, and the Javascript frontend registers all tool calls with the WebMCP API:

final class WishlistController extends AbstractController
{
    #[ModelContextTool(
        name: 'wishlist.create',
        description: 'Create a new themed wishlist. The active channel is automatically inferred from the current Sylius context. Theme examples: birthday, gift, summer, casual, formal. Name should be human readable like "Birthday Wishlist — $150".',
        dtoClass: WishlistCreateRequest::class,
        emitsEvents: ['webmcp:wishlist-created'],
        routeName: 'bitexpert_concierge_wishlist_create',
    )]
    public function create(Request $request): JsonResponse
    {
    }
}

Participating in the OpenAI WebMCP Challenge was a valuable experience, providing good insights into the potential of WebMCP and AI agents in e-commerce transactions.

The Wishlist Concierge plugin has sparked ideas for future projects, potentially leading to a conference talk. Stay tuned for more!

This is where Doctrine Doctor comes into play. It is a Symfony bundle that extends the Symfony Web Profiler bar to analyze database queries in real-time.

What is Doctrine Doctor?​

Doctrine Doctor analyzes the actual execution context of your Doctrine queries, including parameters, data volume, and query plans, to identify runtime issues such as N+1 queries, missing indexes, and MySQL configuration problems.

Installing Doctrine Doctor​

To get started with Doctrine Doctor, run the following command in your terminal:

composer require --dev ahmed-bhs/doctrine-doctor

After installation, you'll see Doctrine Doctor in action in the Symfony Profiler bar.

Features and Capabilities​

Doctrine Doctor boasts over 90 specialized analyzers for performance, security, integrity, and configuration issues. It can detect issues like:

1. Initialization problems, such as collections not being properly initialized

2. Configuration issues, like a property storing money information using incorrect decimal places

AI Mate / MCP Integration​

For automated issue detection and fixing, Doctrine Doctor offers an optional AI Mate / MCP integration. To enable this feature, update your mate/extensions.php config file as follows:

return [
    'ahmed-bhs/doctrine-doctor' => ['enabled' => true],
    'symfony/ai-symfony-mate-extension' => ['enabled' => true],
];

By following the steps outlined above, you can improve the performance and reliability of your Symfony applications. To further enhance your skills, I recommend checking out the official Doctrine Doctor documentation and experimenting with its features in your own projects.

The initial approach involved querying the certificate during Docker build time from Vault like this:

CERT=$(curl -s -H "X-Vault-Token:$VAULT_TOKEN" -XGET $VAULT_ADDR/v1/nomad/data/job.prod/certs | jq -r .data.data.CERTIFICATE)

However, this method had a significant downside: upon certificate renewal, we had to update all our Docker images and redeploy them. Over time, as we added this to more Docker images, we occasionally forgot to update an image.

To address this issue, we decided to change our procedure. Now, Nomad retrieves certificates from Vault, and the Docker entrypoint script processes the data if needed. Although this slightly increases startup time, the benefits outweigh the costs. As a bonus, whenever we change the certificate in Vault, the Nomad jobs are notified and re-rendered with the updated certificate.

In our Nomad job file, we populate a template block to fetch the certificate from Vault:

template {
  data = <<EOH
{{ with secret "job.prod/certs" }}
{{- .Data.data.CERTIFICATE -}}
{{ end }}
EOH
  destination = "secrets/cert.pem"
} 

Then, in the Docker configuration, we mount the /secrets directory to the container and read the certificate from there:

config {
  image      = "nexus.loc/app:1.0.1"
  command    = "/usr/local/bin/entrypoint.sh"
  volumes    = [
    "secrets:/secrets",
  ]
}

By leveraging Nomad and Vault, we've streamlined our certificate management process, eliminating the need for manual updates upon renewal. This approach has improved our deployment efficiency and reduced the likelihood of errors.

Thanks to DDEV's flexibility, completing this task was relatively straightforward. Let me walk you through the process.

First, we need to install Odoo in the DDEV Docker image. This is achieved by adding a file named .ddev/web-build/Dockerfile.odoo, which contains additional Dockerfile commands that DDEV will append to its own Dockerfile. These commands include installing extra packages, as well as installing Odoo from its official Debian repository.

However, I encountered a problem at this stage: The DDEV Docker image is based on Debian Trixie, which is not fully supported by Odoo. In fact, Odoo depends on the python3-pypdf2 package, which is no longer available in Debian Trixie. Instead, you need to install the python3-pypdf package. This means that Odoo is not installable out of the box on Debian Trixie, unless you install it from source.

After discussing all options with my Coding agent, I decided the best way to fix this is building and installing a fake python3-pypdf2 package which resulted in this code:

mkdir /tmp/pypdf2-fake \
    && cd /tmp/pypdf2-fake \
    && printf '%s\n' \
        'Section: misc' \
        'Priority: optional' \
        'Package: python3-pypdf2' \
        'Version: 9999.0' \
        'Architecture: all' \
        'Description: Dummy package for python3-pypdf2' \
        ' This package is provided by Debian python3-pypdf.' \
        > control \
    && equivs-build control \
    && dpkg -i ./python3-pypdf2_9999.0_all.deb \
    && rm -rf /tmp/pypdf2-fake

The complete version of the .ddev/web-build/Dockerfile.odoo Dockerfile I added to my project looks like this:

# Install required tools needed by Odoo
RUN apt-get update && apt-get install -y wget gnupg ca-certificates	equivs python3-ldap python3-pypdf python3-venv

# Prepare a fake python3-pypdf2 as Odoo has a hard dependency on this package but it is no longer available in Trixxie
RUN mkdir /tmp/pypdf2-fake \
    && cd /tmp/pypdf2-fake \
    && printf '%s\n' \
        'Section: misc' \
        'Priority: optional' \
        'Package: python3-pypdf2' \
        'Version: 9999.0' \
        'Architecture: all' \
        'Description: Dummy package for python3-pypdf2' \
        ' This package is provided by Debian python3-pypdf.' \
        > control \
    && equivs-build control \
    && dpkg -i ./python3-pypdf2_9999.0_all.deb \
    && rm -rf /tmp/pypdf2-fake

# Add Odoo repository
RUN wget -O - https://nightly.odoo.com/odoo.key | gpg --dearmor -o /usr/share/keyrings/odoo-archive-keyring.gpg

RUN echo "deb [signed-by=/usr/share/keyrings/odoo-archive-keyring.gpg] https://nightly.odoo.com/19.0/nightly/deb/ ./" > /etc/apt/sources.list.d/odoo.list

# Install Odoo
RUN apt-get update && apt-get install -y odoo

To ensure the /var/lib/odoo directory persists across restarts, I created an additional Docker Compose file .ddev/docker-compose.odoo.yaml that mounts the directory to a Docker volume.

services:
  web:
    volumes:
      - ddev-odoo:/var/lib/odoo

volumes:
  ddev-odoo:
    name: ddev-odoo

By default, DDEV starts nginx with php-fpm to serve requests. However, we need to run Odoo server instead and expose it to the Traefik proxy that DDEV uses to route requests to the container. Luckily, DDEV supports generic web servers, as documented in their official documentation, since early 2025.

All it takes is some additional configuration. To achieve this, I created a file named .ddev/config.odoo.yaml with the following content:

webserver_type: generic
web_extra_daemons:
  - name: "odoo"
    command: "odoo -c /var/www/html/.ddev/odoo/odoo.conf"
    directory: /var/www/html
web_extra_exposed_ports:
  - name: "odoo"
    container_port: 8069
    http_port: 80
    https_port: 443

The final piece of the puzzle is the Odoo configuration file. To add this, you'll need to create a file named .ddev/odoo/odoo.conf, which will contain the necessary Odoo configuration settings:

[options]
addons_path = /var/www/html/odoo_addons
data_dir = /var/lib/odoo
db_name = db
db_host = db
db_port = 5432
db_user = db
db_password = db
smtp_password =
smtp_user =
smtp_port = 1025
smtp_server = mailpit
smtp_ssl = False
email_from = odoo@example.com

In the root of my project, I created a directory named odoo_addons to store the Odoo modules I want to develop.

To initialize the DDEV setup, run ddev start. This command will build and start the DDEV environment.

Once the setup is up and running, I created the database and Odoo admin user by running:

ddev exec odoo db init db --force --username admin@example.com --password 'odoo123#'

Every day, new tools emerge on GitHub to solve this problem. To find the best tool for your needs, you'll need to try them out. My go-to tool is Engram, a Go binary with an SQLite backend that includes FTS5 full-text search capabilities and can be accessed via CLI, HTTP API, an MCP server implementation, and an interactive TUI.

Installing Engram​

To get started with Engram, download the latest release from the GitHub releases page.

Configuring your Coding agent​

Engram supports a variety of different agents, in my case I am using OpenCode. For OpenCode the installation procedure is as follows:

engram setup opencode

This command adds Engram as an MCP server to your coding agent's config file and installs a plugin for the chosen agent. The plugin ensures the memory is regularly updated.

Usually, the Coding agent plugin will make sure to update the memory in regular intervals. However, if you tell the agent to do so manually, it will also work. I sometimes do this to make sure the latest learnings are documented for future use.

Why Engram?​

I chose Engram for several reasons:

• As a standalone binary with no extra dependencies, Engram is easy to install
• Engram integrates seamlessly with my coding agent, and the interaction via the agent is smooth
• The TUI mode is helpful for viewing documented memories
• Memory Sharing: Memories can be shared via Git with the development team or by running Engram as a self-hosted service

By using Engram, I've improved my coding agent's long-term memory, enabling it to learn and remember over time. Give Engram a try to see how it can enhance your coding agent's capabilities.

What's New in Gally 2.3​

Gally 2.3 offers significant updates, including:

• A new recommender feature
• Visitor tracking
• Search term suggestions
• API Platform 4.2 Update and support for PHP 8.4 and later

To get the latest version of our DDEV addon, compatible with Gally 2.3, you can use the following commands:

ddev add-on get bitExpert/ddev-gally
ddev restart

The first time you run the addon, it will build a Gally Docker image from scratch, and this may take a few minutes to complete.

With these updates, you can now integrate Gally 2.3 into your development environment using our DDEV addon. Enjoy the new features and improved performance!

We're excited to welcome Elizabeth Barron as our guest speaker. As the Executive Director of The PHP Foundation, Elizabeth will introduce us to the foundation's mission and share insights into upcoming plans.

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

How did we approach the migration?​

First, we reviewed the plugins used in our Sylius 1 instance and checked their availability for Sylius 2. Some plugins, like Setono Terms plugin and Setono Redirects plugin, required updates, which we completed and submitted as PRs on GitHub.

The CustomOptionsPlugin from Brille24 posed a significant challenge, as it was a key requirement for our ticket sales flow but lacked a Sylius 2 compatible version. In the end, we decided to build our own simplified version, leveraging AI coding agents to mimic the Sylius attribute system. This approach allowed us to learn how to work with coding agents in a real-world project as well as build a solution that exactly matches our limited requirements.

Transitioning the frontend from Sylius 1 to Sylius 2 was more effort due to changes in HTML and Twig structure. Even though we've been using the Sylius Bootstrap Theme before, there have been a lot of structural changes that we had to adapt to. While we could reuse the styling for isolated components like our countdown component, other parts like the main menu bar, the product details page or the checkout had to be rebuilt from scratch.

We started our development with a clean Sylius 2 setup using DDEV which is our default project setup method. First, we installed the necessary plugins and ported the existing backend logic over. The latter was simple, basically just a copy-and-paste task. Once we got the backend functionality working, we focused on getting the frontend to look right.

Plugins we are using​

We are using the following 3rd party plugins in our ticket shop project:

• SyliusEUVatPlugin for EU VAT validation and tax handling
• SyliusHomepagePlugin and SyliusCmsBlockPlugin for content management
• SyliusSettingsPlugin for storing global shop configurations
• NelmioSecurityBundle to manage Content Security Policy headers
• SyliusRedirectPlugin for managing redirects
• SyliusTermsPlugin for managing terms and conditions acceptance
• InvoicingPlugin for generating invoices
• MolliePlugin for payment handling
• Our own SyliusOrderRevocationPlugin for compliance with EU Directive 2023/2673 - also known as the "revocation button"

Additionally, we've developed a few custom Twig components to fetch the main menu structure and sponsors component from our main Sulu website, ensuring data consistency.

Conclusion​

Although we started with a solid foundation - a codebase compatible with Sylius 1.14 and a Bootstrap CSS-based frontend - the migration to Sylius 2 still required significant effort.

Was it worth the effort?​

Overall Sylius 2 has simplified several aspects of our workflow. For instance, we use net pricing internally, as we need to sell tickets without VAT to companies outside of Germany. In Sylius 1, we worked around this by displaying the gross price from a separate product property and used the net price for the regular calculations. With Sylius 2, we were able to override the relevant components to display the gross price in the frontend while calculating with the net price in the background.

Also, operating a Sylius store gives us a unique merchant-centric perspective, which proves invaluable in our project work.

By the way, the unKonf ticket sale started last week! If you're interested in attending this year's event, act fast - tickets will sell out quickly. Trust my words.

Recently, we ran an issue with Onyx consuming about 50 idle PostgreSQL connections, which caused problems when deploying additional tools in our application cluster.

My first approach was to use pgbouncer to address the issue. However, Onyx itself was unable to handle pgbouncer's connection pooling and failed to start properly.

I opened an issue on GitHub, and fortunately, the Onyx team had already resolved the problem.

We now have two options to manage PostgreSQL connections:

1. Use Onyx's connection pooling feature: We opted for this approach. You can configure the connection pool and overflow buffer size using the POSTGRES_API_SERVER_POOL_SIZE and POSTGRES_API_SERVER_POOL_OVERFLOW environment variables.
2. Disable connection pooling and use pgbouncer: To disable Onyx's connection pooling feature, set the POSTGRES_USE_NULL_POOL environment variable to true.

Adjusting Onyx's internal connection pool settings resolved the issue for us. By choosing one of the two available options, you can effectively manage PostgreSQL connections and avoid potential deployment issues.

I discovered the codebase-memory-mcp on GitHub a few months ago. It's a single, static binary that enhances code base search in your coding agent.

How to install?​

To get started, download the latest release from GitHub and install the binary on your machine.

You can choose between the CLI-only version and the UI variant with 3D graph visualization. For now, I opted for the simple CLI-only version.

How to configure OpenCode?​

To integrate codebase-memory-mcp with OpenCode, add the following MCP (Memory Computation Protocol) configuration to your OpenCode config file:

{
    "$schema": "https://opencode.ai/config.json",
    "mcp": {
        "codebase-memory-mcp": {
            "type": "local",
            "command": ["/usr/local/bin/codebase-memory-mcp"],
            "enabled": true
        }
    }
}

How to use codebase-memory-mcp?​

It starts with indexing a new codebase. Run the command Index this project to start this process. Once the indexing is complete, OpenCode will start searching for code via the codebase-memory-mcp server.

Conclusion​

I'm impressed with codebase-memory-mcp's simplicity and ease of use. As a single, static binary, it's easy to install and works well with our PHP projects (Symfony/Sylius).

Not using PHP? No worries, it supports about 158 languages, making it a versatile tool for any development team. Moreover, it's not limited to just programming languages; it also handles Infrastructure-as-code indexing, including Dockerfiles and Kubernetes manifests.

Overall, codebase-memory-mcp has become an indispensable tool in my development workflow, and I highly recommend it to any developer or team looking to supercharge their code search and management capabilities.

In many cases, the default grid configuration might not fully meet your requirements. This is where customization comes into play.

While Sylius provides a YAML configuration approach for customizing grids, I prefer using PHP event listeners for their flexibility. With event listeners, you can use conditions to show or hide fields or actions, making your customizations more dynamic.

Let's create an event listener class to add a new field to the Admin Customer Grid. Here's an example implementation:

<?php

declare(strict_types=1);

namespace App\Grid\Admin;

use Sylius\Component\Grid\Definition\Field;
use Sylius\Component\Grid\Definition\Filter;
use Sylius\Component\Grid\Event\GridDefinitionConverterEvent;

final class CustomerGridListener
{
    public function editFields(GridDefinitionConverterEvent $event): void
    {
        // get the grid instance
        $grid = $event->getGrid();

        // create a new field and add it to the grid
        $field = Field::fromNameAndType('my_new_field', 'twig');
        $field->setLabel('app.ui.my_new_field');
        $field->setPath('.');
        $field->setOptions(['template' => 'admin/grid/fields/my_new_field.html.twig']);
        $grid->addField($field);
    }
}

In this example, we create a new field called my_new_field and add it to the grid using the addField() method.

But how does the event listener know which grid to modify? The answer is service tags.

To make Sylius aware of the event listener and bind it to a specific grid, you need to add a service definition to your services.yaml file:

App\Grid\Admin\CustomerGridListener:
  class: App\Grid\Admin\CustomerGridListener
  tags:
    - { name: kernel.event_listener, event: sylius.grid.admin_customer, method: editFields }

Here, we define the CustomerGridListener service and tag it with the kernel.event_listener tag. We also specify the grid name sylius.grid.admin_customer and the method to call editFields().

Customizing Sylius grids using PHP event listeners provides a flexible and powerful way to tailor your grids to your specific needs. By following this approach, you can add custom columns, filters, and actions to your grids, making them more useful and user-friendly.

This message greeted me after submitting the job:

I was confused. In the past 8 years of working with Nomad, I had never come across a similar error. I tried resubmitting the job again, but the same error occurred. I attempted it once more, and the same error persisted.

However, when I resubmitted a different job on the same node, there was no error at all. This only added to my confusion.

I decided to restart the Nomad daemon by running systemctl restart nomad and the error disappeared.

Problem solved. But I am still confused.

However, Repman is no longer actively maintained, leaving us with outdated PHP and Symfony versions behind. So what to do?

We could either migrate again or try to maintain a custom fork for our own needs. For now, we decided to go with the latter option. And this is our story.

Upgrading Repman​

To make our Repman fork to support PHP 8.5 and Symfony 8.0, we used Rector to automatically refactor the code. We did the upgrade in smaller iterations:

• From Symfony 5.4 to 6.0
• From 6.0 to 6.4
• From 6.4 to 7.0
• From 7.0 to 7.4
• From 7.4 to 8.0 and 8.1

The process was relatively straightforward, but in-depth testing revealed issues that required a few manual fixes. After about 2 days, we had a usable application ready.

Challenges and Solutions​

Rector couldn't fix the unit tests, leaving us with a ton of failing tests. We tried using AI to fix them all at once, but it didn't work as expected.

We then decided to fix each test one by one, removing all failing tests and adding one test case class at a time. Doing this in a single session in the Coding agent proved to be beneficial since the agent could learn how previous errors have been fixed. This approach took more time but worked better and helped us learn more about the code base.

We also used the Coding Agent to fix all PHPStan issues, starting with the initial analysis level of 3 and moving to the max level one by one. This worked flawlessly and was quickly done.

Simplification​

Once we had all tests working and PHPStan issues fixed, we simplified the code by removing unused features, such as BitBucket integration, telemetry, the user registration flow, and more.

Also, we've introduced the Asset Mapper to manage assets such as CSS and JS files. This change allows us to control the loading of these assets, rather than relying on direct loading from a CDN.

Conclusion​

The combination of Rector and the AI Coding agent was a great learning experience for us and made the migration a lot simpler.

Would we recommend others doing the same? Probably not.

In our case, it makes sense since we self-host a lot of tools and managing the fork for us allows a deeper integration of Repman with some other tools we use on a daily basis. And thanks to Renovate Bot, we get automatic updates for the dependencies, making sure we don't fall behind anymore.

The latest Sylius UX release introduces the Calendar Link component, which allows users to add events to their calendar of choice with a single click.

While it may not sound like a revolutionary feature, it's incredibly useful when building a ticket booking site, such as the unKonf ticket shop, which we're currently upgrading to Sylius 2.

How does it work?​

To get started, install the new component using Composer:

composer require symfony/ux-calendar-link

Next, I decided to create a Twig Component to generate the CalendarEvent object required to render the links:

<?php

declare(strict_types=1);

namespace App\Twig\Components;

use DateTimeInterface;
use Sylius\TwigHooks\Twig\Component\HookableComponentTrait;
use Symfony\UX\CalendarLink\CalendarEvent;
use Symfony\UX\TwigComponent\Attribute\AsTwigComponent;
use Symfony\UX\TwigComponent\Attribute\ExposeInTemplate;

#[AsTwigComponent]
final class CalenderLink
{
    use HookableComponentTrait;

    #[ExposeInTemplate('event')]
    public function event(): CalendarEvent
    {
        $timezone = new \DateTimeZone('Europe/Berlin');
    
        return new CalendarEvent(
            title: 'unKonf 2026',
            start: new \DateTimeImmutable('2026-10-10 09:00', $timezone),
            end: new \DateTimeImmutable('2026-10-10 18:00', $timezone),
            description: 'unKonf 2026 - Your barcamp for web and software development!',
            location: 'bitExpert AG, Rudolf-Diesel Str. 40 - 46, 68169 Mannheim, Germany',
        );
    }
}

Then, in my Twig template, I use the following logic to render the links:

{% set providers = {
    google: {icon: 'logos:google-calendar', class: 'text-calendar-google border-calendar-google hover:bg-calendar-google hover:text-white'},
    outlook: {icon: 'file-icons:microsoft-outlook', class: 'text-calendar-outlook border-calendar-outlook hover:bg-calendar-outlook hover:text-white'},
    ics: {icon: 'lucide:calendar', class: 'text-calendar-ics border-calendar-ics hover:bg-calendar-ics hover:text-white'},
} %}

<div class="flex flex-wrap gap-2 justify-center sm:justify-start mt-2">
    {% for link in ux_calendar_links(event)|filter(link => providers[link.provider] is defined) %}
        {% set p = providers[link.provider] %}
        <a href="{{ link.url }}"
           target="_blank"
           rel="noopener"
           class="inline-flex items-center gap-2 px-2 py-1 me-3 rounded border text-sm no-underline transition-colors {{ p.class }}"
           title="Add to {{ link.label }} calendar"
        >
            <twig:ux:icon name="{{ p.icon }}" class="size-4"/>
            {{ link.label }}
        </a>
    {% endfor %}
</div>

With these simple steps, you can have the Calendar Link component up and running in little time.

Conclusion​

The Calendar Link component is a valuable addition to the Symfony UX ecosystem, providing an easy way to integrate calendar functionality into your applications.

We've invited our long-time friend Sebastian Feldmann to come over and talk about how to become a Domain Driven Design (DDD) essentialist.

Domain-Driven Design has been around for a long time. It covers a wide spectrum of useful architectural patterns such as Event Sourcing, CQRS, and Hexagonal Architecture. And because we're technical people, those patterns often become the focus.

But DDD is bigger than its patterns. In his talk, Sebastian revisits the fundamentals and make the case that they matter far more than any particular architecture. If we get those right, our code and applications improve regardless of whether we're using the latest DDD-inspired pattern or none of them at all.

Sounds interesting? Simply sign up on our meetup page to secure your spot!