Problem

When creating a controller with make:controller or a crud with make:crud or a registration form with make:registration-form or a password reset system with make:reset-password or a form login system with make:security:form-login, at the following question:

Do you want to generate PHPUnit tests? [Experimental] (yes/no) [no]:

If we don't have PHPUnit installed, we get the following error:

In KernelTestCase.php line 25:

  Attempted to load class "TestCase" from namespace "PHPUnit\Framework".  
  Did you forget a "use" statement for another namespace?

→ It throws an error and creates neither the controller nor the tests.

Steps to reproduce

1. Do not have PHPUnit installed

2. Create a controller with the maker bundle:

   php bin/console make:controller
   

3. Answer “yes” to the following question:

   Do you want to generate PHPUnit tests? [Experimental] (yes/no) [no]:
   > yes
   

4. Get the following error:

   In KernelTestCase.php line 25:
   
     Attempted to load class "TestCase" from namespace "PHPUnit\Framework".  
     Did you forget a "use" statement for another namespace?
   

Screenshots

Versions

Symfony 7.3.1 Symfony MakerBundle 1.64.0

composer.json:

{
    "type": "project",
    "license": "proprietary",
    "minimum-stability": "stable",
    "prefer-stable": true,
    "require": {
        "php": ">=8.2",
        "ext-ctype": "*",
        "ext-iconv": "*",
        "symfony/console": "7.3.*",
        "symfony/dotenv": "7.3.*",
        "symfony/flex": "^2",
        "symfony/framework-bundle": "7.3.*",
        "symfony/runtime": "7.3.*",
        "symfony/yaml": "7.3.*"
    },
    "require-dev": {
        "symfony/maker-bundle": "^1.64"
    },
    "config": {
        "allow-plugins": {
            "php-http/discovery": true,
            "symfony/flex": true,
            "symfony/runtime": true
        },
        "bump-after-update": true,
        "sort-packages": true
    },
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "App\\Tests\\": "tests/"
        }
    },
    "replace": {
        "symfony/polyfill-ctype": "*",
        "symfony/polyfill-iconv": "*",
        "symfony/polyfill-php72": "*",
        "symfony/polyfill-php73": "*",
        "symfony/polyfill-php74": "*",
        "symfony/polyfill-php80": "*",
        "symfony/polyfill-php81": "*",
        "symfony/polyfill-php82": "*"
    },
    "scripts": {
        "auto-scripts": {
            "cache:clear": "symfony-cmd",
            "assets:install %PUBLIC_DIR%": "symfony-cmd"
        },
        "post-install-cmd": [
            "@auto-scripts"
        ],
        "post-update-cmd": [
            "@auto-scripts"
        ]
    },
    "conflict": {
        "symfony/symfony": "*"
    },
    "extra": {
        "symfony": {
            "allow-contrib": false,
            "require": "7.3.*"
        }
    }
}

composer show symfony/maker-bundle:

name     : symfony/maker-bundle
descrip. : Symfony Maker helps you create empty commands, controllers, form classes, tests and more so you can forget about writing boilerplate code.
keywords : code generator, dev, generator, scaffold, scaffolding
versions : * v1.64.0
released : 2025-06-23, 2 weeks ago
type     : symfony-bundle
license  : MIT License (MIT) (OSI approved) https://spdx.org/licenses/MIT.html#licenseText
homepage : https://symfony.com/doc/current/bundles/SymfonyMakerBundle/index.html
source   : [git] https://github.com/symfony/maker-bundle.git c86da84640b0586e92aee2b276ee3638ef2f425a
dist     : [zip] https://api.github.com/repos/symfony/maker-bundle/zipball/c86da84640b0586e92aee2b276ee3638ef2f425a c86da84640b0586e92aee2b276ee3638ef2f425a
names    : symfony/maker-bundle

support
issues : https://github.com/symfony/maker-bundle/issues
source : https://github.com/symfony/maker-bundle/tree/v1.64.0

autoload
psr-4
Symfony\Bundle\MakerBundle\ => src/

requires
doctrine/inflector ^2.0
nikic/php-parser ^5.0
php >=8.1
symfony/config ^6.4|^7.0
symfony/console ^6.4|^7.0
symfony/dependency-injection ^6.4|^7.0
symfony/deprecation-contracts ^2.2|^3
symfony/filesystem ^6.4|^7.0
symfony/finder ^6.4|^7.0
symfony/framework-bundle ^6.4|^7.0
symfony/http-kernel ^6.4|^7.0
symfony/process ^6.4|^7.0

requires (dev)
composer/semver ^3.0
doctrine/doctrine-bundle ^2.5.0
doctrine/orm ^2.15|^3
symfony/http-client ^6.4|^7.0
symfony/phpunit-bridge ^6.4.1|^7.0
symfony/security-core ^6.4|^7.0
symfony/security-http ^6.4|^7.0
symfony/yaml ^6.4|^7.0
twig/twig ^3.0|^4.x-dev

conflicts
doctrine/doctrine-bundle <2.10
doctrine/orm <2.15

composer/lock:

{
      "name": "symfony/maker-bundle",
      "version": "v1.64.0",
}

Related versions / commits / PRs

Release v1.59.0 PR https://github.com/symfony/maker-bundle/pull/1497

This is just a nitpick, but has DX impact.

The recipe's mainfest.json can state the instruction to create the placeholder folders (similarly to dockerfile/docker-compose configurations).

Having empty committed .gitignore files or having to delete them each time the recipe is reinstalled is not the best DX.

Adds the standard responsive viewport meta tag to the base.html.twig provided by TwigBundle recipes across supported versions. This aligns the default scaffold with common HTML5 boilerplates and improves out-of-the-box rendering on mobile devices, without changing template structure or behavior otherwise.

This is a partial PR to gather feedbacks.

• Each Monolog handler has its own configuration and extension class
• Some handlers can share the same with different properties (name, handler class)
• They are all registered in the MonologExtension
• 3rd party bundles can add their own handler extension classes

Automated refresh of the bridge ModelCatalog static lists from upstream metadata (models.dev for per-provider bridges, the OpenRouter API for OpenRouter).

New models are appended; hand-curated entries are left untouched. Review the diff before merging, and adjust capabilities or model classes where the heuristics need a human.

This PR adds support for additional parameters to the native mailer, as describe in https://www.php.net/manual/en/function.mail.php

The additional_params parameter can be used to pass additional flags as command line options to the program configured to be used when sending mail, as defined by the sendmail_path configuration setting. For example, this can be used to set the envelope sender address when using sendmail with the -f sendmail option.

In a recent project we had the requirement to set the additional parameter [email protected] to be able to send emails through a relay server. Otherwise the mails were bounced.

The bundle currently allows to set these parameters only on existing logger instances. This PR allows to set them in the configuration file:

native_mailer:
    type: native_mailer
    from_email: '[email protected]'
    to_email: '[email protected]'
    subject: 'Example subject'
    parameters:
        - '[email protected]'

✏️ Describe the bug When a Data object contains a keyed collection (array<string, ChildData> / DataCollection) and the array keys themselves contain literal dots, validation via validateAndCreate() (or request/validate()) fails. The array key is treated as a nested path separator, so the validator looks for the value at the wrong location and reports the fields as missing.

Plain creation with from() is not affected. It looks like defining an empty rules() function also resolves the issue. Looks like #1043 introduced the regression.

↪️ To Reproduce

it('will validate a keyed collection whose keys contain dots', function () {
    $dataClass = new class () extends Data {
        /** @var array<string, SimpleData> */
        #[DataCollectionOf(SimpleData::class)]
        public array $items;
    };

    DataValidationAsserter::for($dataClass)
        ->assertOk([
            'items' => [
                'key.with.dots' => ['string' => 'first'],
                'another.key' => ['string' => 'second'],
            ],
        ])
        ->assertErrors([
            'items' => [
                'key.with.dots' => ['other_string' => 'wrong key'],
            ],
        ])
        ->assertRules([
            'items' => ['present', 'array'],
            'items.key\.with\.dots.string' => ['required', 'string'],
        ], payload: [
            'items' => [
                'key.with.dots' => [],
            ],
        ]);
});

✅ Expected behavior Validating keys containing dots should be resolved correctly 🖥️ Versions

Laravel: 12 Laravel Data: 4.18.0+ PHP: 8.4

The current implementation of RSS is very barebones (still happy that it exists!).

Problem

Right now if there is an update added to an incident the RSS feed will not be notified to reflect that.

Solution

As per the RSS 2.0 spec, you can create an "updated" RSS functionality by changing the guid (as per the spec here).

Contributing

I am willing to make a pull request with the desired functionality.

I am still between the solution of creating "perminant" items or "impermanent"; meaning if the rss file contains all the items (for all the incidents and its updates one seperate item) or just the incident, and when an update is created we just update the item with a new guid. (the rss file returned only contains the incident with the information in the details)

I have created a fork with the second option implemented in a separate branch

Blocking?

I might want to wait on #256 so the notifications are not wrong (incident on new status while update on old status)

Fixes #1019.

This prevents mapped input properties from falling back to the original PHP property name when validated creation is being used. Without this, an input like ['size' => 300] can bypass validation rules defined for the mapped input name page.size and still hydrate the property.

The change only removes the unmapped original property during validation-backed creation, so existing unvalidated from() behavior continues to accept the original property name.

Tests run:

• php vendor/bin/php-cs-fixer fix --dry-run --diff --allow-risky=yes --config=.php-cs-fixer.dist.php src/DataPipes/MapPropertiesDataPipe.php tests/ValidationTest.php
• php vendor/bin/phpstan analyse src/DataPipes/MapPropertiesDataPipe.php --memory-limit=1G
• php vendor/bin/pest tests/ValidationTest.php --filter "original property names" --no-coverage
• php vendor/bin/pest tests/MappingTest.php --no-coverage

Not run: full tests/ValidationTest.php on my Windows/PHP 8.3 setup, because it hits an unrelated phpDocumentor FQSEN parsing issue in it can overwrite collection item rules with wildcard rules.

Companion PR to symfony/ux#3468. Adds the Toolkit/Shadcn docs page for the popover recipe.

Kept as draft until symfony/ux#3468 (which introduces the upstream recipe) is merged.

Split out from the original #54 so each component can be reviewed/merged independently alongside its upstream recipe.

This PR documents the new route-specific CORS support so developers can configure cross-origin policies where routes are defined instead of relying only on global configuration.

Framework PR: https://github.com/laravel/framework/pull/59305

Usage

The docs now cover route-level ->cors([...]) usage, route group inheritance, and the #[Cors] attribute on controller classes and methods.

Approach

• Extend the routing documentation's CORS section with the new per-route configuration workflow.
• Show the supported options and explain precedence between route, group, class, and method definitions.
• Note that route-specific CORS metadata continues to work with route caching.

Summary

Adds an emptyState() method to Stat, letting you define a fallback value/content to render when a stat's value resolves to null.

Stat::make('Unique views', $uniqueViews)
    ->emptyState('-')

The blade view now does:

{{ $getValue() ?? $getEmptyState() }}

Why not just handle this with value()?

You can already get the same visual result today without this PR, just by doing the null-coalescing yourself:

Stat::make('Unique views', null)
    ->value($uniqueViews ?? '-')

That works, but it means every stat needs this handled ad-hoc at the call site. Adding a dedicated emptyState() method:

• separates "what the value is" from "what to show when there's no value," which reads more clearly
• can be configured globally via Stat::configureUsing(), so an app can set one default empty-state placeholder (e.g. '-' or 'N/A') for every stat without repeating ?? '-' everywhere

use Filament\Widgets\StatsOverviewWidget\Stat;

Stat::configureUsing(function (Stat $stat): void {
    $stat->emptyState('-');
});

That global-default use case isn't really reachable with the manual value($x ?? '-') approach, since it has to be repeated per-stat rather than configured once.

Adding cachet to a container registry like ghcr.io would massively simplify deployment on various platforms. If updates to the container registry image were uploaded mutually with new releases, it would further improve the deployment process.

I can see on dockerhub the last image was uploaded 3 years ago

Problem

MakeQueueTenantAwareAction::isTenantAware() reads $payload['data']['command'] unconditionally. Modern Laravel payloads always carry the serialized job there, but legacy string-job payloads have no data.command:

{ "job": "App\\Jobs\\SyncInventory@handle", "data": { "sku": "ABC-123" } }

This shape is produced whenever messages reach the queue from something other than Laravel's dispatcher — e.g. AWS EventBridge input transformers pushing to SQS, or any raw Queue::pushRaw-style producer. Laravel's worker still runs them via $instance->handle($job, $data), and fires JobProcessing as usual.

Because data.command is absent, the action throws Undefined array key "command" before it ever reaches the interface checks. So a legacy-format job that implements NotTenantAware (or TenantAware) has its declaration silently ignored, and the worker errors instead of processing the job.

Fix

When data.command is absent, resolve the job class straight from payload['job'] (stripping the @method suffix) and run the existing interface / config-list / default checks against that class name (ReflectionClass accepts a class-string). The decision logic is extracted into a shared helper so both paths behave identically.

• Honors all the same config knobs: tenant_aware_interface, not_tenant_aware_interface, tenant_aware_jobs, not_tenant_aware_jobs, queues_are_tenant_aware_by_default.
• If the class can't be resolved (missing job key, or class doesn't exist) it falls back to queues_are_tenant_aware_by_default — it never throws.
• The legacy path has nothing to unserialize and no encrypted command, so no decryption/unserialization is attempted there.

Zero impact on modern payloads

Modern Queueable jobs always carry data.command (the real job is serialized inside it; the top-level job is Illuminate\Queue\CallQueuedHandler@call, not the job class). The new branch triggers only when data.command is genuinely absent, so the modern path is unchanged — the added risk surface is limited to payloads that currently crash. A regression test asserts this and fails if the legacy branch is ever allowed to touch a modern payload.

Tests

New LegacyQueuePayloadTest covering: legacy NotTenantAware → false; legacy TenantAware → true; legacy class in tenant_aware_jobs / not_tenant_aware_jobs → respective result; unresolvable/missing class → falls back to the default (both true and false); missing job key → default; a modern data.command payload behaves exactly as before; and an end-to-end regression firing JobProcessing for a legacy payload no longer throws.

when adding symfony/joli-notif-notifier to a project, the env var is commented out.

 composer req symfony/joli-notif-notifier

cat .env

###> symfony/joli-notif-notifier ###
# JOLINOTIF_DSN=jolinotif://default
###< symfony/joli-notif-notifier ###

I can't find anything in the recipe that does this, and I don't understand why anyone would want to, since it's an extra step the first time you try to use it.

If the Mercure hub is located on a completely different domain from the one where the front-end is hosted, then authorizing with the hub using cookies doesn't work (AFAIK). Using Authorization header doesn't work with the browser's native EventSource. This leaves adding an authorization parameter to the hub query.

I propose adding a Twig extension to generate a hub URL, similar to the existing mercure() function, but adding an authorization param to the query.

I have a Dockerfile like the following in order to re-build the application in 2.4 and apply some CSS changes

>cat Dockerfile 
# build stage
FROM cachethq/docker:latest
COPY public/img/login-logo.png /var/www/html/public/img/login-logo.png
COPY resources /var/www/html/resources
USER root
RUN apk add --no-cache npm
USER 1001
RUN mkdir -p /home/www-data/.npm/ && cd /var/www/html && npm install && npm run production

# docker stage
FROM cachethq/docker:latest
RUN rm -fr /var/www/html
COPY --from=0 --chown=1001 /var/www/html /var/www/html
COPY entrypoint.sh /sbin/entrypoint.sh
USER root
RUN apk add --no-cache vim
USER 1001

Lately I have noticed that uglify-js is giving this error.

 DONE  Compiled successfully in 30631ms                                                                                        11:59:51 AM

Whoops! We had trouble minifying "public/dist/js/all.js". Perhaps you need to use mix.babel() instead?

/var/www/html/node_modules/laravel-mix/src/webpackPlugins/CustomTasksPlugin.js:64
                    throw e;
                    ^
SyntaxError: Name expected
    at JS_Parse_Error.get (eval at <anonymous> (/var/www/html/node_modules/uglify-js/tools/node.js:27:1), <anonymous>:86:23)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! cachet@ production: `cross-env NODE_ENV=production node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the cachet@ production script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/www-data/.npm/_logs/2020-12-22T11_59_51_992Z-debug.log

When I build the image using an older docker image from a previous build from my docker registry, that has node_modules already installed, then the build succeeds. I have verified that the uglify-js is in the same version in both images.

bash-5.0$ npm list uglify-js
cachet@ /var/www/html
`-- [email protected]
  +-- [email protected]
  | `-- [email protected]
  |   `-- [email protected] 
  +-- [email protected] 
  `-- [email protected]
    `-- [email protected]
      `-- [email protected]  deduped

However, if I diff the two folders (the one created in a new npm install, and the one that was installed in an older image) the actual files differ. So, as a workaround, after npm install I am replacing the node_modules/uglify-js from an older image to the node_modules and the npm run production works without any issues and this was my workaround to the problem.

✏️ Describe the bug After upgrading the package to the latest version I started getting validation errors I feel are unexpected. I tried numerous versions of laravel-data and have isolated this to changes introduced in 4.22.0.

For example, take this class definition:

abstract class BaseExampleData extends Data implements PropertyMorphableData
{
    public function __construct(
        #[PropertyForMorph]
        public string $type,
        public bool $example_bool = true,
    ) {}

    public static function morph(array $properties): ?string
    {
        return match ($properties['type']) {
            'failing' => FailingExampleData::class,
            'working' => WorkingFailingExampleData::class,
            default => null,
        };
    }
}

class FailingExampleData extends BaseExampleData
{
    public function __construct(
        bool $example_bool = true,
    ) {
        parent::__construct(
            type: 'failing',
            example_bool: $example_bool,
        );
    }
}

In versions of laravel-data < 4.22.0 you could run this code without any validation error:

FailingExampleData::validate(['type' => 'failing']);

This feels like expected behaviour because the parent class defines a default for the example_bool property.

From laravel-data version 4.22.0 and onwards this will start throwing a validation exception saying that example_bool is required.

Interestingly, this alternative definition of the child class (with public in constructor - again even though it's defined on the parent) does work:

class WorkingFailingExampleData extends BaseExampleData
{
    public function __construct(
        public bool $example_bool = true,
    ) {
        parent::__construct(
            type: 'working',
            example_bool: $example_bool,
        );
    }
}

I checked to see if laravel-data recognises the default values:

$failingDataClass = app(DataConfig::class)->getDataClass(FailingExampleData::class);
dump($failingDataClass->properties['example_bool']->hasDefaultValue);

$workingDataClass = app(DataConfig::class)->getDataClass(WorkingFailingExampleData::class);
dump($workingDataClass->properties['example_bool']->hasDefaultValue);

This is actually the same result false then true, for laravel-data versions both before and after that version.

I had a quick look and it seems like when \Spatie\LaravelData\Support\DataClass is built it only checks the classes constructor. I'm not sure if it makes sense to see to check the parent class as well, but this could get complex quickly. E.g. How many parents do you check? Do you need to consider the default value changing from subsequent parent::__construct calls?

So I'm not really sure what to do here. I can change my data class definitions, but it feels like something that should work and will be very easy to miss/forget in the future when creating more data classes.

✅ Expected behavior I should be able to define a public property with a default value in the constructor of an abstract class. Any classes that extend it should know there's a default value and avoid triggering required validation errors for it.

🖥️ Versions

Laravel: 12.48.1 Laravel Data: Tested with versions from 4.19.0 onward PHP: 8.5.2

We want to use the TagProcessor from Monolog. How can we configure the Tags in the yaml config file?

Hi,

The following configuration can't be used in a Docker context. I need to specify 0.0.0.0 as the host for the built-in PHP server, and use the PHP container name as the $baseUri.".

$client = Client::createPantherClient(
    options: [
        'hostname': '0.0.0.0' 
        'browser' => PantherTestCase::SELENIUM,
    ],
    managerOptions: [
        'host' => 'http://selenium-hub:4444', // the host of the Selenium Server (Grid)
        'capabilities' => DesiredCapabilities::firefox(), // the capabilities of the browser
    ],
);

Would it be possible to add a new base_uri option to separate the server binding and the base URI configuration?

Currently, I need to do something like this :

static::startWebServer(['hostname' => '0.0.0.0', 'port' => 9080]);
self::$baseUri = 'http://my_container_php:9080';
$client = static::createPantherClient(
    options: [
        'browser' => PantherTestCase::SELENIUM,
    ],
    managerOptions: [
        'host' => 'http://selenium:4444/wd/hub', // the host of the Selenium Server (Grid)
        'capabilities' => DesiredCapabilities::chrome(), // the capabilities of the browser
    ],
);

What about allowing displaying post-install messages again, eg when running this?

composer recipes the/package

Bumps actions/checkout from 6 to 7.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Preview

Description:

Currently, LiveComponent actions triggered via data-action="live#action" execute synchronously and bypass standard confirmation dialogs. If developers configure a global async dialog (like SweetAlert2) via Turbo.config.forms.confirm (or Turbo.setConfirmMethod), it is completely ignored on LiveComponent actions. Additionally, native onclick="return confirm('...')" correctly prevents the event's default behavior, but the live#action was still being fired because event.defaultPrevented wasn't being checked before execution.

This PR introduces robust, framework-agnostic support for action confirmations, bridging the gap between LiveComponent, Hotwired Turbo, and custom async modal libraries.

What changed?

1. Respect event.defaultPrevented: Added an early return in action() if the event was already canceled (e.g., via a native onclick="return confirm('...')").
2. Asynchronous actions: Refactored the action(event) method to async and cached event.currentTarget to ensure scope and element references remain intact across the asynchronous boundary (await).
3. Turbo native integration (data-turbo-confirm): Seamlessly integrates with Turbo 7 and Turbo 8 globally configured confirm methods. We strictly type-cast the integration locally inside the method to avoid polluting the global Window object and prevent type collisions for developers using their own @hotwired/turbo types.
4. Framework-agnostic data-live-confirm: Introduced a new data-live-confirm attribute for developers who do not use Turbo. It dispatches a cancelable live:confirm custom event, allowing easy interception to hook up custom UI modals like SweetAlert2.
5. Documentation: Added clear examples in doc/index.rst on how to use Native Confirm, Turbo Confirm, and Custom LiveConfirm (including a JS snippet showing SweetAlert2 integration and explicitly mentioning that any library or custom UI can be used).
6. Demo Component: Added an interactive example (test.php & test.html.twig inside the confirm/ folder) to easily demonstrate and test all three confirmation strategies side-by-side using Bootstrap UI.

Backward Compatibility

This implementation is 100% backward-compatible. If no confirm attributes are present, the action executes synchronously just like before.

How to Test / Demo

You can check out the provided Demo component in the confirm/ directory. Simply render {{ component('test') }} in any application.

• Native: Prompts standard browser dialog.
• Turbo: Awaits the globally defined Turbo confirm promise.
• Live: Dispatches a DOM event that you can intercept to open any async modal.

test.php

<?php

namespace App\Twig\Components;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\UX\LiveComponent\Attribute\AsLiveComponent;
use Symfony\UX\LiveComponent\Attribute\LiveAction;
use Symfony\UX\LiveComponent\Attribute\LiveProp;
use Symfony\UX\LiveComponent\DefaultActionTrait;

#[AsLiveComponent]
class test extends AbstractController
{
    use DefaultActionTrait;

    #[LiveProp(writable: true)]
    public string $nativeStatus = 'Waiting';

    #[LiveProp(writable: true)]
    public string $swalStatus = 'Waiting';

    #[LiveProp(writable: true)]
    public string $liveStatus = 'Waiting';

    #[LiveAction]
    public function deleteNative(): void
    {
        $this->nativeStatus = 'Confirmed';
    }

    #[LiveAction]
    public function deleteSweetAlert(): void
    {
        $this->swalStatus = 'Confirmed';
    }

    #[LiveAction]
    public function deleteLiveConfirm(): void
    {
        $this->liveStatus = 'Confirmed';
    }
}

test.html.twig

<div {{ attributes }}>
    <div class="container mt-5">
        <h2 class="mb-4 text-center">Interactive Confirm Examples</h2>
        <div class="row justify-content-center">
            {# Native Confirm #}
            <div class="col-md-4">
                <div class="card shadow-sm h-100">
                    <div class="card-body d-flex flex-column">
                        <h5 class="card-title text-primary">Native Confirm</h5>
                        <p class="card-text">Uses the browser's default confirm dialog via `onclick`.</p>
                        <hr>
                        <p><strong>Status:</strong>
                            <span class="badge {% if nativeStatus == 'Confirmed' %}bg-success{% else %}bg-secondary{% endif %}">
                                {{ nativeStatus }}
                            </span>
                        </p>
                        <button
                                data-action="live#action"
                                data-live-action-param="deleteNative"
                                onclick="return confirm('Are you sure you want to delete this item? (Native Confirm)')"
                                class="btn btn-danger w-100 mt-auto"
                        >
                            <i class="bi bi-trash"></i> Delete (Native)
                        </button>
                    </div>
                </div>
            </div>

            {# Turbo Confirm with SweetAlert2 #}
            <div class="col-md-4">
                <div class="card shadow-sm h-100">
                    <div class="card-body d-flex flex-column">
                        <h5 class="card-title text-success">Turbo setConfirmMethod</h5>
                        <p class="card-text">Uses `data-turbo-confirm` which is handled by `turbo:confirm-start` event.</p>
                        <hr>
                        <p><strong>Status:</strong>
                            <span class="badge {% if swalStatus == 'Confirmed' %}bg-success{% else %}bg-secondary{% endif %}">
                                {{ swalStatus }}
                            </span>
                        </p>
                        <button
                                data-action="live#action"
                                data-live-action-param="deleteSweetAlert"
                                data-turbo-confirm="Are you sure you want to delete this item? (setConfirmMethod)"
                                class="btn btn-success w-100 mt-auto"
                        >
                            <i class="bi bi-check-circle"></i> Delete (Turbo)
                        </button>
                    </div>
                </div>
            </div>

            {# Live Confirm with SweetAlert2 #}
            <div class="col-md-4">
                <div class="card shadow-sm h-100">
                    <div class="card-body d-flex flex-column">
                        <h5 class="card-title text-info">Live Confirm</h5>
                        <p class="card-text">Uses `data-live-confirm` which is handled by the Live Component system.</p>
                        <hr>
                        <p><strong>Status:</strong>
                            <span class="badge {% if liveStatus == 'Confirmed' %}bg-success{% else %}bg-secondary{% endif %}">
                                {{ liveStatus }}
                            </span>
                        </p>
                        <button
                                data-action="live#action"
                                data-live-action-param="deleteLiveConfirm"
                                data-live-confirm="Are you sure you want to delete this item? (Live Confirm)"
                                class="btn btn-info w-100 text-white mt-auto"
                        >
                            <i class="bi bi-bootstrap"></i> Delete (Live)
                        </button>
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>

Bumps axios from 0.30.2 to 0.32.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the Security Alerts page.

I have checked here and the latest version as of now is 2.3.18. Is there a problem with releasing pre-built docker images?

docker compose build fails with

failed to solve: process "/bin/sh -c wget ${archive_url} && tar xzf ${cachet_ver}.tar.gz --strip-components=1 && chown -R www-data:root /var/www/html && rm -r ${cachet_ver}.tar.gz && php /bin/composer.phar global require \"hirak/prestissimo:^0.3\" && php /bin/composer.phar install -o && rm -rf bootstrap/cache/*" did not complete successfully: exit code: 1

On a Symfony 7.3 project, I'm upgrading to 7.4RC3 via:

composer config minimum-stability rc
composer config extra.symfony.require "7.4.*"
composer update

I updated some Flex recipes and it all went good.

Then I run:

composer symfony:recipes:update symfony/phpunit-bridge

And my diff is:

On branch upgradeSymfony8
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	deleted:    .env.test
	deleted:    .gitignore
	deleted:    bin/phpunit
	modified:   phpunit.xml.dist
	modified:   symfony.lock
	deleted:    tests/bootstrap.php

Most of those files should not have disappeared, for example : .gitignore should not be removed.

How to reproduce

This was done on a open source project:

• branch: https://github.com/jolicode/secret-santa/tree/upgradeSymfony8
• PR: https://github.com/jolicode/secret-santa/pull/323

Checkout the branch, and run:

composer symfony:recipes:update symfony/phpunit-bridge

(you can use castor start && castor builder to have the project running via Docker and a shell to run the command).

Maybe related to https://github.com/symfony/recipes/pull/1401

Updates the requirements on symfony/var-dumper to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Description

The ElevenLabs speech-to-text API supports exporting transcripts in additional formats, including SRT subtitles, through the additional_formats multipart field.

Currently, the Symfony AI ElevenLabs bridge supports Capability::SPEECH_TO_TEXT, but it is not possible to request SRT output cleanly through PlatformInterface::invoke(). The standard asText() result only exposes the plain transcript text, while the SRT content returned by ElevenLabs under additional_formats[0].content is not available through a first-class API.

This makes subtitle generation difficult when using Symfony AI with ElevenLabs Scribe.

Use case

I want to generate SubRip subtitles from an audio file using ElevenLabs Scribe v2 through Symfony AI:

$result = $platform->invoke(
    model: new ElevenLabs(
        name: 'scribe_v2',
        capabilities: [
            Capability::SPEECH_TO_TEXT,
            Capability::INPUT_AUDIO,
            Capability::OUTPUT_TEXT,
        ],
    ),
    input: Audio::fromFile(__DIR__ . '/audio.mp3'),
    options: [
        'language_code' => 'pl',
        'tag_audio_events' => false,
        'num_speakers' => 1,
        'diarize' => true,
        'timestamps_granularity' => 'word',
        'additional_formats' => [
            [
                'format' => 'srt',
                'include_timestamps' => true,
            ],
        ],
    ],
);

Expected result: Symfony AI should send these speech-to-text options to ElevenLabs and make the returned SRT content accessible.

Current workaround

The only reliable workaround is to bypass Symfony AI and call ElevenLabs directly with Symfony HttpClient:

public function createSubRipText(string $language, string $audio): string
{
    $formData = new FormDataPart(fields: [
        'model_id' => 'scribe_v2',
        'language_code' => $language,
        'tag_audio_events' => 'false',
        'num_speakers' => '1',
        'diarize' => 'true',
        'timestamps_granularity' => 'word',
        'additional_formats' => json_encode(value: [
            [
                'format' => 'srt',
                'include_timestamps' => true,
            ],
        ], flags: JSON_THROW_ON_ERROR),
        'file' => new DataPart(body: $audio, filename: 'audio.mp3', contentType: self::AUDIO_MIME_TYPE),
    ]);

    $url = sprintf('%s/v1/speech-to-text', self::API_URL);

    $response = $this->httpClient->request(method: 'POST', url: $url, options: [
        'headers' => [
            'xi-api-key' => $this->apiKey,
            ...$formData->getPreparedHeaders()->toArray(),
        ],
        'body' => $formData->bodyToIterable(),
    ])->toArray();

    $result = $response['additional_formats'][0]['content'] ?? null;

    if (empty($result)) {
        throw new \RuntimeException(message: 'Failed to create audio SRT subtitles');
    }

    return $result;
}

This works, but it duplicates functionality that should ideally be available through the ElevenLabs bridge.

Proposed solution

There are two related improvements that would solve this:

1. Forward speech-to-text $options to the ElevenLabs /v1/speech-to-text request body.

   For example, options such as these should be supported:

   [
       'language_code' => 'pl',
       'tag_audio_events' => false,
       'num_speakers' => 1,
       'diarize' => true,
       'timestamps_granularity' => 'word',
       'additional_formats' => [
           [
               'format' => 'srt',
               'include_timestamps' => true,
           ],
       ],
   ]
   

2. Expose additional transcript formats in the result.

   Possible API options:

   $result->asText(); // existing transcript text
   $result->getRawResult()->getData()['additional_formats'][0]['content']; // already possible if raw data is preserved
   

   Or, preferably, a first-class result API such as:

   $result->asSubRipText();
   

   or:

   $result->getAdditionalFormat('srt');
   

Why this is useful

SRT generation is a common speech-to-text use case for video subtitles, social media videos, accessibility captions, and content workflows. ElevenLabs already supports this natively through additional_formats, so Symfony AI only needs to expose this functionality through the bridge.

Related API behavior

ElevenLabs /v1/speech-to-text accepts multipart fields such as:

model_id
file
language_code
tag_audio_events
num_speakers
timestamps_granularity
diarize
additional_formats

The SRT content is returned in the response under:

$response['additional_formats'][0]['content']

Environment

Symfony AI ElevenLabs bridge: current main / latest release ElevenLabs model: scribe_v2 Use case: speech-to-text with SRT subtitle output

initial issue https://github.com/symfony/symfony/issues/62766

I have a non-nullable title field on Book entity, on an edit form. i tried to clear the title field value and submit the form. it raised an error (http code 500). the expected output is validator error message should be appear (http code 422)

all form, entity, and controller in the reproducer repository were created using maker-bundle

How to reproduce

https://github.com/IndraGunawan/symfony-validator-reproducer

git clone [email protected]:IndraGunawan/symfony-validator-reproducer.git
cd symfony-validator-reproducer
symfony serve

head over to http://127.0.0.1:8000/new and directly click the submit button. This value should not be blank. error will be shown

head over to http://127.0.0.1:8000/edit and clear title field and click the submit button. InvalidTypeException will be raised, Expected argument of type "string", "null" given at property path "title".

TypeError
App\Entity\Book::setTitle(): Argument #1 ($title) must be of type string, null given, called in .../validator-issue-reproducer/vendor/symfony/property-access/PropertyAccessor.php on line 532

MakerBundle generates the setter for non-nullable field, does not allow null on the argument, do we need to update the generator to allow null even for non-nullable field?

Hi,

I use a service definition config like this one:

return static function (ContainerConfigurator $container) {
    $services = $container->services();
    $services
        ->defaults()
            ->autowire()
            ->autoconfigure()
            ->tag('monolog.logger', ['channel' => 'defaultchannel'])
   ;

   $services
       ->set(\MyService::class)
            ->tag('monolog.logger', ['channel' => 'specificchannel'])
   ;
}

So I'd like to define a default channel in the service defaults, but override this default for some services. But in reality MyService will always use the defaultchannel and never the specificchannel. This is because

• Symfony adds both tags to MyService, but the one from defaults last deliberately (in AbstractServiceConfigurator)
• MonologBundle iterates over all tags in order, and modifies services for each iteration, which means that the last tag will win (in LoggerChannelPass)

Now I'm unsure where the problem is located. Is my reasoning about defaults and specific overrides correct? Is this in theory the right way to do (if not, what is a better/working/official solution?)? Or is this a possible improvement for the bundle?

Thank you in advance for insights 🙂

Octane Version

1.0.3

Laravel Version

11.8.0

PHP Version

8.3

What server type are you using?

FrankenPHP

Server Version

1.0.3

Database Driver & Version

No response

Description

Using the latest laravel version as of today.

WARN Your FrankenPHP binary version (1.0.3) may be incompatible with Octane.

Using FROM dunglas/frankenphp:1.0-php8.3

FROM dunglas/frankenphp:1.0-php8.3

ARG DOCKER_WWWGROUP
ARG DOCKER_WWWUSER
ARG NODE_VERSION=20
ARG APP_ENV

WORKDIR /var/www/html

ENV DEBIAN_FRONTEND=noninteractive
ENV TZ=UTC

# Set timezone
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

# Update and install essential packages
RUN apt-get -y update --fix-missing && \
    apt-get upgrade -y && \
    apt-get install -y --no-install-recommends \
        apt-utils \
        apt-transport-https \
        curl \
        wget \
        nano \
        dialog \
        build-essential \
        git \
        gnupg2 \
        iputils-ping \
        libonig-dev \
        libsqlite3-dev \
        libsqlite3-0 \
        libzip-dev \
        libicu-dev \
        libxml2-dev \
        libxslt-dev \
        libssh2-1-dev \
        libssh2-1 \
        libcurl4-openssl-dev \
        pkg-config \
        openssl \
        zip \
        unzip \
        supervisor && \
    rm -rf /var/lib/apt/lists/*

# Install Node.js and Yarn
RUN curl -sL https://deb.nodesource.com/setup_$NODE_VERSION.x | bash - && \
    apt-get install -y --no-install-recommends nodejs && \
    npm install --global yarn && \
    rm -rf /var/lib/apt/lists/*

RUN pecl install xdebug

# Install PHP extensions
RUN install-php-extensions \
    pdo_sqlite \
    curl \
    zip \
    intl \
    mbstring \
    gettext \
    calendar \
    exif \
    pcntl \
    dom \
    xsl \
    simplexml \
    bcmath \
    sockets

# Clean up the image
RUN apt-get clean && apt-get autoremove -y

# Get latest Composer
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

# Create user and group
RUN groupadd --gid 1000 $DOCKER_WWWGROUP && \
    useradd --uid 1000 --gid 1000 -m $DOCKER_WWWUSER && \
    chown 1000:1000 /var/log -R && chown 1000:1000 /var/run/ -R

# Switch to the new user
USER $DOCKER_WWWUSER

# Set the command to run frankenphp
ENTRYPOINT ["php", "artisan", "octane:frankenphp"]

Steps To Reproduce

see above

Hi, Symfony has a large community of Iranian developers and I suggest adding translation for the Persian language.

Hello, When using php-flasher-toastr with Laravel 11, I encounter a TypeError: array_replace_recursive(): Argument #2 must be of type array, int given error in Illuminate\Translation\FileLoader at line 130. My environment:

• PHP: 8.3.7
• Laravel: 11.4.2
• php-flasher/flasher-toastr-laravel: 2.1
• php-flasher/flasher-laravel: 2.1 The error disappears when I uninstall php-flasher/flasher-toastr-laravel and php-flasher/flasher-laravel. Alternatively, ensuring that the value passed to with() is always a string (e.g., with('success', 'Message')) prevents the error.

https://github.com/cakephp/phinx

I can't solve the problem for two days. I run it on a local computer and everything works fine. I transferred the project to Ubuntu 22.04 and it gives me this error. Laravel + Symphony panther bundle

Symfony\Component\Panther\Exception\RuntimeException Could not start chrome. Exit code: 1 (General error). Error output: cannot join mount namespace of pid 1: Operation not permitted

The following errors are happening in a production & staging environment when we attempt to screenshot with panther, set size for the window, or do anything that utilizes panther for web scraping. It seems like the connection drops or is lost between panther and php-webdriver.

Errors:

Facebook\WebDriver\Exception\Internal\WebDriverCurlException: Curl error thrown for http POST to /session with params: 
{
    "capabilities": {
        "firstMatch": [
            {
                "browserName": "chrome",
                "goog:chromeOptions": {
                    "args": [
                        "--no-sandbox",
                        "--headless",
                        "--disable-dev-shm-usage",
                        "--hide-scrollbars"
                    ]
                }
            }
        ]
    },
    "desiredCapabilities": {
        "browserName": "chrome",
        "platform": "ANY",
        "goog:chromeOptions": {
            "args": [
                "--no-sandbox",
                "--headless",
                "--disable-dev-shm-usage",
                "--hide-scrollbars"
            ]
        }
    }
}
...
Operation timed out after 180000 milliseconds with 0 bytes received in /app/vendor/php-webdriver/webdriver/lib/Exception/Internal/WebDriverCurlException.php:20

Current Workarounds:

• implemented exponential backoff when the WebDriverCurlException is thrown
• implementing longer timeouts for connection, request, & read.

Versions::

• php: 8.3
• symfony: 6.4
• symfony/panther: 2.1.1
• php-webdriver/webdriver: 1.15.1
• chrome: latest
• chromedriver: latest, stable for chrome

If I call another console command in a running console command, the output is closed after the inner command returns.

E.g. Run Messenge consumer which starts a console command. After starting the console command, the output is overwritten by the new output, provided to Application.php by running the inner command. When the inner command ends, the Application.php fires a terminate event, which causes the ConsoleHandler to close the output. After that there is no more output on console available.

Solution: Maybe the Handlers should stack there outputs and get the last out of the stack when the terminate event is fired until there is no output left and then close the handler.

In the first parameter, a presenter string is required either "html" or "json".

Since #60645, SqsQueue::bulk() dispatches jobs via the SendMessageBatch API, splitting them into chunks of 10 messages / 1 MB and sending the chunks one at a time. Sequential dispatch is required for FIFO queues — a later chunk must not arrive ahead of an unsent one — but standard queues make no ordering guarantees, so a large bulk dispatch currently pays for hundreds of serial HTTP round-trips it doesn't need (a 10,000 job bulk is 1,000 sequential requests).

This PR dispatches the batch requests concurrently when the queue is a standard queue, while keeping FIFO dispatch strictly ordered.

How it works

The chunk requests are yielded lazily from a generator and driven by GuzzleHttp\Promise\Each::ofLimitAll(), so "sequential vs. concurrent" is simply the concurrency argument:

• FIFO queues run at a concurrency of 1: the next request is not created until the previous one has settled, preserving today's ordering and stop-at-first-failure behavior exactly.
• Standard queues run at SqsQueue::MAX_CONCURRENT_BATCH_REQUESTS (50), which subclasses may override.

Laziness matters here: a promise created by sendMessageBatchAsync() is already registered on the shared curl multi handle, and the first wait() transmits every registered transfer at once. Because requests only come into existence when the pool pulls them from the generator, un-launched chunks remain genuinely un-launched.

Failure semantics

The same contract as every other driver's bulk(), where a failed push() simply throws: the first failed chunk rejects the aggregate promise, its exception is rethrown untouched, and chunks that were not yet dispatched are never sent. Entry-level failures inside an HTTP 200 response are surfaced as the same synthesized SqsException as before, with an unchanged message format.

As with the sequential implementation — or any driver failing mid-bulk() — a thrown exception means the dispatch may have partially completed: chunks accepted before the failure are on the queue and have raised their JobQueued events, and with concurrent dispatch up to forty-nine in-flight chunks may additionally land after the failure. SQS standard queues are at-least-once delivery, so consumers of bulk dispatch at this scale should already be idempotent.

The AWS SDK for PHP has no native handling for any of this — sendMessageBatch rejects more than 10 entries outright, and unlike the Java SDK's buffered SQS client (or the PHP SDK's own DynamoDB WriteRequestBatch), it offers no chunking or parallel dispatch for SQS.

On Guzzle handlers without curl_multi support (e.g. the stream handler), the standard-queue path gracefully degrades to sequential execution with identical results.

🤖 Generated with Claude Code

Priority: P2 (High - Fix Soon)

Problem

Both CreateScheduleRequestData (src/Data/Requests/Schedule/CreateScheduleRequestData.php:24) and UpdateScheduleRequestData (:17) accept a ScheduleStatusEnum $status property.

However, the status column was dropped from the schedules table in migration 2024_10_13_214300. The Schedule model computes status from scheduled_at/completed_at via an Attribute accessor. Any status value sent via the API is silently ignored.

Suggested Fix

Remove the $status property from both request data classes, or validate and map it to completed_at if the intent is to let API consumers set a schedule to "complete".

This pull request updates the Docker setup for Cachet with the following improvements:

• Refactored architecture to separate the application, scheduler, and worker into individual containers for better isolation, scalability, and maintainability.
• Enhanced documentation in README.md with architecture rationale, production best practices, and maintenance instructions.
• Updated GitHub Actions workflow (.github/workflows/docker-publish.yml) for multi-platform image builds, improved version handling, and secure registry logins.
• Added security recommendations and reverse proxy setup examples.
• Improved backup, restore, and troubleshooting sections.

These changes make the deployment more robust, secure, and easier to manage in production environments. Please review and merge into the main project.

I am using panther with chromedriver. I use it in a Symfony command to scrape a webpage.

$default_arguments = [
    "--headless",
    "--window-size=1280,1024",
    "--disable-gpu",
    "--no-sandbox",
    "--disable-dev-shm-usage",
];

$arguments = array_merge($default_arguments, $arguments);

$client = PantherClient::createChromeClient(null, $arguments , $options);

At the termination of the command (or even if I force cancel the command mid way) I am getting this error:

In WebDriverCurlException.php line 20:
                                                                                   
  [Facebook\WebDriver\Exception\Internal\WebDriverCurlException]                   
  Curl error thrown for http DELETE to /session/f2c85b0b97dcff0c666368402bab27ec   
                                                                                   
  Failed to connect to 127.0.0.1 port 9515 after 0 ms: Couldn't connect to server  

Any suggestion of why this happens? It would seem like the chromedriver api listening on port 9515 shutdown before that DELETE endpoint is called. But I m not sure why.

Similar to what we did on https://github.com/symfony/ux

Bumps intervention/image from 3.11.7 to 4.1.4.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Bumps actions/checkout from 6 to 7.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Summary

This PR adds an opt-in way for Redis cache stores to clear only keys managed by the configured Laravel cache prefix instead of flushing the selected Redis database.

It introduces:

• Illuminate\Contracts\Cache\CanFlushPrefix
• RedisStore::flushPrefix()
• Repository::flushPrefix() / supportsFlushingPrefix()
• php artisan cache:clear --prefix
• cache.stores.redis.flush_scope, configurable with REDIS_CACHE_FLUSH_SCOPE=prefix

The existing Redis cache flush() behavior is unchanged and continues to call FLUSHDB unless the new prefix mode is explicitly requested.

Why

Laravel's default Redis configuration has historically encouraged isolating cache data in a separate logical Redis database. That is increasingly difficult with managed Redis-compatible services:

• Redis documents that Redis Cluster only supports database zero and that SELECT cannot be used in cluster mode: https://redis.io/docs/latest/commands/select/
• Redis also documents that Redis Software and Redis Cloud do not support shared logical databases; SELECT is accepted only for compatibility and does not perform an operation: https://redis.io/docs/latest/commands/select/
• AWS documents that ElastiCache Serverless abstracts the cluster topology and that FLUSHDB / FLUSHALL always flush all keys across the cluster: https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/SupportedCommands.html

That means applications running on modern Redis Cluster, Redis Cloud, Redis Software, or ElastiCache Serverless deployments need a first-party way to clear only Laravel cache keys without clearing unrelated data that shares database zero.

Backwards Compatibility

This is intended to be backwards compatible:

• RedisStore::flush() still calls flushdb().
• cache:clear still uses the existing flush behavior by default.
• Prefix clearing is only used when cache:clear --prefix is passed or when cache.stores.redis.flush_scope is set to prefix.
• The new cache store capability is an optional contract, so existing cache store implementations are not required to add new methods.
• Prefix clearing refuses to run when the Redis cache store has an empty prefix.

Tests

• vendor/bin/pint --dirty
• git diff --check
• vendor/bin/phpunit tests/Cache/CacheRedisStoreTest.php tests/Cache/ClearCommandTest.php tests/Cache/CacheEventsTest.php
• vendor/bin/phpunit tests/Cache

The full cache suite passes. PHPUnit reports the existing notices/skips from the suite: 8 notices and 13 skipped tests.

Description This PR adds the native PHP count() function to the ExpressionLanguage component. This allows developers to use count(items) directly in expressions, simplifying code and making expressions more powerful.

Usage example

$language = new ExpressionLanguage();
$result = $language->evaluate('count([1,2,3]) > 2'); // true
$result = $language->evaluate('count(items) > 2', ['items' => ['a', 'b', 'c']]); // true

We need a method of migrating users from 2.4 to 3.x.

Things to consider:

• Migrate settings
• Migrate resources
• Migrate subscriptions / subscribers
• Migrate API Keys

AOB (please add to this list)

As a comment on the latter, once #183 is merged, we'll need to programmatically migrate users 2.4 API Keys to 3.x using something like the following

$v2ApiKey = $v2User->api_key;

$v3User->tokens()->create([
    'name' => 'v2.4 API Key',
    'token' => hash('sha256', $v2ApiKey),
    'abilities' => ['*'],
    'expires_at' => now()->addDays(90),
]);

@jbrooksuk We need to decide on the abilities and expires_at. IMO it makes sense to throw something into the upgrade documentation that old 2.4 API Keys will continue to work for up to 90 days. But if they want to use the API after that, then they'll need to generate a new API Token using the 3.x dashboard.

Summary

When a parent live component action removes and re-adds a child live component on the same DOM element, Stimulus keeps the controller instance alive — it only calls disconnect() then connect() again, not initialize(). Because createComponent() only runs in initialize(), the Component (and its ValueStore) keep the stale props from before the parent action, even though the server-rendered HTML now exposes a fresh set.

The next user input then throws Uncaught Error: Invalid model name "xyz.content" — the model name has changed, but ValueStore.has() still looks up against the old props.

Fix

In connect(), compare the current propsValue (which Stimulus has refreshed from the live data-live-props-value attribute) against component.valueStore.getOriginalProps(). When they differ, rebuild the Component.

• First connect() after initialize(): props match by construction → no rebuild.
• Plain disconnect/reconnect without any prop change: props match → no rebuild.
• Parent morph that swaps props on the same element: props diverge → rebuild.

The diagnosis and proposed fix are from @Pechynho in #3424 (confirmed working by another reporter in the thread).

Test plan

• New unit test rebuilds the Component on reconnect when props changed in between exercises the bug scenario by calling controller.disconnect() / mutating propsValue / controller.connect(), and asserts the Component instance has been swapped and the new ValueStore reflects the fresh props.
• New unit test keeps the existing Component on reconnect when props are unchanged asserts that a no-op reconnect cycle does not recreate the Component.
• Full LiveComponent controller test suite still green (109 tests).
• oxlint + oxfmt --check clean.

Fixes #3424

The Albert bridge was requiring the API version in the base URL (e.g. https://example.com/v1) and overriding completionsPath/embeddingsPath to compensate, while Generic and all other bridges expect a bare base URL and include the version in the path (/v1/chat/completions).

Drop the version validation and the path overrides so Albert delegates entirely to Generic defaults, aligning both conventions.

Octane Version

2.9

Laravel Version

12

PHP Version

8.4

What server type are you using?

FrankenPHP

Server Version

1.12

Database Driver & Version

No response

Description

The current Caddy configuration template for FrankenPHP utilizes a broad try_files directive: try_files {path} frankenphp-worker.php

This logic causes all requests for non-existent static files (e.g., versioned assets like app-v123.js after a deployment) to be forwarded to the PHP worker. In high-traffic environments, a surge of requests for missing assets triggers unnecessary PHP process execution, leading to worker saturation, increased CPU/Memory overhead, and potential system failure.

Technical Impact

• Performance: High overhead for 404 responses that should be handled at the web-server level.
• Stability: Potential DoS condition when static asset paths are brute-forced or when client-side caches request deprecated versioned files.
• Resource Allocation: PHP workers are occupied by I/O-bound requests for missing files instead of processing dynamic application logic.

Proposed Solution Refactor the Caddyfile logic to isolate static file handling. A dedicated matcher for common file extensions should be implemented to ensure that if a static file is not found on disk, Caddy returns a 404 Not Found immediately, bypassing the php_server or php_dispatch logic.

Recommended Configuration Change Define a matcher for static assets and handle them via file_server exclusively:

@static {
    path *.css *.js *.mjs *.map *.ico *.png *.jpg *.jpeg *.gif *.svg *.webp *.avif *.woff *.woff2 *.ttf *.otf *.eot *.mp4 *.webm *.ogg *.mp3 *.wav *.pdf *.zip *.txt *.xml *.json *.wasm *.webmanifest *.manifest
}

file_server @static

Steps To Reproduce

1. Deploy Laravel Octane with FrankenPHP.
2. Request a non-existent file with a .js or .css extension.
3. Observe that the request is processed by frankenphp-worker.php (returning a Laravel 404) instead of a native Caddy 404.

Version: 3.x dev demo Issue details:

• After creating an incident and setting the "Occurred at" to today with any time, the incident does not appear on the status page
• Setting the incident to yesterday does make the incident appear
• It is possibly to do with me being in Australia, even though I set the timezone in Cachet to Melbourne/Australia

Timezone set in "Manage Cachet" should also affect timezone handling in the dashboard wich is still using UTC when for example Europe/Berlin in configured.

Versions

• spatie/laravel-multitenancy: 4.1.3 (behaviour unchanged on main at time of writing)
• laravel/framework: 12.x
• PHP: 8.4

Description

When queues_are_tenant_aware_by_default is enabled, MakeQueueTenantAwareAction::bindOrForgetCurrentTenant() calls Tenant::forgetCurrent() when a NotTenantAware job starts processing, and nothing ever restores the tenant that was current before the job.

On a queue worker this goes unnoticed, because every job re-binds its own tenant and nothing meaningful runs between jobs. But when a job executes in-process — the sync driver, or dispatchSync() on any app — the job runs inside the dispatching request, so the dispatcher loses its current tenant for the remainder of the request:

$tenant->makeCurrent();

SomeNotTenantAwareJob::dispatchSync();

Tenant::current(); // null — the request continues with no tenant

Everything tenant-dependent after that point misbehaves. The loudest symptom is dispatching a TenantAware job afterwards, which throws CurrentTenantCouldNotBeDeterminedInTenantAwareJob because no tenant was current at dispatch time. Tenant-scoped queries in the same window fail silently, which is worse.

The same mechanism affects TenantAware jobs run via dispatchSync() for a different tenant than the request's: after the job, the request continues under the job's tenant instead of its own.

This contradicts the documented behaviour

From docs/basic-usage/making-queues-tenant-aware.md:

"On the other hand, a job that is not tenant aware will make no modifications to the current tenant, which may still be set from a previous job."

The current implementation does modify it — forgetCurrent() — with no restore. (I suspect the forgetCurrent() was added as hygiene so a previous job's tenant can't bleed into a not-tenant-aware job, which is good — but the docs' contract that the surrounding context's tenant survives was lost in the process.)

Reproduction (failing test against this package's suite)

Verified failing against main (032e74c): the first expectation passes (the job itself correctly runs without a tenant), the second fails with Tenant::checkCurrent() returning false. The package's existing QueueIsTenantAwareByDefaultTest passes in the same environment.

Drop this into tests/Feature/TenantAwareJobs/ — it reuses the existing NotTenantAwareTestJob test class:

<?php

use Spatie\Multitenancy\Models\Tenant;
use Spatie\Multitenancy\Tests\Feature\TenantAwareJobs\TestClasses\NotTenantAwareTestJob;
use Spatie\Valuestore\Valuestore;

beforeEach(function () {
    config()->set('multitenancy.queues_are_tenant_aware_by_default', true);
    config()->set('queue.default', 'sync');

    $this->tenant = Tenant::factory()->create();
    $this->valuestore = Valuestore::make(tempFile('tenantAware.json'))->flush();
});

it('does not lose the dispatching context\'s tenant after a sync NotTenantAware job', function () {
    $this->tenant->makeCurrent();

    dispatch(new NotTenantAwareTestJob($this->valuestore));

    // The job itself correctly ran without a tenant:
    expect($this->valuestore->get('tenantId'))->toBeNull();

    // But the dispatching context's tenant should still be current — this fails:
    expect(Tenant::checkCurrent())->toBeTrue()
        ->and(Tenant::current()->id)->toBe($this->tenant->id);
});

Who hits this in practice

• Any app running the sync driver (Laravel's fallback default when QUEUE_CONNECTION is unset)
• Any app calling dispatchSync() mid-request
• Standard Laravel test suites (QUEUE_CONNECTION=sync in phpunit.xml): a model observer that dispatches a NotTenantAware job silently drops the tenant for the rest of the test — this is how we found it. Two earlier "fixes" in our codebase (marking a job NotTenantAware, adding a Queue::fake()) turned out to be band-aids over this same root cause.

The docs and an existing test disagree — which reflects the intent?

I want to flag this carefully rather than assert it's simply a bug, because there is an existing test asserting the current behaviour: in TenantAwareJobThatCannotFindTenantTest, "it will forget any current tenant when starting a not tenant aware job" dispatches on the sync driver and then asserts assertNull(Tenant::current()) after the dispatch has returned.

Reading that test's comments ("Simulate a tenant being set from a previous queue job"), its intent looks like worker hygiene: a stale tenant from a previous job must not bleed into a not-tenant-aware job — which makes complete sense. But the final assertion observes the forgotten tenant after the dispatch returns, which on the sync driver means it also pins down the side effect described above: the dispatching context loses its tenant permanently. That post-dispatch state is where the test and the documented contract ("will make no modifications to the current tenant") seem to point in opposite directions.

So my question is: which one reflects the intended behaviour?

• If the docs are the intent (jobs run with the right tenant context, but processing a job makes no net modification to the dispatcher's current tenant), then the action needs a restore step and that one test assertion needs adjusting.
• If the test is the intent (the current tenant is genuinely meant to be gone after a not-tenant-aware job is processed in-process), then the docs sentence quoted above is misleading and apps using the sync driver or dispatchSync() need to re-bind their tenant manually — which would be worth documenting.

For what it's worth, I have a working fix for the first interpretation validated against this package's test suite (restore the previously-current tenant on JobProcessed/JobExceptionOccurred, preserving the bleed-in protection during the job itself — all existing tests pass apart from the post-dispatch assertion discussed above). I'd be happy to open a PR if you confirm that's the direction you want; equally happy if the answer is "docs need updating" instead.

A single <select> without a placeholder/empty option is auto-selected by the browser on its first <option>. In a native form POST, that first option is submitted as if picked. Inside a LiveComponent form, however, the model stayed null until the user actually interacted with the field, so a NotBlank() constraint failed even though the option appeared selected.

SetValueOntoModelFieldsPlugin already handles this for selects carrying a data-model (#469), but it only iterated over [data-model] elements. Form fields inside <form data-model="*"> are bound through their name attribute and have no data-model of their own, so they were skipped.

This widens the selector to also pick up select[name] elements and resolves their model through the existing getModelDirectiveFromElement() (which already knows how to derive the model name from name within a data-model form). The existing single-select sync logic then reflects the auto-selected option into the model — matching native browser behavior.

Added a unit test mirroring the existing #469 one, but for a select living inside a <form data-model="*">.

Summary

Extends the existing "Only To Others - Configuration" section to document how to retrieve the socket ID when using the framework adapter packages (@laravel/echo-react, @laravel/echo-vue, @laravel/echo-svelte).

Previously, this section only showed the vanilla Echo approach (Echo.socketId()), leaving framework adapter users without guidance — which led to confusion and workarounds (see laravel/echo#474).

What's added

• echo().socketId() via the exported echo() helper, for interceptor setup and outside-component usage
• useSocketId() reactive hook/composable/rune for inside-component usage, with examples for all three adapters

Related

• laravel/echo#474
• laravel/echo#499 (adds the useSocketId() hook itself)

Adds a multiselect option to the SelectListWidget:

Laravel Version

12.35.0

PHP Version

8.3.24

Database Driver & Version

No response

Description

After running frankenphp for a long time in a production environment, execute the following command:

sudo docker exec myproject php /var/www/artisan octane:reload

Will cause curl error:

production.ERROR: cURL error 77: Unable to initialize NSS: -12285 (SSL_ERROR_NO_CERTIFICATE) (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://xxx {"exception":"[object] (GuzzleHttp\Exception\RequestException(code: 0): cURL error 77: Unable to initialize NSS: -12285 (SSL_ERROR_NO_CERTIFICATE) (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://xxx at /var/www/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:276)

Can only be restored through restart

Steps To Reproduce

sudo docker exec myproject php /var/www/artisan octane:reload

Bumps postcss from 8.5.8 to 8.5.15.

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the Security Alerts page.

Note Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

This PR adds support for pushing browser history entries when a LiveComponent updates URL-bound LiveProp values.

Until now, URL updates were always done with history.replaceState(), which overwrote the current entry. With this change, components can opt in to history.pushState() so users can navigate previous component states via the browser back button (for example, previous pages in pagination or prior filter states in search UIs).

Included changes:

• Added a new pushHistoryState parameter to #[AsLiveComponent(...)] (default: false).
• Exposed this option in component metadata as push_history_state.
• Added LiveComponentMetadata::hasPushHistoryStateEnabled() to read the flag.
• Updated LiveUrlSubscriber to include a new response header:
  • X-Live-Url-Push-History-State: 1|0
• Updated frontend BackendResponse to parse the new header.
• Updated frontend URL update logic to choose:
  • history.pushState(...) when enabled
  • history.replaceState(...) otherwise (current behavior preserved)

Would it be possible to extend MaskBuilder to support more than 32 permission masks? Or are there any limitations? I know that acl_entries table has 'mask' defined as INT(11) but I can change it to bigint but don't know if this has any effect on acl?

This updates the Composer autoload hook to copy LARAVEL_INSTALLER_DEFER_HOOKS from $_ENV or $_SERVER into the process environment when getenv() cannot see it.

That lets later @php artisan ... Composer scripts inherit the deferred installer flag and avoid prompting during starter kit installs on platforms where Composer exposes the value through PHP superglobals.

Fixes #60253.

Tests:

• vendor/bin/phpunit tests/Foundation/FoundationComposerScriptsTest.php
• vendor/bin/pint --test src/Illuminate/Foundation/ComposerScripts.php tests/Foundation/FoundationComposerScriptsTest.php

symfony/ux-editor adds a single Symfony form field (EditorType) on top of multiple content-authoring editors — WYSIWYG, block and page-builder — behind one consistent API.

The core package is editor-agnostic and provides:

• a polymorphic content model: EditorContentInterface with HtmlContent, BlockContent and PageContent, plus an EditorContentFormat enum;
• EditorType form abstraction with data transformers;
• Doctrine custom types (editor_html, editor_blocks, editor_page);
• a signed upload pipeline (EditorUploadController, SignedUploadUrlGenerator, EditorUploadHandlerInterface, local handler + registry);
• a ux_editor_render Twig function (HTML sanitized, blocks via registry, page rendered in a sandboxed iframe);
• a LiveEditor trait for debounced autosave with LiveComponent;
• a debug:ux-editor console command and a WebProfiler data collector.

Concrete editors plug in through BridgeInterface + BridgeRegistry. This PR also includes three bridges as separate composer + npm sub-packages:

• symfony/ux-editor-ckeditor — CKEditor 5 (WYSIWYG family)
• symfony/ux-editor-editorjs — EditorJS (block family)
• symfony/ux-editor-grapesjs — GrapesJS (page-builder family)

PHP and JS test suites are included and passing. Documentation lives in src/Editor/doc/.

The SlackRecord used by the Slack and SlackWebhook handlers has a constructor parameter to exclude certain fields from being sent to Slack. This is a great way to log exceptions but not have them clutter up your Slack channels, for example. Currently, the configuration for the bundle doesn't have a key for this field, which means it can't be configured.

There's been a PR open (#402 by @Gwemox), but for some reason it's just been sitting there, gathering dust for some two years. It'd be great if someone could either merge it, or, in case that's not an option, offer some guidance on What To Do to get it in a mergable state.

Hi,

In order to deploy this in a production environment I'm required to specify a schema, I sadly didn't see how... Is this possibility simply not available via env variables ?

Thanks !

Since the site keeps growing and growing, especially with Toolkit Kits recipes, I think it could be a nice idea to add a search engine, based on Meilisearch.

To index:

• List of UX packages
• List of UX demos
• List of recipes, per kits, from UX Toolkit

Ref: https://symfony.com/blog/migrating-symfony-com-search-engine-to-meilisearch

Hi team, I trying to start cachet in docker, I'm getting the following error when I finish setup:

2021/07/13 18:49:48 [error] 73#73: *4 FastCGI sent in stderr: "PHP message: [2021-07-13 18:49:48] production.ERROR: ErrorException: count(): Parameter must be an array or an object that implements Countable in /var/www/html/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Builder.php:1161
cachet_1    | Stack trace:
cachet_1    | #0 [internal function]: Illuminate\Foundation\Bootstrap\HandleExceptions->handleError(2, 'count(): Parame...', '/var/www/html/v...', 1161, Array)
cachet_1    | #1 /var/www/html/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Builder.php(1161): count(NULL)
cachet_1    | #2 /var/www/html/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Builder.php(1192): Illuminate\Database\Eloquent\Builder->callScope(Object(Closure))
cachet_1    | #3 /var/www/html/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Builder.php(314): Illuminate\Database\Eloquent\Builder->applyScopes()
cachet_1    | #4 /var/www/html/app/Http/Controllers/Dashboard/DashboardController.php(79): Illuminate\Database\Eloquent\Builder->get()
cachet_1    | #5 [internal function]: CachetHQ\Cachet\Http\Controllers\Dashboard\DashboardController" while reading response header from upstream, client: 172.23.0.1, server: localhost, request: "GET /dashboard HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "localhost:8000", referrer: "http://localhost:8000/setup"

Cachet version v2.3.18 Can you help me please, thanks

Bumps vite and laravel-vite-plugin. These dependencies needed to be updated together. Updates vite from 6.4.2 to 8.1.3

Updates laravel-vite-plugin from 1.3.0 to 3.1.0

import { defineConfig } from 'vite'; import laravel from 'laravel-vite-plugin';

export default defineConfig({ plugins: [ laravel({ input: ['resources/css/app.css', 'resources/js/app.js'], refresh: true,

•       assets: [
  

•           'resources/images/**',
  

•           'resources/favicons/**',
  

•       ],
    }),
  

  ], });

On the record update for an active incident, there needs to be a tie to the component to be update the current component status.

When trying to install Cachet version 3 on Ubuntu 24.04 I am getting the following error as Ubuntu are only shipping PHP version 8.3

Is there a method we can use to install this on Ubuntu 24.04?

Fixes #50

TODO:

• Actually silence the logs in each test where it's needed

Fixes #22223

Cachet v3.x-dev installed on Debian 12 following the instructions in the documentation and served by Caddy.

This problem also occurs in the demo system.

If an incident is created with any status other than "Fixed", and is then updated to "Fixed", the status page shows the correct information.

If an incident is created with any status other than "Fixed" and is then updated to any status other than "Fixed" and is then updated to "Fixed", the status page still shows "Some systems are experiencing issues." even if all the components are in the correct working state. The only way to fix this appears to be to either delete the incident or delete all the updates other than the "Fixed" one.

Package

filament/forms

Package Version

v5.6.8

Laravel Version

v13.19.0

Livewire Version

v4.3.3

PHP Version

PHP 8.5.6

Problem description

When saving a form with a MorphToSelect, if the selected Type's modifyOptionsQueryUsing is defined and the query is modified with a join (for example, through orderByLeftPowerJoins()), the following error will be thrown during validation:

SQLSTATE[HY000]: General error: 1 ambiguous column name: id

This is due to how Type defines getOptionLabel() in its setUp method, in particular when a where clause is added to the query:

#vendor/filament/forms/src/Components/MorphToSelect/Type.php::179
$query->where($query->getModel()->getKeyName(), $value);

The fix should be as simple as using the qualified key name instead:

--- a/packages/forms/src/Components/MorphToSelect/Type.php
+++ b/packages/forms/src/Components/MorphToSelect/Type.php
@@ -176,7 +176,7 @@ class Type
         $this->getOptionLabelUsing(function (Select $component, $value) {
             $query = $this->getModel()::query();
 
-            $query->where($query->getModel()->getKeyName(), $value);
+            $query->where($query->getModel()->getQualifiedKeyName(), $value);
 
             if ($this->modifyOptionsQueryUsing) {
                 $query = $component->evaluate($this->modifyOptionsQueryUsing, [

Expected behavior

The validation would succeed and the record would be created. This kind of code/configuration used to be possible on version 3.x - I know that because I found this behaviour while upgrading a 3.x app to 5.x.

Steps to reproduce

Follow the README in the reproduction repository

Reproduction repository (issue will be closed if this is not valid)

https://github.com/gp-lnuff/filament-issue/tree/morphtoselect-validation

Relevant log output

[2026-07-14 10:38:12] local.ERROR: SQLSTATE[HY000]: General error: 1 ambiguous column name: id (Connection: sqlite, Database: /app/database/database.sqlite, SQL: select "bars".* from "bars" left join "foos" on "bars"."foo_id" = "foos"."id" where "id" = 5 order by "foos"."description" asc, "description" asc limit 1) {"userId":1,"exception":"[object] (Illuminate\\Database\\QueryException(code: HY000): SQLSTATE[HY000]: General error: 1 ambiguous column name: id (Connection: sqlite, Database: /app/database/database.sqlite, SQL: select \"bars\".* from \"bars\" left join \"foos\" on \"bars\".\"foo_id\" = \"foos\".\"id\" where \"id\" = 5 order by \"foos\".\"description\" asc, \"description\" asc limit 1) at /app/vendor/laravel/framework/src/Illuminate/Database/Connection.php:857)
[stacktrace]
#0 /app/vendor/laravel/framework/src/Illuminate/Database/Connection.php(813): Illuminate\\Database\\Connection->runQueryCallback('select \"bars\".*...', Array, Object(Closure))
#1 /app/vendor/laravel/framework/src/Illuminate/Database/Connection.php(426): Illuminate\\Database\\Connection->run('select \"bars\".*...', Array, Object(Closure))
#2 /app/vendor/laravel/framework/src/Illuminate/Database/Query/Builder.php(3573): Illuminate\\Database\\Connection->select('select \"bars\".*...', Array, true, Array)
#3 /app/vendor/laravel/framework/src/Illuminate/Database/Query/Builder.php(3557): Illuminate\\Database\\Query\\Builder->runSelect()
#4 /app/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Builder.php(908): Illuminate\\Database\\Query\\Builder->get(Array)
#5 /app/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Builder.php(890): Illuminate\\Database\\Eloquent\\Builder->getModels(Array)
#6 /app/vendor/laravel/framework/src/Illuminate/Database/Concerns/BuildsQueries.php(366): Illuminate\\Database\\Eloquent\\Builder->get(Array)
#7 /app/vendor/filament/forms/src/Components/MorphToSelect/Type.php(187): Illuminate\\Database\\Eloquent\\Builder->first()
#8 /app/vendor/filament/support/src/Concerns/EvaluatesClosures.php(36): Filament\\Forms\\Components\\MorphToSelect\\Type->{closure:Filament\\Forms\\Components\\MorphToSelect\\Type::setUp():176}(Object(Filament\\Forms\\Components\\Select), 5)
#9 /app/vendor/filament/forms/src/Components/MorphToSelect.php(121): Filament\\Support\\Components\\Component->evaluate(Object(Closure), Array)
#10 /app/vendor/filament/support/src/Concerns/EvaluatesClosures.php(36): Filament\\Forms\\Components\\MorphToSelect->{closure:{closure:Filament\\Forms\\Components\\MorphToSelect::setUp():74}:121}(Object(Filament\\Forms\\Components\\Select), Object(Filament\\Schemas\\Components\\Utilities\\Get), 5)
#11 /app/vendor/filament/forms/src/Components/Select.php(599): Filament\\Support\\Components\\Component->evaluate(Object(Closure), Array)
#12 /app/vendor/filament/forms/src/Components/Select.php(1788): Filament\\Forms\\Components\\Select->getOptionLabel(false)
#13 /app/vendor/filament/forms/src/Components/Concerns/CanBeValidated.php(810): Filament\\Forms\\Components\\Select->getInValidationRuleValues()
#14 /app/vendor/filament/forms/src/Components/Concerns/CanBeValidated.php(854): Filament\\Forms\\Components\\Field->getInValidationRule()
#15 /app/vendor/filament/forms/src/Components/Concerns/CanBeValidated.php(910): Filament\\Forms\\Components\\Field->getValidationRules()
#16 /app/vendor/filament/schemas/src/Concerns/CanBeValidated.php(85): Filament\\Forms\\Components\\Field->dehydrateValidationRules(Array)
#17 /app/vendor/filament/schemas/src/Concerns/CanBeValidated.php(95): Filament\\Schemas\\Schema->getValidationRules()
#18 /app/vendor/filament/schemas/src/Concerns/CanBeValidated.php(115): Filament\\Schemas\\Schema->getValidationRules()
#19 /app/vendor/filament/schemas/src/Concerns/HasState.php(450): Filament\\Schemas\\Schema->validate()
#20 /app/vendor/filament/schemas/src/Components/Concerns/CanBeHidden.php(270): Filament\\Schemas\\Schema->{closure:Filament\\Schemas\\Concerns\\HasState::getState():449}()
#21 /app/vendor/filament/schemas/src/Concerns/HasState.php(449): Filament\\Schemas\\Components\\Component::withVisibilityCache(Object(Closure))
#22 /app/vendor/filament/filament/src/Resources/Pages/EditRecord.php(168): Filament\\Schemas\\Schema->getState(true, Object(Closure))
#23 /app/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Filament\\Resources\\Pages\\EditRecord->save(true, true)
#24 /app/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::{closure:Illuminate\\Container\\BoundMethod::call():35}()
#25 /app/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#26 /app/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#27 /app/vendor/livewire/livewire/src/Wrapped.php(23): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array)
#28 /app/vendor/livewire/livewire/src/Mechanisms/HandleComponents/HandleComponents.php(708): Livewire\\Wrapped->__call('save', Array)
#29 /app/vendor/livewire/livewire/src/Mechanisms/HandleComponents/HandleComponents.php(242): Livewire\\Mechanisms\\HandleComponents\\HandleComponents->callMethods(Object(App\\Filament\\Resources\\Morphables\\Pages\\EditMorphable), Array, Object(Livewire\\Mechanisms\\HandleComponents\\ComponentContext))
#30 /app/vendor/livewire/livewire/src/LivewireManager.php(131): Livewire\\Mechanisms\\HandleComponents\\HandleComponents->update(Array, Array, Array)
#31 /app/vendor/livewire/livewire/src/Mechanisms/HandleRequests/HandleRequests.php(205): Livewire\\LivewireManager->update(Array, Array, Array)
#32 /app/vendor/laravel/framework/src/Illuminate/Routing/ControllerDispatcher.php(46): Livewire\\Mechanisms\\HandleRequests\\HandleRequests->handleUpdate()
#33 /app/vendor/laravel/framework/src/Illuminate/Routing/Route.php(275): Illuminate\\Routing\\ControllerDispatcher->dispatch(Object(Illuminate\\Routing\\Route), Object(Livewire\\Mechanisms\\HandleRequests\\HandleRequests), 'handleUpdate')
#34 /app/vendor/laravel/framework/src/Illuminate/Routing/Route.php(215): Illuminate\\Routing\\Route->runController()
#35 /app/vendor/laravel/framework/src/Illuminate/Routing/Router.php(822): Illuminate\\Routing\\Route->run()
#36 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(180): Illuminate\\Routing\\Router->{closure:Illuminate\\Routing\\Router::runRouteWithinStack():821}(Object(Illuminate\\Http\\Request))
#37 /app/vendor/livewire/livewire/src/Mechanisms/HandleRequests/RequireLivewireHeaders.php(19): Illuminate\\Pipeline\\Pipeline->{closure:Illuminate\\Pipeline\\Pipeline::prepareDestination():178}(Object(Illuminate\\Http\\Request))
#38 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Livewire\\Mechanisms\\HandleRequests\\RequireLivewireHeaders->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#39 /app/vendor/laravel/framework/src/Illuminate/Routing/Middleware/SubstituteBindings.php(52): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#40 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Routing\\Middleware\\SubstituteBindings->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#41 /app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/PreventRequestForgery.php(104): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#42 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Foundation\\Http\\Middleware\\PreventRequestForgery->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#43 /app/vendor/laravel/framework/src/Illuminate/View/Middleware/ShareErrorsFromSession.php(48): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#44 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\View\\Middleware\\ShareErrorsFromSession->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#45 /app/vendor/laravel/framework/src/Illuminate/Session/Middleware/StartSession.php(120): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#46 /app/vendor/laravel/framework/src/Illuminate/Session/Middleware/StartSession.php(63): Illuminate\\Session\\Middleware\\StartSession->handleStatefulRequest(Object(Illuminate\\Http\\Request), Object(Illuminate\\Session\\Store), Object(Closure))
#47 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Session\\Middleware\\StartSession->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#48 /app/vendor/laravel/framework/src/Illuminate/Cookie/Middleware/AddQueuedCookiesToResponse.php(36): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#49 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Cookie\\Middleware\\AddQueuedCookiesToResponse->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#50 /app/vendor/laravel/framework/src/Illuminate/Cookie/Middleware/EncryptCookies.php(74): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#51 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Cookie\\Middleware\\EncryptCookies->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#52 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(137): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#53 /app/vendor/laravel/framework/src/Illuminate/Routing/Router.php(821): Illuminate\\Pipeline\\Pipeline->then(Object(Closure))
#54 /app/vendor/laravel/framework/src/Illuminate/Routing/Router.php(800): Illuminate\\Routing\\Router->runRouteWithinStack(Object(Illuminate\\Routing\\Route), Object(Illuminate\\Http\\Request))
#55 /app/vendor/laravel/framework/src/Illuminate/Routing/Router.php(764): Illuminate\\Routing\\Router->runRoute(Object(Illuminate\\Http\\Request), Object(Illuminate\\Routing\\Route))
#56 /app/vendor/laravel/framework/src/Illuminate/Routing/Router.php(753): Illuminate\\Routing\\Router->dispatchToRoute(Object(Illuminate\\Http\\Request))
#57 /app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(200): Illuminate\\Routing\\Router->dispatch(Object(Illuminate\\Http\\Request))
#58 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(180): Illuminate\\Foundation\\Http\\Kernel->{closure:Illuminate\\Foundation\\Http\\Kernel::dispatchToRouter():197}(Object(Illuminate\\Http\\Request))
#59 /app/vendor/livewire/livewire/src/Features/SupportDisablingBackButtonCache/DisableBackButtonCacheMiddleware.php(19): Illuminate\\Pipeline\\Pipeline->{closure:Illuminate\\Pipeline\\Pipeline::prepareDestination():178}(Object(Illuminate\\Http\\Request))
#60 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Livewire\\Features\\SupportDisablingBackButtonCache\\DisableBackButtonCacheMiddleware->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#61 /app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/ConvertEmptyStringsToNull.php(27): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#62 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Foundation\\Http\\Middleware\\ConvertEmptyStringsToNull->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#63 /app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/TrimStrings.php(47): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#64 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Foundation\\Http\\Middleware\\TrimStrings->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#65 /app/vendor/laravel/framework/src/Illuminate/Http/Middleware/ValidatePostSize.php(27): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#66 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Http\\Middleware\\ValidatePostSize->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#67 /app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/PreventRequestsDuringMaintenance.php(109): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#68 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Foundation\\Http\\Middleware\\PreventRequestsDuringMaintenance->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#69 /app/vendor/laravel/framework/src/Illuminate/Http/Middleware/HandleCors.php(61): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#70 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Http\\Middleware\\HandleCors->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#71 /app/vendor/laravel/framework/src/Illuminate/Http/Middleware/TrustProxies.php(58): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#72 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Http\\Middleware\\TrustProxies->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#73 /app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/InvokeDeferredCallbacks.php(22): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#74 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Foundation\\Http\\Middleware\\InvokeDeferredCallbacks->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#75 /app/vendor/laravel/framework/src/Illuminate/Http/Middleware/ValidatePathEncoding.php(28): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#76 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Http\\Middleware\\ValidatePathEncoding->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#77 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(137): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#78 /app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(175): Illuminate\\Pipeline\\Pipeline->then(Object(Closure))
#79 /app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(144): Illuminate\\Foundation\\Http\\Kernel->sendRequestThroughRouter(Object(Illuminate\\Http\\Request))
#80 /app/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1220): Illuminate\\Foundation\\Http\\Kernel->handle(Object(Illuminate\\Http\\Request))
#81 /app/public/index.php(20): Illuminate\\Foundation\\Application->handleRequest(Object(Illuminate\\Http\\Request))
#82 {main}

[previous exception] [object] (PDOException(code: HY000): SQLSTATE[HY000]: General error: 1 ambiguous column name: id at /app/vendor/laravel/framework/src/Illuminate/Database/Connection.php:435)
[stacktrace]
#0 /app/vendor/laravel/framework/src/Illuminate/Database/Connection.php(435): PDO->prepare('select \"bars\".*...')
#1 /app/vendor/laravel/framework/src/Illuminate/Database/Connection.php(846): Illuminate\\Database\\Connection->{closure:Illuminate\\Database\\Connection::select():426}('select \"bars\".*...', Array)
#2 /app/vendor/laravel/framework/src/Illuminate/Database/Connection.php(813): Illuminate\\Database\\Connection->runQueryCallback('select \"bars\".*...', Array, Object(Closure))
#3 /app/vendor/laravel/framework/src/Illuminate/Database/Connection.php(426): Illuminate\\Database\\Connection->run('select \"bars\".*...', Array, Object(Closure))
#4 /app/vendor/laravel/framework/src/Illuminate/Database/Query/Builder.php(3573): Illuminate\\Database\\Connection->select('select \"bars\".*...', Array, true, Array)
#5 /app/vendor/laravel/framework/src/Illuminate/Database/Query/Builder.php(3557): Illuminate\\Database\\Query\\Builder->runSelect()
#6 /app/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Builder.php(908): Illuminate\\Database\\Query\\Builder->get(Array)
#7 /app/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Builder.php(890): Illuminate\\Database\\Eloquent\\Builder->getModels(Array)
#8 /app/vendor/laravel/framework/src/Illuminate/Database/Concerns/BuildsQueries.php(366): Illuminate\\Database\\Eloquent\\Builder->get(Array)
#9 /app/vendor/filament/forms/src/Components/MorphToSelect/Type.php(187): Illuminate\\Database\\Eloquent\\Builder->first()
#10 /app/vendor/filament/support/src/Concerns/EvaluatesClosures.php(36): Filament\\Forms\\Components\\MorphToSelect\\Type->{closure:Filament\\Forms\\Components\\MorphToSelect\\Type::setUp():176}(Object(Filament\\Forms\\Components\\Select), 5)
#11 /app/vendor/filament/forms/src/Components/MorphToSelect.php(121): Filament\\Support\\Components\\Component->evaluate(Object(Closure), Array)
#12 /app/vendor/filament/support/src/Concerns/EvaluatesClosures.php(36): Filament\\Forms\\Components\\MorphToSelect->{closure:{closure:Filament\\Forms\\Components\\MorphToSelect::setUp():74}:121}(Object(Filament\\Forms\\Components\\Select), Object(Filament\\Schemas\\Components\\Utilities\\Get), 5)
#13 /app/vendor/filament/forms/src/Components/Select.php(599): Filament\\Support\\Components\\Component->evaluate(Object(Closure), Array)
#14 /app/vendor/filament/forms/src/Components/Select.php(1788): Filament\\Forms\\Components\\Select->getOptionLabel(false)
#15 /app/vendor/filament/forms/src/Components/Concerns/CanBeValidated.php(810): Filament\\Forms\\Components\\Select->getInValidationRuleValues()
#16 /app/vendor/filament/forms/src/Components/Concerns/CanBeValidated.php(854): Filament\\Forms\\Components\\Field->getInValidationRule()
#17 /app/vendor/filament/forms/src/Components/Concerns/CanBeValidated.php(910): Filament\\Forms\\Components\\Field->getValidationRules()
#18 /app/vendor/filament/schemas/src/Concerns/CanBeValidated.php(85): Filament\\Forms\\Components\\Field->dehydrateValidationRules(Array)
#19 /app/vendor/filament/schemas/src/Concerns/CanBeValidated.php(95): Filament\\Schemas\\Schema->getValidationRules()
#20 /app/vendor/filament/schemas/src/Concerns/CanBeValidated.php(115): Filament\\Schemas\\Schema->getValidationRules()
#21 /app/vendor/filament/schemas/src/Concerns/HasState.php(450): Filament\\Schemas\\Schema->validate()
#22 /app/vendor/filament/schemas/src/Components/Concerns/CanBeHidden.php(270): Filament\\Schemas\\Schema->{closure:Filament\\Schemas\\Concerns\\HasState::getState():449}()
#23 /app/vendor/filament/schemas/src/Concerns/HasState.php(449): Filament\\Schemas\\Components\\Component::withVisibilityCache(Object(Closure))
#24 /app/vendor/filament/filament/src/Resources/Pages/EditRecord.php(168): Filament\\Schemas\\Schema->getState(true, Object(Closure))
#25 /app/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Filament\\Resources\\Pages\\EditRecord->save(true, true)
#26 /app/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\\Container\\BoundMethod::{closure:Illuminate\\Container\\BoundMethod::call():35}()
#27 /app/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(96): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#28 /app/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#29 /app/vendor/livewire/livewire/src/Wrapped.php(23): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array)
#30 /app/vendor/livewire/livewire/src/Mechanisms/HandleComponents/HandleComponents.php(708): Livewire\\Wrapped->__call('save', Array)
#31 /app/vendor/livewire/livewire/src/Mechanisms/HandleComponents/HandleComponents.php(242): Livewire\\Mechanisms\\HandleComponents\\HandleComponents->callMethods(Object(App\\Filament\\Resources\\Morphables\\Pages\\EditMorphable), Array, Object(Livewire\\Mechanisms\\HandleComponents\\ComponentContext))
#32 /app/vendor/livewire/livewire/src/LivewireManager.php(131): Livewire\\Mechanisms\\HandleComponents\\HandleComponents->update(Array, Array, Array)
#33 /app/vendor/livewire/livewire/src/Mechanisms/HandleRequests/HandleRequests.php(205): Livewire\\LivewireManager->update(Array, Array, Array)
#34 /app/vendor/laravel/framework/src/Illuminate/Routing/ControllerDispatcher.php(46): Livewire\\Mechanisms\\HandleRequests\\HandleRequests->handleUpdate()
#35 /app/vendor/laravel/framework/src/Illuminate/Routing/Route.php(275): Illuminate\\Routing\\ControllerDispatcher->dispatch(Object(Illuminate\\Routing\\Route), Object(Livewire\\Mechanisms\\HandleRequests\\HandleRequests), 'handleUpdate')
#36 /app/vendor/laravel/framework/src/Illuminate/Routing/Route.php(215): Illuminate\\Routing\\Route->runController()
#37 /app/vendor/laravel/framework/src/Illuminate/Routing/Router.php(822): Illuminate\\Routing\\Route->run()
#38 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(180): Illuminate\\Routing\\Router->{closure:Illuminate\\Routing\\Router::runRouteWithinStack():821}(Object(Illuminate\\Http\\Request))
#39 /app/vendor/livewire/livewire/src/Mechanisms/HandleRequests/RequireLivewireHeaders.php(19): Illuminate\\Pipeline\\Pipeline->{closure:Illuminate\\Pipeline\\Pipeline::prepareDestination():178}(Object(Illuminate\\Http\\Request))
#40 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Livewire\\Mechanisms\\HandleRequests\\RequireLivewireHeaders->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#41 /app/vendor/laravel/framework/src/Illuminate/Routing/Middleware/SubstituteBindings.php(52): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#42 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Routing\\Middleware\\SubstituteBindings->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#43 /app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/PreventRequestForgery.php(104): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#44 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Foundation\\Http\\Middleware\\PreventRequestForgery->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#45 /app/vendor/laravel/framework/src/Illuminate/View/Middleware/ShareErrorsFromSession.php(48): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#46 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\View\\Middleware\\ShareErrorsFromSession->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#47 /app/vendor/laravel/framework/src/Illuminate/Session/Middleware/StartSession.php(120): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#48 /app/vendor/laravel/framework/src/Illuminate/Session/Middleware/StartSession.php(63): Illuminate\\Session\\Middleware\\StartSession->handleStatefulRequest(Object(Illuminate\\Http\\Request), Object(Illuminate\\Session\\Store), Object(Closure))
#49 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Session\\Middleware\\StartSession->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#50 /app/vendor/laravel/framework/src/Illuminate/Cookie/Middleware/AddQueuedCookiesToResponse.php(36): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#51 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Cookie\\Middleware\\AddQueuedCookiesToResponse->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#52 /app/vendor/laravel/framework/src/Illuminate/Cookie/Middleware/EncryptCookies.php(74): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#53 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Cookie\\Middleware\\EncryptCookies->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#54 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(137): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#55 /app/vendor/laravel/framework/src/Illuminate/Routing/Router.php(821): Illuminate\\Pipeline\\Pipeline->then(Object(Closure))
#56 /app/vendor/laravel/framework/src/Illuminate/Routing/Router.php(800): Illuminate\\Routing\\Router->runRouteWithinStack(Object(Illuminate\\Routing\\Route), Object(Illuminate\\Http\\Request))
#57 /app/vendor/laravel/framework/src/Illuminate/Routing/Router.php(764): Illuminate\\Routing\\Router->runRoute(Object(Illuminate\\Http\\Request), Object(Illuminate\\Routing\\Route))
#58 /app/vendor/laravel/framework/src/Illuminate/Routing/Router.php(753): Illuminate\\Routing\\Router->dispatchToRoute(Object(Illuminate\\Http\\Request))
#59 /app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(200): Illuminate\\Routing\\Router->dispatch(Object(Illuminate\\Http\\Request))
#60 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(180): Illuminate\\Foundation\\Http\\Kernel->{closure:Illuminate\\Foundation\\Http\\Kernel::dispatchToRouter():197}(Object(Illuminate\\Http\\Request))
#61 /app/vendor/livewire/livewire/src/Features/SupportDisablingBackButtonCache/DisableBackButtonCacheMiddleware.php(19): Illuminate\\Pipeline\\Pipeline->{closure:Illuminate\\Pipeline\\Pipeline::prepareDestination():178}(Object(Illuminate\\Http\\Request))
#62 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Livewire\\Features\\SupportDisablingBackButtonCache\\DisableBackButtonCacheMiddleware->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#63 /app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/ConvertEmptyStringsToNull.php(27): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#64 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Foundation\\Http\\Middleware\\ConvertEmptyStringsToNull->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#65 /app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/TrimStrings.php(47): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#66 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Foundation\\Http\\Middleware\\TrimStrings->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#67 /app/vendor/laravel/framework/src/Illuminate/Http/Middleware/ValidatePostSize.php(27): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#68 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Http\\Middleware\\ValidatePostSize->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#69 /app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/PreventRequestsDuringMaintenance.php(109): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#70 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Foundation\\Http\\Middleware\\PreventRequestsDuringMaintenance->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#71 /app/vendor/laravel/framework/src/Illuminate/Http/Middleware/HandleCors.php(61): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#72 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Http\\Middleware\\HandleCors->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#73 /app/vendor/laravel/framework/src/Illuminate/Http/Middleware/TrustProxies.php(58): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#74 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Http\\Middleware\\TrustProxies->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#75 /app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/InvokeDeferredCallbacks.php(22): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#76 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Foundation\\Http\\Middleware\\InvokeDeferredCallbacks->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#77 /app/vendor/laravel/framework/src/Illuminate/Http/Middleware/ValidatePathEncoding.php(28): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#78 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(219): Illuminate\\Http\\Middleware\\ValidatePathEncoding->handle(Object(Illuminate\\Http\\Request), Object(Closure))
#79 /app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(137): Illuminate\\Pipeline\\Pipeline->{closure:{closure:Illuminate\\Pipeline\\Pipeline::carry():194}:195}(Object(Illuminate\\Http\\Request))
#80 /app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(175): Illuminate\\Pipeline\\Pipeline->then(Object(Closure))
#81 /app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(144): Illuminate\\Foundation\\Http\\Kernel->sendRequestThroughRouter(Object(Illuminate\\Http\\Request))
#82 /app/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1220): Illuminate\\Foundation\\Http\\Kernel->handle(Object(Illuminate\\Http\\Request))
#83 /app/public/index.php(20): Illuminate\\Foundation\\Application->handleRequest(Object(Illuminate\\Http\\Request))
#84 {main}
"}

On Windows I get the error message "Symfony\Component\Panther\Exception\RuntimeException: Could not start chrome. Exit code: 1 (General error). Error output: The command "." is either misspelled or could not be found." To fix the issue on Windows I changed the hardcoded path "./drivers" in ChromeManager::findChromeDriverBinary (line 89 in version 2.2.0) to ".\drivers".

Searching for the issue I found that in some older versions of Panther it was possible to create a ChromeClient directly, telling it the drivers-path as a parameter, but this seems to be removed and I couldn't find a way to do it with the current version. (Using Client::createChromeClient() with the binary-path does not work either, it throws a "Facebook\WebDriver\Exception", also setting PANTHER_CHROME_BINARY to my path did not change anything.)

Question: Am I missing something or can I still set a custom drivers-path somehow? Or should the hardcoded path in ChromeManager use the DIRECTORY_SEPARATOR instead of a slash?

Adds QUERY to the list of cacheable, safe HTTP methods in CachingHttpClient.

QUERY carries its payload in the request body, so:

• a body no longer disqualifies a QUERY request from caching (only a non-string/streamed body does)
• the cache key now folds in the request body and Content-Type, so different QUERY payloads to the same URL don't collide in the cache

Following old internal discussion, I would like to push the usage and auto-configuration of symfony.cli.yaml symfony.local.yaml file with Symfony recipes, in order to improve the DX when working with the Symfony CLI.

Requires:

• https://github.com/symfony-cli/symfony-cli/pull/669, for the config file name
• https://github.com/symfony-cli/symfony-cli/pull/668, for open configuration option

Bumps shivammathur/setup-php from 2 to 2.37.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the Security Alerts page.

Conflict between options [-i|--invokable] and [-i| --id=ID] The App ID

Bumps the dev-dependencies group with 4 updates: autoprefixer, postcss, prettier and vite.

Updates autoprefixer from 10.5.1 to 10.5.2

Updates postcss from 8.5.15 to 8.5.16

Updates prettier from 3.8.4 to 3.9.4

Updates vite from 8.1.0 to 8.1.2

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

Laravel Version

13.12.0

PHP Version

8.5.0

Database Driver & Version

No response

Description

The v13.9.0 release included a fix that changes the serialization of array fields in multipart forms (See PR #59984). As far as I understand, this was intended as a minor fix that shouldn't cause any regressions. But it did break some things, for example in the laravel/ai package.

I haven't looked into this too much, but it seems like some parsers interpret multipart forms differently, and the change in serialization breaks at least some Python parsers.

Here's an AI-generated summary of the issues I've ran into debugging with Gemini:

The Serialization Discrepancy

When passing an array value such as ['timestamp_granularities' => ['segment']] in a multipart request:

Before v13.9.0: Laravel serialized the array by repeating the exact key name:

Content-Disposition: form-data; name="timestamp_granularities"

segment

After v13.9.0: Guzzle delegates serialization to PSR-7, which appends PHP-style brackets [] to the key name:

Content-Disposition: form-data; name="timestamp_granularities[]"

segment

Why this breaks Python / FastAPI / Pydantic APIs

Unlike PHP, many API backends built in Python (using FastAPI, Pydantic, or python-multipart ) do not interpret trailing [] as arrays automatically.

Instead, the parser:

1. Looks strictly for the exact parameter name ( timestamp_granularities ).
2. Treats timestamp_granularities[] as an unrelated, unknown key and discards it.
3. Sees the parameter timestamp_granularities as missing/empty, resulting in 422 Unprocessable Entity validation errors (e.g. timestamp granularity must be set to ['segment'], got [] ).

This regression breaks out-of-the-box integrations with third-party APIs served by Python backends (such as Mistral AI's Voxtral STT).

Steps To Reproduce

I reproduced this error using laravel/ai. You can see more details in this PR: laravel/ai/pull/671

Description

When running Laravel under Octane with FrankenPHP, a generator callback passed to response()->stream() returns a 200 OK response with Content-Length: 0 and no body.

The same streamed response implemented with echo + flush() works and returns the expected SSE body.

This appears to be in Octane's FrankenPHP response handling. I originally filed this in laravel/framework, but the failing path is in the FrankenPHP client:

• Framework issue: https://github.com/laravel/framework/issues/60406
• Proposed fix: https://github.com/laravel/octane/pull/1141

Observed versions:

• Laravel Framework: 13.14.0
• Laravel Octane: 2.17.4
• FrankenPHP: 1.12.3
• PHP: 8.5.6

Steps To Reproduce

Add these two routes to a Laravel app running under Octane/FrankenPHP:

use Illuminate\Support\Facades\Route;

Route::get('/sse-yield', fn () => response()->stream(function (): iterable {
    yield "data: hello\n\n";
    yield "data: [DONE]\n\n";
}, headers: ['Content-Type' => 'text/event-stream']));

Route::get('/sse-echo', fn () => response()->stream(function (): void {
    echo "data: hello\n\n";
    flush();

    echo "data: [DONE]\n\n";
    flush();
}, headers: ['Content-Type' => 'text/event-stream']));

Run Octane with FrankenPHP:

php artisan octane:frankenphp --workers=4 --watch

Request both endpoints:

curl -i http://localhost:8000/sse-yield
curl -i http://localhost:8000/sse-echo

Observed result for /sse-yield:

HTTP/1.1 200 OK
Content-Type: text/event-stream; charset=utf-8
X-Accel-Buffering: no
Content-Length: 0

Observed result for /sse-echo:

HTTP/1.1 200 OK
Content-Type: text/event-stream; charset=utf-8
Transfer-Encoding: chunked

data: hello

data: [DONE]

Expected result: /sse-yield should stream the yielded chunks, like it does outside this Octane/FrankenPHP path, or like the echo implementation does.

I would like to suggest a new component, ShareLink

Similar to the CalendarLink component, it would allow you to generate URLs for sharing a page across multiple platforms (email, Facebook, X, Threads, WhatsApp, etc.) using twig functions ux_share_link and ux_share_links

WDYT ?

Note: We are not looking for a community member to build this feature, it will be handled a member of the Filament core team when we have availability.

unknown error: Chrome failed to start: crashed. (unknown error: DevToolsActivePort file doesn't exist) (The process started from chrome location /usr/bin/google-chrome is no longer running, so ChromeDriver is assuming that Chrome has crashed.)

This error occurs on ubuntu 22.04 On Mac OS everything worked fine

This fixes a loop where Worker keeps dispatching an envelope after its batch handler has already acknowledged or rejected the message.

Why it happens

While a batch is waiting for more messages, Worker saves one envelope for its batch handler in DeferredBatchMessageQueue.

The saved DeferredBatchMessage contains two important pieces of state:

• its envelope has NoAutoAckStamp, which records that the handler did not acknowledge the message during its first dispatch; and
• its acked property refers to the boolean changed later by the message's Acknowledger.

When another message fills the batch, the handler processes the batch and calls ack() or nack() for every message. This changes the saved message's acked property to true, but its envelope remains in DeferredBatchMessageQueue with NoAutoAckStamp.

On the next empty worker loop, Worker::flush() removes that saved entry and dispatches its envelope with FlushBatchHandlersStamp. After the dispatch, the existing code decides whether to save the envelope again:

if (!$deferredMessage->acked && !$noAutoAckStamp) {
    $this->acks[] = [$transportName, $envelope, $e];
} elseif ($noAutoAckStamp) {
    $this->unacks->add(/* ... */);
}

For a completed message, the first condition is false because acked is true. The second condition is still true because the saved envelope keeps NoAutoAckStamp. The completed envelope is therefore saved again.

The same steps repeat on every empty worker loop:

1. remove the saved envelope;
2. dispatch it;
3. see NoAutoAckStamp; and
4. save it again.

This is an in-process loop; the transport does not return the message again. In the reproduced idle case, the batch is empty, so its process() method has no jobs to run. The extra dispatches still run the message bus and its middleware.

The fix

Worker::flush() now checks DeferredBatchMessage::$acked twice:

1. Before dispatch: the batch may have completed while this envelope was waiting in the flush queue. In that case, no flush dispatch is needed.
2. After dispatch: the flush itself may have completed the batch. In that case, the envelope must not be saved again.

A message with acked === false follows the existing behavior.

Test

The regression test sends 10 messages to a batch handler with a batch size of 10. It uses MockClock to keep the worker running for 30 simulated seconds after the batch completes.

Before this fix, the 41 dispatches are the 10 received messages, 30 idle-loop dispatches, and one final dispatch when the worker stops. After this fix, each received message is dispatched exactly once.

Currently, when handleSignal() needs access to the input or output, you first need to store the objects in properties because they are not passed to the method, for example:

use Symfony\Component\Console\Attribute\AsCommand;
use Symfony\Component\Console\Command\SignalableCommandInterface;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;

#[AsCommand(name: 'app:my-command')]
class MyCommand implements SignalableCommandInterface
{
    private ?OutputInterface $output = null;

    public function __invoke(OutputInterface $output): int
    {
        $this->output = $output;

        // ...
    }

    public function handleSignal(int $signal, int|false $previousExitCode = 0): int|false
    {
        $this->output?->writeln(\sprintf('Received signal %d.', $signal));

        return false;
    }
}

This PR adds two new optional parameters to SignalableCommandInterface::handleSignal(): ?InputInterface $input = null and ?OutputInterface $output = null.

This improves the developer experience by removing the need to store these objects as properties solely so they can be accessed from handleSignal().

Problem

PropertyInfoDescriber already supports serializer-group filtering — its array $serializerGroups = ['*'] constructor argument is forwarded to SerializerExtractor::getProperties($class, ['serializer_groups' => ...]).

But that filter is only settable when constructing the describer, and there is no way to pass groups per call: Factory::buildProperties() / buildParameters() accept no context, and ObjectSubject carries none. So a consumer cannot ask for "the schema of class X, limited to the write group" without hand-rolling a Factory with a bespoke PropertyInfoDescriber.

Motivation

Structured output and agent/tool write-back over domain objects want to expose only an editable subset of a class (a #[Groups(['write'])] view) rather than every property. This is the API-Platform pattern (JSON Schema derived from serializer groups). The machinery is present but unreachable.

Solution

Thread an optional $context from Factory down to the describers:

• Factory::buildProperties(string $className, array $context = []) and buildParameters(string $className, string $methodName, array $context = [])
• ObjectSubject carries it and exposes getContext()
• PropertyInfoDescriber::describeObject() prefers a per-call serializer_groups context over the groups it was constructed with
• SerializerDescriber propagates the context into the discriminator anyOf sub-schemas, so nested schemas stay group-scoped

$factory->buildProperties(GroupedDto::class, ['serializer_groups' => ['write']]);
// => only the properties in the "write" group

The serializer_groups context key is deliberately the Serializer-native one already used by PropertyInfoDescriber / SerializerExtractor, so nothing new is invented.

Alternative considered

A dedicated GroupsDescriber post-filtering emitted PropertySubjects against ClassMetadataFactory. Rejected as redundant: PropertyInfoDescriber + SerializerExtractor already filter — threading the option reuses that path and avoids loading class metadata twice.

BC

Fully backward compatible. The new arguments default to [] / ['*']; existing callers and emitted schemas are unchanged (covered by a regression test).

Tests

FactoryTest gains three cases against a new GroupedDto fixture: no context yields all properties (regression), a single group and multiple groups yield only the grouped properties, with required / additionalProperties recomputed accordingly.

Full src/platform suite is green (744 tests). PHPStan reports one pre-existing TypeInfoDescriber generics error that is present on unmodified main and unrelated to this change.

After upgrading to v3.2.2, i've noticed that declaration order of stimulus controllers in HTML matters. In my project I'm using symfony/ux-autocomplete and I have a custom controller to override tom-select options rendering. All my controllers are fetch in eager mode.

Here is an example :

<select id="new_link_sap_order_item" class="form-control" required
        {{ stimulus_controller({
            'symfony/ux-autocomplete/autocomplete':{
                url: path('colporteur_find_sap_order_lines')
            },
            'colporteur--sap-order-item-select':{},
        }) }}>
</select>

Not declaring colporteur--sap-order-item-select before symfony/ux-autocomplete/autocomplete in the HTML, leads to custom controller connecting but never intercepting the autocomplete:pre-connect event dispatched by ux-autocomplete controller.

Obviously, i've fix this by putting my custom controller in first position :

<select id="new_link_sap_order_item" class="form-control" required
        {{ stimulus_controller({
            'colporteur--sap-order-item-select':{},
            'symfony/ux-autocomplete/autocomplete':{
                url: path('colporteur_find_sap_order_lines')
            }
        }) }}>
</select>

But I do not really like things that depends on declaration order to work. Is this a wanted behaviour ? Maybe I'm opening issue in the wrong repo and should open it on symfony/ux one ?

Could some one help me how to connect to postgres database with SSL from Cachet

Bumps laravel/tinker from 2.11.1 to 3.0.2.

Note Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

The Reference Documentation (https://symfony.com/doc/current/reference/index.html) does not contain a Service Configuration Reference. The options are only described scattered across the article "Service Container" and its sub-articles.

Implement password support for PDFs.

• https://github.com/spatie/laravel-pdf/pull/344/changes#diff-357544f9b384a889d5546957c1142a75ca0a2eed23a3cd80839d88516e5944fd
• https://github.com/tecnickcom/tc-lib-pdf-encrypt

Need to add the ability to link the Schedule to Component and sent message to Subscriber in line with the Subscriber settings.

Hello,

I’m trying to install symfony/ux-chartjs. Just before that, I upgraded my project to Symfony 7.4.*. The Symfony Flex bundle is in version v2.10.0, and ux-chartjs is in v2.31.0.

During the Composer installation, I get the following error:

Symfony operations: 1 recipe (10c8450d5f6cd321a351399032a77ff4)
  - Configuring symfony/ux-chartjs (>=v2.31.0): From auto-generated recipe

In PackageJsonSynchronizer.php line 107:
                                                      
  Trying to access array offset on value of type int  

To quickly move forward, I temporarily modified PackageJsonSynchronizer.php at line 107 to avoid the error.

It looks like the issue might be related to an unexpected value in the package.json handling within the ux-chartjs bundle.

// before
if ('@' !== $name[0] || !str_starts_with($version, 'file:'.$this->vendorDir.'/') || !str_contains($version, '/assets')) {
    continue;
}

// after
if ((is_array($name) && '@' !== $name[0]) || !str_starts_with($version, 'file:'.$this->vendorDir.'/') || !str_contains($version, '/assets')) {
    continue;
}

Please let me know if you need more details or a reproducible example.

the app presents two choices:

• Browse application
• Browse backend

if you pick the first one there is no place where you can login, if you pick the second one you have a login page but if you login as regular user you face an AccessDeniedHttpException exception

maybe a working demo for new user would be nicer, it's already a demo that shows very limited symfony capabilities

Summary

• Implements hybrid event sourcing using Verbs by Thunk
• Eloquent remains the source of truth for reads (Filament, API, status page)
• Verbs captures all state changes for audit trails and replay capability
• Includes migration to initialize events for existing data

Changes

New Dependencies

• hirethunk/verbs - Event sourcing package

New State Classes (4)

Track current state of each resource:

• ComponentState - status history, incident/schedule associations
• ComponentGroupState - component memberships
• IncidentState - status history, affected components, updates
• ScheduleState - affected components, updates

New Event Classes (20)

Capture all state changes:

• Components: Created, Updated, Deleted, StatusChanged
• ComponentGroups: Created, Updated, Deleted
• Incidents: Created, Updated, Deleted, UpdateRecorded, ComponentAttached/Detached
• Schedules: Created, Updated, Deleted, Completed, UpdateRecorded, ComponentAttached/Detached

Modified Action Classes

All create/update/delete actions now fire Verbs events. Events handle:

1. State updates via apply()
2. Eloquent persistence via handle()
3. Webhook dispatch via Verbs::unlessReplaying()

Modified Filament Pages

All create/edit pages route through action classes to ensure Verbs captures changes:

• Component, ComponentGroup, Incident, Schedule pages
• Components widget status toggle

Migration

2026_01_12_000000_initialize_verbs_events.php creates initial events for existing data:

• Runs automatically on php artisan migrate
• Skips if events already exist (idempotent)
• Supports rollback via down() method

Test plan

• All 356 existing tests pass
• Verify events are created when using API endpoints
• Verify events are created when using Filament dashboard
• Verify webhook events still fire correctly
• Test migration on database with existing data

🤖 Generated with Claude Code

This commit adds support for doctrine/dbal ^4 and doctrine/persistence ^4.

Changes:

• Updated composer.json to allow doctrine/dbal ^4 and doctrine/persistence ^4
• Added required return type annotations : void to methods implementing interfaces from doctrine/persistence 4:
  • MutableAclProvider::propertyChanged() (implements PropertyChangedListener interface)
  • Acl::addPropertyChangedListener() (implements NotifyPropertyChanged interface)
• Fixed foreign key constraints in Schema.php to use table names instead of Table objects (DBAL 4 requirement)

Note: The return type annotations are now required (not optional) because the interfaces in doctrine/persistence 4 have these return types defined. Without them, PHP will throw a fatal error about incompatible method signatures.

Summary

Closes discussion #19515.

Adds an opt-in strict hierarchical breadcrumbs mode, configurable per-panel via Panel::breadcrumbs():

$panel->breadcrumbs(strictHierarchical: true);

By default, breadcrumbs for a page are built from its resource and parent record relationships (e.g. an EditRecord page's breadcrumbs come from its resource's list/view pages, plus any parent resources for nested resources). When strict hierarchical mode is enabled, breadcrumbs are instead (additionally) built by walking the page's full navigational hierarchy — cluster ancestry, navigation group, and navigation parent item — and combining that chain with the existing resource/parent-record breadcrumbs.

Changes

• Filament\Panel\Concerns\HasBreadcrumbs: extended breadcrumbs() with a second bool|Closure $strictHierarchical = false parameter, and added hasStrictHierarchicalBreadcrumbs() alongside the existing hasBreadcrumbs().
• Filament\Pages\Page: added $breadcrumb property, getBreadcrumb(), and getHierarchicalBreadcrumbs(), which recursively resolves cluster, navigation group, and navigation parent item breadcrumbs for a page. getBreadcrumbs() now checks Filament::getCurrentOrDefaultPanel()->hasStrictHierarchicalBreadcrumbs() and prepends the hierarchical chain when enabled.
• Filament\Resources\Pages\Page: getResourceBreadcrumbs() now checks strict mode first and, when enabled, prepends static::getHierarchicalBreadcrumbs() ahead of the existing resource/parent-record breadcrumbs; falls back to the previous cluster-only behavior otherwise.

Behavior

• Strict mode disabled (default): unchanged — breadcrumbs resolve exactly as before, via cluster + resource/parent-record relationships.
• Strict mode enabled: breadcrumbs are [...hierarchical chain, ...resource/parent-record breadcrumbs, page's own breadcrumb]. The hierarchical chain and resource/record breadcrumbs are combined, not one replacing the other.

When configuring both Albert and Generic bridges, the base_url convention is inconsistent, which is confusing, especially when using both platforms side by side (e.g. Albert + a vLLM instance via Generic).

Albert requires the API version in base_url and validates it:

ai:
    platform:
        albert:
            base_url: 'https://albert.example.com/v1'  # /v1 required here

Internally calls /chat/completions (no version in path).

Generic expects the version in the path (default /v1/chat/completions):

ai:
    platform:
        generic:
            default:
                base_url: 'https://vllm.example.com'  # no /v1 here

Internally calls /v1/chat/completions.

Both produce the same final URL, but the configuration expectation is opposite. There is no error when Generic's base_url accidentally includes /v1, it silently produces /v1/v1/chat/completions.

Expected behavior

Both bridges should follow the same convention: either the version always belongs in base_url, or always in the path.

References

• Albert/Factory.php: validates /v\d+ at end of base_url, passes completionsPath: '/chat/completions'
• Generic/Factory.php: defaults to completionsPath: '/v1/chat/completions'

Symfony version(s) affected

8.1.1

Description

When the Request sent through the client does not specify support for compressed response, the client transparently adds an Accept-encoding: gzip header, and if the received response's body is indeed gzip-encoded, it does decode it transparently before passing it back to the caller.

However, when doing that, it does not strip the Content-Encoding header of the Response, with the result that the caller has to do some accurate (read: brittle) testing in order to decide if it should trust that Content-Encoding header and do decompression on its own, or not.

This makes it harder than necessary to build middlewares that use the Symfony http Client... (also, for comparison, Guzzle also does automatic decompression of response bodies, and it does strip the Content-Encoding header when doing so)

How to reproduce

I tested this using the Psr18Client wrapper to send http requests via the Symfony Http Client.

Possible Solution

No response

Additional Context

No response

Summary

• flare login now defaults to a browser PKCE flow against Passport. --device runs the device-code flow for headless terminals (and is the auto-fallback when stdin is non-interactive). --token preserves the legacy paste-a-PAT UX.
• Stored OAuth records refresh transparently before each API call via CredentialStore::getAccessToken(). spatie/[email protected]'s new retryOn hook acts as a 401 safety net via CredentialStore::forceRefresh().
• Per-host credential storage now accepts both legacy strings and OAuth record objects. Existing PAT users keep working until they choose to flare login again — no migration needed.
• flare logout --all wipes every host in one go.

What landed

• app/Services/OAuth/: TokenRecord (value object), PkceCodes (RFC 7636 verifier/challenge/state), OAuthEndpoints, OAuthHttpClient, TokenRefresher, LocalCallbackServer (stream_socket_server on 127.0.0.1:0 with inline success/error HTML — PHAR-safe), PkceLoginFlow, DeviceLoginFlow, DeviceAuthorization + DevicePollResult DTOs, OAuthException.
• config/flare.php: client ID + scopes config. Default client UUID is the dev seed value — see launch blocker below.
• CredentialStore: extended with getRecord() / setRecord() / getAccessToken() / forceRefresh() / flushAll(), with flock-guarded read-modify-write around refresh.
• AppServiceProvider: bound the new OAuth services and wired ->auth() to getAccessToken() and ->retryOn() to forceRefresh().
• LoginCommand refactored: dispatches by mode flag, falls back to device flow on non-interactive stdin, warns when --token replaces an existing OAuth session.
• 93 Pest tests (+46 new), all passing. PHPStan clean. Pint clean.

:warning: Launch blocker — production OAuth client UUID

config/flare.php ships the dev Flare CLI Passport client UUID (9d000000-0000-4000-8000-000000000001) as the default for FLARE_OAUTH_CLIENT_ID. The production client UUID must be substituted there before tagging a release. The CLI honors the env var at runtime so staging/local can keep overriding via FLARE_OAUTH_CLIENT_ID=… — but the baked-in default is what end users will hit.

Grep for 9d000000 in config/flare.php to spot it. Worth considering a CI grep that fails on a release branch if the placeholder is still present.

Server-side dependencies

• Passport Flare CLI client must be seeded with loopback redirect URIs (http://127.0.0.1/callback, http://[::1]/callback, flare://oauth/callback) — landed on passport-oauth branch.
• ApproveAuthorizationController and DenyAuthorizationController must convert Inertia redirects to Inertia::location() (otherwise the XHR can't cross HTTPS → HTTP loopback). Landed on passport-oauth branch.

Test plan

• OAuth storage shape (mixed with legacy strings) — CredentialStoreTest
• PKCE flow happy path (state CSRF, code exchange, scope/URL params) — PkceLoginFlowTest
• Local callback server: real socket, request parsing, success/error HTML — LocalCallbackServerTest
• Device flow: pending → success, slow_down increases interval, fatal aborts, expiry throws — DeviceLoginFlowTest
• Token exchange + refresh + refresh-token rotation — OAuthHttpClientTest
• Proactive refresh threshold — TokenRefresherTest
• CredentialStore::getAccessToken() refresh + write-back + no-op skip — CredentialStoreTest
• retryOn(401 → forceRefresh) wiring — OpenApiRegistrationTest
• LoginCommand: --token, PKCE, non-TTY fallback to device, error paths — LoginCommandTest
• LogoutCommand: per-host + --all — LogoutCommandTest
• Manual: PKCE end-to-end against passport-oauth.test
• Manual: proactive refresh (forced expires_at) and retryOn 401 (mangled access_token) against real Passport
• Manual: --token with both modern (Passport PAT) and legacy SHA-256 tokens
• Manual: device flow end-to-end (verified at the unit/integration boundary; physical browser approval not yet exercised)
• Manual: non-TTY auto-fallback to device flow end-to-end (same reason)

I'm not sure if it should be in the doc in the v3.x installation section or in the composer setup part.

But I think it's worth to mention that the storage directory must be writable by the users that is used by the web server (www-data or similar).

Let me know what you think about so I can transform this in pull request.

I don't know if it is the proper way to fix a recipe, but this change should fix the issue of running mercure behind Traefik.

Context

src/store/src/Command/ holds four commands. Three of them have a unit test in src/store/tests/Command/; IndexCommand has none.

grep -rl IndexCommand src/store returns only the class itself. (PR #2305 adds ai:store:clear with a ClearStoreCommandTest, which leaves IndexCommand as the sole gap.)

To be clear about the scope: this is not a hole in the indexing logic. The pipeline underneath the command is well covered — Indexer/SourceIndexerTest, Indexer/ConfiguredSourceIndexerTest, Indexer/DocumentIndexerTest, Document/VectorizerTest, Document/Loader/RssFeedLoaderTest, Document/Transformer/TextSplitTransformerTest, and so on. What is untested is the thin CLI wrapper around it, which is exactly the layer the three sibling tests cover for their commands.

What to cover

src/store/src/Command/IndexCommand.php. Its execute() has real branching:

1. --source normalisation — the most valuable case. execute() does:

   $sources = $input->getOption('source'); // VALUE_OPTIONAL | VALUE_IS_ARRAY
   $source = match (true) {
       [] === $sources => null,
       1 === \count($sources) => $sources[0],   // collapses to a scalar
       default => $sources,                      // stays an array
   };
   

   Three distinct outcomes — no --source → null, one --source → string, several → array — all passed to IndexerInterface::index($source). The single-value collapse is the kind of thing that silently changes shape; assert what index() actually receives.
2. Unknown indexer → RuntimeException, The "%s" indexer does not exist.
3. Indexer of the wrong type — anything that is not a SourceIndexer or a ConfiguredSourceIndexer → RuntimeException (... is not a SourceIndexer ...).
4. index() throws → wrapped in RuntimeException with the original as previous.
5. Success path → Documents indexed successfully using "%s" indexer.
6. configure() — name, description, indexer argument required, source option is an array. The siblings all have a testCommandIsConfigured().
7. Optionally complete(), which suggests the indexer names from the ServiceLocator.

How

Follow src/store/tests/Command/SetupStoreCommandTest.php — plain TestCase, the command built with a Symfony\Component\DependencyInjection\ServiceLocator of stubbed indexers, driven through Symfony\Component\Console\Tester\CommandTester. Note the exception class is the component's own Symfony\AI\Store\Exception\RuntimeException, not the native one.

New file: src/store/tests/Command/IndexCommandTest.php

cd src/store && vendor/bin/phpunit tests/Command/
cd src/store && vendor/bin/phpstan analyse
vendor/bin/php-cs-fixer fix src/store/   # from the repo root

Tests only — no CHANGELOG.md entry (see AGENTS.md: changelogs list features and deprecations, not test coverage).

Background

Surfaced while reviewing #2300, which adds end-to-end tests to the demo that lean on ai:store:index to build the blog store. Not a blocker for that PR, and independent of it.

I tried the example config from the docs to a Laravel/Inertia/Vue app, and it don't work.

If use the code (HandleInertiaRequests.php): 'messages' => flash()->render([], 'array'),

Error: Flasher\Prime\Flasher::render(): Argument #1 ($presenter) must be of type string, array given, called in D:\Laragon6\www\mobi-care\app\Http\Middleware\HandleInertiaRequests.php on line 36

And changing it to: 'messages' => flash()->render('array'), it loads the page, but, I only see the notifications if i press F5, with its not the desired state.

Companion PR to symfony/ux#3466. Adds the Toolkit/Shadcn docs page for the native-select recipe.

Kept as draft until symfony/ux#3466 (which introduces the upstream recipe) is merged.

Split out from the original #54 so each component can be reviewed/merged independently alongside its upstream recipe.

Hi there,

I'm struggeling to understand how we should set the values of

MERCURE_JWT_SECRET MERCURE_PUBLISHER_JWT_KEY MERCURE_SUBSCRIBER_JWT_KEY

In the docs for the bundle, MERCURE_JWT_SECRET is used in the examples. In the docs and templates for frankenphp and mercure.rocks, the template uses MERCURE_PUBLISHER_JWT_KEY/..SUBSCRIBER..

Am I understanding correctly that these are two different ways (sync/async) to handle secrets? What is recommended? What are the requirements for the keys/secrets to use? Am I correct that they do not go together?

It seems I cannot find the docs required. Either, they are well hidden or do not exist - which is a pitty because it seems to set the entry barrier higher for this to use.

If you can provide an explanation how "it should be used", I'm more than happy to feed that back into the corresponding docs via MR for future users.

Summary

Documents the new Route::static() API for Laravel 13.x.

The new section in routing.md covers:

• basic ->static() usage with shared and browser TTL overrides,
• default config/cache.php options,
• response and middleware behavior,
• when not to use static routes,
• Inertia behavior,
• Livewire compatibility,
• the CDN / Cloudflare Cache Rule caveat.

Related PRs

• Laravel 13.x framework PR: https://github.com/laravel/framework/pull/60286
• Laravel 12.x framework backport PR: https://github.com/laravel/framework/pull/60287
• Laravel 12.x docs backport PR: https://github.com/laravel/docs/pull/11215

Compatibility Verification

The framework PR includes app-level matrix verification across PHP 8.4 / 8.5, Inertia 2 / 3, and Livewire 3 / 4 for Laravel 13.x. Inertia 1 is not Laravel 13 compatible.

Testing

Documentation-only change.

I am trying to deploy docker image on AWS ECS Fargate containers. I am getting this error in logs. symlink(): No such file or directory

I think I am having following issue: but I don't know how to solve it when running in container. https://www.nicesnippets.com/blog/symlink-no-such-file-or-directory-laravel-ubuntu-solved

This will allow the use of IsCsrfTokenValid Attribute but we lose the redirection when the csrk token is not valid. What do you think?

Hi there 👋

I believe this is a fairly common issue, and I’m hoping to find some guidance here, as I couldn’t find anything relevant in the documentation.

In my application, I'm using turbo_stream_listen to establish a connection to a Mercure hub and update the page in real-time when specific events occur. Everything works great so far. The whole stack runs inside Docker Compose using FrankenPHP (and a custom Caddyfile to enable Mercure).

However, I’m running into a problem during deployment:

docker compose up -d --wait --remove-orphans

When Docker restarts the containers, the client’s connection to the Mercure server is lost.

In a normal user-driven scenario, this wouldn’t be a big issue — as soon as the user interacts with the app again, a page load or navigation would re-establish the connection seamlessly.

But in my case, the app runs unattended on a tablet in kiosk mode. So after each deployment, the page stays open but no longer receives updates, and I’m forced to ask the client to manually refresh the page, which is not ideal.

I thought about sending a Turbo Stream to trigger a client-side refresh, but of course that doesn’t work — by the time the message is sent, the Mercure connection is already lost.

Is there a recommended way to detect a broken Mercure connection and trigger a page reload or reconnection automatically? Any idea would be greatly appreciated!

Thanks in advance 🙏

Hello, I try to create a new symfony project with enabled "--webapp" option, but get an error while installing.

This is the command: symfony new symfony-64-template --version=lts --webapp

The error is in the cache:clear part of the installation:

Symfony operations: 20 recipes (7a429e6d184854502a7c6c7bf6163efd)
  - Configuring symfony/webapp-pack (>=1.0): From github.com/symfony/recipes:main
  - Configuring doctrine/doctrine-bundle (>=2.10): From github.com/symfony/recipes:main
  -  IGNORING  doctrine/doctrine-bundle (>=2.10): From github.com/symfony/recipes:main
  - Configuring doctrine/doctrine-migrations-bundle (>=3.1): From github.com/symfony/recipes:main
  - Configuring phpunit/phpunit (>=9.6): From github.com/symfony/recipes:main
  - Configuring symfony/debug-bundle (>=5.3): From github.com/symfony/recipes:main
  - Configuring symfony/messenger (>=6.0): From github.com/symfony/recipes:main
  - Configuring symfony/phpunit-bridge (>=6.3): From github.com/symfony/recipes:main
  - Configuring symfony/twig-bundle (>=6.4): From github.com/symfony/recipes:main
  - Configuring symfony/web-profiler-bundle (>=6.1): From github.com/symfony/recipes:main
  - Configuring symfony/validator (>=5.3): From github.com/symfony/recipes:main
  - Configuring symfony/stimulus-bundle (>=2.13): From github.com/symfony/recipes:main
  - Configuring symfony/ux-turbo (>=v2.21.0): From auto-generated recipe
  - Configuring twig/extra-bundle (>=v3.13.0): From auto-generated recipe
  - Configuring symfony/translation (>=6.3): From github.com/symfony/recipes:main
  - Configuring symfony/security-bundle (>=6.4): From github.com/symfony/recipes:main
  - Configuring symfony/notifier (>=5.0): From github.com/symfony/recipes:main
  - Configuring symfony/monolog-bundle (>=3.7): From github.com/symfony/recipes:main
  - Configuring symfony/maker-bundle (>=1.0): From github.com/symfony/recipes:main
  - Configuring symfony/mailer (>=4.3): From github.com/symfony/recipes:main
  - Configuring symfony/asset-mapper (>=6.4): From github.com/symfony/recipes:main
Executing script importmap:require [OK]
Executing script importmap:require [OK]
Executing script importmap:require [OK]
Unpacking Symfony packs
  - Unpacked symfony/webapp-pack
  - Unpacked symfony/orm-pack
  - Unpacked symfony/serializer-pack
  - Unpacked symfony/twig-pack
  - Unpacked symfony/debug-pack
  - Unpacked symfony/profiler-pack
  - Unpacked symfony/test-pack
Loading composer repositories with package information
Pattern "php" listed for update matches platform packages, but these cannot be updated by Composer.
Updating dependencies
Nothing to modify in lock file
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 0 installs, 0 updates, 7 removals
  - Removing symfony/webapp-pack (v1.3.0)
  - Removing symfony/twig-pack (v1.0.1)
  - Removing symfony/test-pack (v1.1.0)
  - Removing symfony/serializer-pack (v1.3.0)
  - Removing symfony/profiler-pack (v1.0.6)
  - Removing symfony/orm-pack (v2.4.1)
  - Removing symfony/debug-pack (v1.0.10)
Generating autoload files
112 packages you are using are looking for funding.
Use the `composer fund` command to find out more!

Symfony operations: 1 recipe (46e521589617cc6dbb7e69e8bab9ecc0)
  - Unconfiguring symfony/webapp-pack (>=1.0): From github.com/symfony/recipes:main
Executing script cache:clear [KO]
 [KO]
Script cache:clear returned with error code 255
!!
!!   // Clearing the cache for the dev environment with debug true
!!
!!  16:02:31 CRITICAL  [php] Uncaught Error: Too few arguments to function PHPStan\PhpDocParser\Parser\ConstExprParser::__construct(), 0 passed in /home/michael/Entwicklung/symfony/symfony-64-template/vendor/symfony/property-info/Extractor/PhpStanExtractor.php on line 71 and exactly 1 expected ["exception" => ArgumentCountError { …}]
!!
!!  In ConstExprParser.php line 18:
!!
!!    Too few arguments to function PHPStan\PhpDocParser\Parser\ConstExprParser::
!!    __construct(), 0 passed in /home/michael/Entwicklung/symfony/symfony-64-tem
!!    plate/vendor/symfony/property-info/Extractor/PhpStanExtractor.php on line 7
!!    1 and exactly 1 expected
!!
!!
!!  cache:clear [--no-warmup] [--no-optional-warmers]
!!
!!
Script @auto-scripts was called via post-update-cmd


  unable to run /usr/bin/composer require webapp --no-interaction

Without the --webapp the installation works, a seperate "composer require webapp" in the folder gives me the same error

My system is Arch Linux with all Updates, Composer version 2.8.2 2024-10-29 16:12:11 PHP version 8.3.13 (/usr/bin/php) Symfony CLI version 5.10.4

Can anybody points me in the right direction.

Thanks in advance.

Michael

After adding one or more tags to a component, I'm unable to delete all of the tags from the component. I can add, delete, and change tags. However, I can't delete the last tag from the component. I've tried from the Cachet web interface as well as via the Python cachet-client package. I'm running Cachet 2.4.1 on Ubuntu 24.04.1 LTS (x86).

Moved from symfony-cli/symfony-cli#331

Symfony 5.4 LTS in theory support PHP7.4 but symfony-cli new --webapp --version=lts or just composer require webapp --no-interaction unable to finish if used on PHP7.4:

 [KO]
Script cache:clear returned with error code 1
!!
!!  In CheckExceptionOnInvalidReferenceBehaviorPass.php line 86:
!!
!!    The service "doctrine.orm.default_annotation_metadata_driver" has a depende
!!    ncy on a non-existent service "doctrine.orm.metadata.annotation_reader".
!!
!!
!!
Script @auto-scripts was called via post-update-cmd

If I'll use php81 composer require webapp --no-interaction it will install but still not working on PHP7.4

Good morning,

I am currently evaluating the Cachet 2.4 solution to display the status of an information system. I encounter a bug in the dashboard display: When the dashboard has not been accessed for several hours, there is systematically a delay of 2 minutes before it can be displayed. I don't see any errors in the docker logs, I don't understand why this is happening.

The login form is displayed quickly if necessary and it is only after validation of the login that the "blocking" is felt. Once these few minutes have passed, I regain full access to the dashboard.

This is all the more bizarre as the public HMI continues to work perfectly during this period of time.

Here is my configuration:

Docker compose -postgres:12 -redis:latest -postfix (custom container) -stamp:2.4 (custom container) environment: - DB_DRIVER=pgsql - DB_HOST=<postgres_container> - DB_PORT=5432 - DB_DATABASE=<DATABASE> - DB_USERNAME=<DB_USER> - DB_PASSWORD=<DB_PASSWORD> - DB_PREFIX=chq_ - APP_KEY=base64:<MyKey> - APP_LOG=errorlog - APP_ENV=${APP_ENV:-production} - APP_DEBUG=false - DEBUG=false - SESSION_DIVER=redis - CACHE_DRIVER=redis - REDIS_HOST=<redis_container> - MAIL_DRIVER=smtp - MAIL_HOST=<postfix_container> - MAIL_PORT=25 - MAIL_ENCRYPTION=false - PHP_MAX_CHILDREN=20 depends_on: - <postgres_container> - <redis_container> - <postfix_container>

Thanks for your help

Summary

Concrete design proposal for #198, which reports that generated ManyToOne setters accept null even when the relation is non-nullable (setCategory(?Category $category) for a nullable: false association).

The discussion stalled on a real constraint: the setter must stay nullable for bidirectional relations, because the collection remove*() generated on the inverse side sets the owning side back to null ($item->setOwner(null), orphanRemoval) — making every ManyToOne setter strict would break that generated code.

This PR tightens only the provably-safe subset: a non-nullable, unidirectional ManyToOne, which has no such remove*() null path:

public function setCategory(Category $category): static  // was: ?Category

Bidirectional and explicitly-nullable relations are unchanged. This mirrors what already happens for non-nullable OneToOne setters ($relation->isNullable()), just extended to the ManyToOne case that is provably safe.

Scope / open questions

• Deliberately setter-only (the original report). The backing property stays ?Category $category = null — consistent with the current OneToOne behavior, and it avoids uninitialized-typed-property pitfalls with Forms.
• Also making the property non-nullable (raised again recently re: phpstan-doctrine doctrine.associationType) is a bigger discussion — it reopens @javiereguiluz's Forms concern about uninitialized properties — so it's left out here. Happy to follow up if you'd like to go there.

No existing fixtures change (no current test case is non-nullable + unidirectional); a new many_to_one_not_nullable_no_inverse case + fixture covers it.

Hi,

i have fully working setup, the only part is missing to start panther in --no-headless mode.

symfony app is inside a docker container, my dev environment is in windows wsl2. i can start chrome from my terminal, which opens up a chrome browser. I cannot start chrome inside my container. I can start playwright with ui from a docker container as well. it looks like my dev env is correct.

i am not totally sure my issue, or question is related to panther, so if you think so, just close it down please.

there are already similar issues like: https://github.com/symfony/panther/issues/505

Could somebody write up, or give an example how to run it?

I did setup DISPLAY env variable to: :0 with and without host.docker.internal I did attached volume /tmp/.X11-unix:/tmp/.X11-unix I did run xhost +local:docker I have 1000:1000 uid:gid in my docker container, and wsl2

I asume chrome still cannot reach display:0 from container I did not tried vnc solution I did made work selenium client but did not liked it

So any help would be greate how to run chrome from inside a container, which can connect to desplay on my wsl2.

thanks!

The PR is a proposal to allow deserialization of readonly properties.

Motivation

I'm currently handling a project that has integrations with external services. Using the library allows to create objects from the data and encapsulate specific login into it, which is very valuable.

However, the limitation of not being able to deserialize into readonly properties, especially in a context that heavily relies on #[PropertyForMorph] for polymorphic types (like Person in the case of this PR), poses some challenges that readonly properties would cover nicely.

Therefore, I decided to open this PR as I believe there is use cases in which leveraging readonly properties.

This carves out slice 1 of @chr-hertel's endpoint refactor (#2029) as a small, self-contained, backward-compatible PR — the piece that PR explicitly marks as landable on its own:

1. Endpoint as a first-class concept on Model

• New Endpoint value object (contract identifier + defaults).
• Model gains getEndpoints(), getDefaultEndpoint(), getEndpoint(string), supportsEndpoint(string).
• Catalogs declare endpoints via the new AbstractModelCatalog::endpointsForModel() hook.
• Minimum viable PR: just the new types + the hook, no consumer changes. Backward-compatible; later PRs migrate consumers.

The intent is to let the Endpoint shape land and be iterated on now (it's also what batch routing — #1802 — and multi-contract models like OpenAI chat-completions vs. responses would hang off of), independently of the larger dispatch rework.

What's here

Endpoint — a value object identifying one contract a model speaks, plus optional contract-specific defaults:

namespace Symfony\AI\Platform;

final class Endpoint
{
    public function __construct(private readonly string $contract, private readonly array $defaults = []) { /* … */ }
    public function getContract(): string;
    public function getDefaults(): array;
}

Model — a new optional, last constructor parameter array $endpoints = [], and five accessors:

$model->getEndpoints();         // Endpoint[]
$model->hasEndpoints();         // bool
$model->getDefaultEndpoint();   // ?Endpoint — the first declared
$model->getEndpoint('openai.responses');     // Endpoint, throws if unsupported
$model->supportsEndpoint('openai.responses'); // bool

AbstractModelCatalog — a new endpointsForModel(array $modelConfig): array hook (defaults to []), called in getModel() and forwarded to the Model constructor, so a catalog can declare a model's endpoints by overriding one method.

Backward compatibility

Fully additive:

• the new Model constructor parameter is optional and last;
• the catalog hook defaults to no endpoints, so existing catalogs produce identical models;
• no consumer or bridge is changed — models without endpoints behave exactly as today.

(Bridge Model subclasses with custom constructors — Anthropic\Claude, the OpenAI/Scaleway Embeddings — keep working unchanged; they'll opt into forwarding $endpoints if and when a catalog starts declaring endpoints for them, in a follow-up.)

Tests

EndpointTest (construction, defaults, empty-contract guard), ModelTest (all five accessors incl. default-is-first and the unsupported-contract exception), and AbstractModelCatalogTest (default = no endpoints; the hook populates a model's endpoints). Full Platform suite green; PHPStan and CS-Fixer clean.

The Endpoint API here matches #2029 verbatim so it drops straight into that branch's later slices.

Originally, the signal handling documentation used SignalableCommandInterface in the example. This was later changed in #20932 to an example using #[AsEventListener(ConsoleSignalEvent::class)].

However, these two approaches are not equivalent.

SignalableCommandInterface registers signal handlers only for the command that implements the interface, whereas an event listener for ConsoleSignalEvent is registered globally and is triggered for every command.

For example:

#[AsCommand(name: 'app:my-command')]
class MyCommand
{
    // ...

    #[AsEventListener(ConsoleSignalEvent::class)]
    public function handleSignal(ConsoleSignalEvent $event): void
    {
        if (\in_array($event->getHandlingSignal(), [\SIGINT, \SIGTERM], true)) {
            // ...
        }

        // ...
    }
}

Although the listener is defined inside MyCommand, it is not scoped to that command. It will be invoked whenever any console command receives one of the configured signals.

As part of this change, all mentions of SignalableCommandInterface were also removed from the documentation, making it appear as though event listeners are the recommended replacement, even though they serve a different purpose.

This PR tries to create the distinction between per-command signal handlers and global signal handlers.

The line can easily be misunderstood in that it would only allow each user access to their profile (while in fact it allows every user access to every profile).

Problem

ProxyCacheWarmer::warmUp() collects proxy files via scandir() without filtering by extension. doctrine/orm's ProxyFactory uses an atomic write pattern — it writes to a temp file (Proxy.php.{random_hex}) then renames it to the final .php path:

$tmpFileName = $fileName . '.' . bin2hex(random_bytes(12));
file_put_contents($tmpFileName, $proxyCode);
rename($tmpFileName, $fileName);

If scandir() runs during this window (race with concurrent PHP workers), or if rename() fails silently and the temp file persists, the temp path ends up in the array returned by warmUp().

Since Symfony 7.4, CacheWarmerAggregate strictly validates that every returned path ends in .php, which causes an exception:

"Symfony\Bridge\Doctrine\CacheWarmer\ProxyCacheWarmer::warmUp()" should return a list of files or classes
but "/var/cache/prod/doctrine/orm/Proxies/__CG__SomeEntity.php.2eb37f8174836c6595d337b3" is none of them.

The error is intermittent because in normal conditions the rename() completes before scandir() is called, but fails under concurrent deploys or when rename() silently errors.

Fix

Add a str_ends_with($file, '.php') guard in the scandir() loop:

  foreach (scandir($proxyCacheDir) as $file) {
-     if (!is_dir($file = $proxyCacheDir.'/'.$file)) {
+     if (!is_dir($file = $proxyCacheDir.'/'.$file) && str_ends_with($file, '.php')) {
          $files[] = $file;
      }
  }

This makes the warmer robust against leftover temp files regardless of whether the race occurs or rename() succeeds.

Hey guys,

Adding AssertMapper in merge #13 broke webapp for SF 5.4

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires symfony/asset-mapper 5.4.*, found symfony/asset-mapper[v6.3.0-BETA1, ..., 6.4.x-dev, v7.0.0-BETA1, ..., 7.1.x-dev] but it does not match the constraint.

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

To reproduce the problem, install SF 5.4:

composer create-project symfony/skeleton:"^5.4" .
composer require webapp

Currently, each maker class is declared as final, which prevents extending an existing maker to adapt it to custom needs.

Here: https://symfony.com/bundles/SymfonyMakerBundle/current/index.html#creating-your-own-makers, it is explained that we can create our own makers. However, the problem is that this requires rebuilding everything from scratch every time.

My personal use case is to extend the MakeEntity class (https://github.com/symfony/maker-bundle/blob/1.x/src/Maker/MakeEntity.php) in order to change the default directory. At the moment, when running make:entity, it always looks for or creates entities in the src/Entity directory, whereas in some projects entities are located in different folders, for example src/FolderA/TestEntity.php.

Related issues: https://github.com/symfony/maker-bundle/issues/51 https://github.com/symfony/symfony/issues/28790 https://github.com/symfony/maker-bundle/issues/247

Essentially, this, I have gotten this after multiple reinstalls:

Here's my docker-compose file:

version: "3"
 
services:
  postgres:
    image: postgres:12-alpine
    volumes:
      - /var/lib/postgresql/data
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=833d4aa3d852c583
    restart: always
  cachet:
    image: cachethq/docker:latest
    ports:
      - 8787:8000
    links:
      - postgres:postgres
    environment:
      - DB_DRIVER=pgsql
      - DB_HOST=postgres
      - DB_PORT=5432
      - DB_DATABASE=postgres
      - DB_USERNAME=postgres
      - DB_PASSWORD=833d4aa3d852c583
      - DB_PREFIX=chq_
      - APP_KEY=base64:UWLlBazkwP3z9G7a4Qb/Xkx4Q3FNSVhv0ClqBppPggo=
      - APP_LOG=errorlog
      - APP_ENV=${APP_ENV:-production}
      - APP_DEBUG=false
      - DEBUG=false
    depends_on:
      - postgres
    restart: on-failure

Description: I am using Flasher 2.0.1 in my Laravel 11 project and would like to know how to properly use the Flasher library in JavaScript. Additionally, I want to ensure that the JavaScript configuration is consistent with the settings defined in the flasher.php configuration file.

Details: Flasher Version: 2.0.1 Laravel Version: 11 Problem: Need guidance on using the Flasher library with JavaScript in a way that mirrors the configuration set in flasher.php.

Hello,

updated all composer packages today and noticed that the config validation is throwing 210 errors now. Example:

 Config validation failed!   
    
  210 errors found in your application:  
    
  hashing.bcrypt.rounds  Value: 12  
    - hashing.bcrypt.rounds must be an integer.
    
  hashing.argon.memory  Value: 65536  
    - hashing.argon.memory must be an integer.  
    
  hashing.argon.threads  Value: 1  
    - hashing.argon.threads must be an integer.
    
  hashing.argon.time  Value: 4  
    - hashing.argon.time must be an integer.

the first example is bcrypt rounds and I haven't overwritten the rounds in my env. I also have a lot of errors where the value has to be a string, but it already is:

  mail.mailers.mailgun.transport  Value: mailgun  
    - mail.mailers.mailgun.transport must be a string.

It does not fail with version 2.6.0 and also not with 2.5.0. If you need more information just ping me in a reply please.

NotOrm Package

The goal is to make abstract code based on the package notorm to build a new orm system

✏️ Describe the bug The search button on https://spatie.be/docs/laravel-data/v4/introduction does not work anymore.

In console following error

TypeError: undefined is not an object (evaluating '$store.modals.open')

🖥️ Versions Chrome, Firefox, Safari all latest on macOS 15.7

And when you are at it, could Command + K be the shortcut for the current doc page not for some global search?

It would be valuable to implement a feature that allows recording browsing sessions in Chrome, exporting them as a JSON file, and then replaying these sessions with Panther. This feature would simplify the process of converting real user interactions into automated tests.

Motivation
A command or API to load a JSON file of recorded actions (page navigations, clicks, form inputs, etc.) and translate them into Panther commands would help developers quickly generate test cases from actual user sessions. It could reduce the manual effort required to write tests and allow for easier reproduction of issues.

Proposed Implementation

1. Recording Session in Chrome:
   Allow users to export their Chrome DevTools recorded session as a JSON file with a structure similar to this:

   [
     {
       "type": "navigate",
       "url": "http://example.com"
     },
     {
       "type": "click",
       "selector": "#login-button"
     },
     {
       "type": "fill",
       "selector": "#username",
       "value": "[email protected]"
     }
   ]
   

2. Replaying the Session in Panther:
   Add a command (e.g., panther:replay-session) or a helper class that reads the JSON file and maps each recorded action to Panther API methods. Below are some code examples demonstrating how this could work:

   Example A: Standalone Script

   <?php
   
   use Symfony\Component\Panther\Client;
   
   // Load JSON session file
   $sessionFile = __DIR__ . '/session.json';
   $actions = json_decode(file_get_contents($sessionFile), true);
   
   // Create a Panther client instance
   $client = Client::createChromeClient();
   
   // Process each action in the recorded session
   foreach ($actions as $action) {
       switch ($action['type']) {
           case 'navigate':
               // Navigate to the given URL
               $client->request('GET', $action['url']);
               break;
           case 'click':
               // Click the element identified by the selector
               $client->getCrawler()->filter($action['selector'])->click();
               break;
           case 'fill':
               // Enter text into the input field identified by the selector
               $client->getCrawler()->filter($action['selector'])->sendKeys($action['value']);
               break;
           default:
               // Optionally log unsupported action types
               echo sprintf("Unsupported action type: %s\n", $action['type']);
               break;
       }
   }
   

   Example B: Symfony Console Command

   <?php
   
   namespace App\Command;
   
   use Symfony\Component\Console\Command\Command;
   use Symfony\Component\Console\Input\InputArgument;
   use Symfony\Component\Console\Input\InputInterface;
   use Symfony\Component\Console\Output\OutputInterface;
   use Symfony\Component\Panther\Client;
   
   /**
    * Command to replay a Chrome recorded session.
    */
   class ReplaySessionCommand extends Command
   {
       protected static $defaultName = 'panther:replay-session';
   
       protected function configure()
       {
           $this
               ->setDescription('Replay a Chrome recorded session from a JSON file.')
               ->addArgument('session', InputArgument::REQUIRED, 'Path to the JSON session file');
       }
   
       protected function execute(InputInterface $input, OutputInterface $output)
       {
           $sessionPath = $input->getArgument('session');
           $actions = json_decode(file_get_contents($sessionPath), true);
   
           $client = Client::createChromeClient();
   
           foreach ($actions as $action) {
               switch ($action['type']) {
                   case 'navigate':
                       $client->request('GET', $action['url']);
                       break;
                   case 'click':
                       $client->getCrawler()->filter($action['selector'])->click();
                       break;
                   case 'fill':
                       $client->getCrawler()->filter($action['selector'])->sendKeys($action['value']);
                       break;
                   default:
                       $output->writeln(sprintf('Unsupported action type: %s', $action['type']));
                       break;
               }
           }
   
           $output->writeln('Session replayed successfully.');
   
           return Command::SUCCESS;
       }
   }
   

Benefits

• Simplifies automated test generation by converting user sessions to executable tests.
• Reduces the time spent on manually writing tests.
• Provides a reproducible method to simulate user interactions for debugging.

I am willing to contribute to this feature if there is interest from the maintainers.

PhpArrayAdapter::deleteItems() classifies each key as either stored (read-only, living in the warmed PHP file) or fallback (delegated to the fallback pool) by reading $this->keys — but it does so before calling initialize(), which is the method that actually populates $this->keys from the file.

public function deleteItems(array $keys): bool
{
    $deleted = true;
    $fallbackKeys = [];

    foreach ($keys as $key) {
        // ...
        if (isset($this->keys[$key])) {   // ← $this->keys is not initialized yet
            $deleted = false;
        } else {
            $fallbackKeys[] = $key;
        }
    }
    if (!isset($this->values)) {
        $this->initialize();              // ← too late
    }
    // ...
}

On a not-yet-initialized adapter $this->keys is empty, so every stored key is misclassified as a fallback key. deleteItem() (and every other method) calls initialize() first, so the two delete methods disagree.

Observable effect

When deleteItems() is the first call on a fresh instance and the key is stored/read-only, compared to the equivalent deleteItem():

$adapter = new PhpArrayAdapter($file, $fallbackPool); // $file has a stored key 'foo'

$adapter->deleteItem('foo');    // returns false, fallback pool untouched  (correct)
$adapter->deleteItems(['foo']); // returns TRUE, and deletes 'foo' from the fallback pool  (wrong)

So deleteItems():

• returns true for a read-only key that cannot actually be deleted (should be false), and
• forwards that key to the fallback pool, wrongly deleting an unrelated same-named entry there.

Once the adapter has been initialized by any prior operation, the bug disappears — it only bites when deleteItems() is the first call.

Fix

Hoist the existing initialize() guard above the loop, exactly as deleteItem(), hasItem(), save(), etc. already do. With the fix, deleteItem() and deleteItems() produce identical results (verified for stored keys, fallback-only keys, and mixed batches, on both cold and warm instances).

A regression test is added (the testDeleteItems* inherited from the integration suite are skipped for this read-only adapter, so this path was previously unasserted). It fails on the current code and passes with the fix.

This PR is to reduce state within the Toolbox class and simplify initialization logic.

If someone needs to support running the application on FrankenPHP and php-fpm, such as for debugging purposes, the bundle currently always sends a http request. We should add an option to prefer the built in hub if mercure_publish is available, even if mercure.url is defined.

Bumps actions/checkout from 6 to 7.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Bumps actions/cache from 3 to 6.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

When a Mercure Hub exception occurs, "Fail to send an update" is too vague to diagnose the issue. The hub logs are extremely dense, so troubleshooting them is very challenging. Additionally, throwing a RuntimeException is not ideal. It should throw a MercureException so it is easier to catch in an EventListener. Currently, I have to listen for RuntimeExceptions and fuzzy search:

str_contains($exception->getMessage(), 'Failed to send an update')

The Mercure bundle needs some work as it is very minimal atm.

This is the exact same as I did here https://github.com/laravel/framework/pull/60519

This means queue attributes 🤝 model attributes (We are same same but different)

This essentially means, traits can carry model attributes which means we can put attributes on a trait, and reuse the trait.

This only checks traits on the current class in the hierarchy same as the other PR

Nice for package maintainers, or teams using traits.

#[Connection('warehouse')]
trait UsesWarehouse
{
  // scopes etc... that may be shared
}

class Product extends Model
{
    use UsesWarehouse;
}

class StockTransfer extends Model
{
    use UsesWarehouse;
}

I'm completely fine if you close this, just thought I'd try bring the same behaviour as queues to models for the attributes 🫡

Changes In Code

Issue ticket number / Business Case

Checklist before requesting a review

• I have written PHP tests.
• I have updated the documentation in the readme where needed.
• I have checked code styles, PHPStan etc. pass.
• I have provided an issue/business case.

Hello :)

I'm trying to use the bundle with a custom tokenprovider which is working for one part. So I have my tokenprovider which collects all subscribeable and publishable topics and creates a token with it.

That's working fine for the backend.

For the Client I wanted to send a cookie with a token and had a look at the Authorization class.

I would like to use it but it's not compatible with the token provider. I mean it would use a TokenFactory but not a Provider.

public function createCookie(Request $request, $subscribe = [], $publish = [], array $additionalClaims = [], ?string $hub = null): Cookie

I can generate a new cookie but I need all the topics again and it's not using my token provider.

I then thought of creating the cookie myself but then I can't use the MERCURE_AUTHORIZATION_COOKIE_NAME as it's private.

Maybe I've missed something but should't it be possible to use a service which implements TokenProviderInterface with the Authorization class too?

Thanks & best Alex

Would be super cool to see how the Symfony Team creates a AGENTS.md file for the demo project.

The ai-bundle already has the file => https://github.com/symfony/ai-bundle/blob/main/AGENTS.md

Sure I can create my own, but to see what you add to the coding rules would be super interesting.

This MR adds the basic option to enable OAuth authentication through Github / Keycloak.

OAuth Login requires additional configuration from the user. This configuration is exposed through a set of new configuration variables.

It currently does not support any kind of roles / group management. This must be managed either trough the domain allowlist and/or on the provider side. All newly registered users are normal users and may be promoted though the web portal as necessary.

Implements #264

I would appreciate any feedback you may have!

Hey guys,

I am new to cachet and I am trying to set up cachet queue in docker for making my application faster when there are multiple subscribers for sending email. According to the document

"Cachet uses a queue to send Configuring Mail and Beacons without slowing down the rest of the application. This can be setup in a variety of ways."

I have not found any document for doing this. Can someone help in figuring this out. I set up my status page with queue as Database

Thanks,

Vignesh

Laravel Version

13.8

PHP Version

8.4

Database Driver & Version

MySQL 8.0.18 for Windows 11 Pro on x86_64

Description

DatabaseLock::acquire() catches all QueryException instances indiscriminately in its INSERT fallback path, including errors that are not related (e.g. SQLSTATE[22001]: String data, right truncated). This turns permanent, unrecoverable errors into a 30-second retry loop that always ends in LockTimeoutException, masking the real cause.

When the lock INSERT fails, acquire() catches the QueryException and attempts an UPDATE assuming the failure was due to a duplicate key (i.e. the lock already exists). This assumption only holds for SQLSTATE 23xxx (Integrity Constraint Violation). Other SQL errors such as 22001 (value too long for column) are silently swallowed and cause the UPDATE to match zero rows, so acquire() returns false on every attempt until the block timeout expires.

I think DatabaseLock::adquire() must re-throw the exception if it is not an integrity constraint violation (SQLSTATE 23xxx), which is the only class of errors that legitimately indicates locking:

} catch (QueryException $e) {
    // just an example, maybe put this in a trait like `DetectsIntegrityConstraints`
    if (! str_starts_with($e->getSqlState(), '23')) {
        throw $e;
    }

    $updated = $this->connection->table($this->table)
        ->where('key', $this->name)
        ->where(fn ($q) => $q->where('owner', $this->owner)->orWhere('expiration', '<=',
$this->currentTime()))
        ->update(['owner' => $this->owner, 'expiration' => $this->expiresAt()]);

    $acquired = $updated >= 1;
}

I tested it on MySQL only. The fix should work on any SQL-92 compliant engine since SQLSTATE 23xxx is standardised, but I didn't verified this behaviour on other engines.

An alternative approach would be to validate the key length before attempting the INSERT and throw an explicit exception if it exceeds 255 characters, since the cache_locks migration defines the key column as $table->string('key')->primary();. However, this would only address the symptom in this specific table, whereas re-throwing non-23xxx exceptions fixes the underlying assumption in the catch block and protects against any unrecoverable QueryException, regardless of cause. Both fixes are complementary but the exception re-throw is the more robust solution.

This bug was discovered when investigating an infinite 503 refresh loop in a Statamic static cache installation. The lock key exceeded the VARCHAR(255) limit of the cache_locks table, causing repeated SQLSTATE[22001] errors that DatabaseLock::acquire() misidentified, retrying for 30 seconds before throwing LockTimeoutException.

Steps To Reproduce

Quick steps using composer:

composer create-project laravel/laravel laravel-db-cache-lock
cd laravel-db-cache-lock
# configure MySQL database on .env
php artisan migrate

php artisan tinker --execute="
  try {
      Cache::store('database')->lock(str_repeat('a', 260), 30)->block(5, fn() => 'ok');
  } catch (\Illuminate\Contracts\Cache\LockTimeoutException \$e) {
      echo 'LockTimeoutException thrown after 5s' . PHP_EOL;
  }
  "

The last command shows LockTimeoutException thrown after 5s and the expected result is an exception with the message SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'key' at row 1

I don't know why it was proposed in #147 not to include entryExists in EntrypointLookupInterface, but it doesn't makes sense to test agains't a specific class instead of the interface.

In my case, this cause an issue as I cannot use dependence injection on EntrypointLookupInterface and expect entryExists to be present.

If this is not approved, I suggest adding entryExists to it's own interface and have EntrypointLookup implement both (although you won't fix the dependency injection problem).

svg file are not list in the .htaccess For exemple : /bundles/apiplatform/logo-header.svg

Summary

Backports the Route::static() CDN-cacheable route API from the Laravel 13.x PR to Laravel 12.x.

This includes:

• the fluent Route::static() method,
• Illuminate\Routing\Middleware\CacheStaticResponse,
• request-aware static-route middleware stripping,
• final response hardening after the full HTTP middleware stack,
• default cache.static configuration,
• routing, middleware, kernel, and integration tests.

Backport Notes

The Laravel 13.x implementation uses Illuminate\Foundation\Http\Middleware\PreventRequestForgery in the default static-route middleware stripping list. Laravel 12.x uses Illuminate\Foundation\Http\Middleware\ValidateCsrfToken in the default web group, so this backport swaps the default to ValidateCsrfToken.

The rest of the behavior matches the 13.x PR:

• cacheable static requests skip configured stateful middleware,
• X-Inertia requests keep normal middleware and bypass static response mutation,
• non-cacheable methods, non-cacheable statuses, and redirects are not made static,
• cookies are stripped according to the route/config options,
• Cache-Control, optional CDN-Cache-Control, and merged Vary headers are emitted,
• the final kernel pass keeps Livewire-style global no-cache middleware from overriding static route cache headers.

Related PRs

• Laravel 13.x framework PR: https://github.com/laravel/framework/pull/60286
• Laravel 13.x docs PR: https://github.com/laravel/docs/pull/11214
• Laravel 12.x docs backport PR: https://github.com/laravel/docs/pull/11215

Compatibility Verification

Verified with the Herd test app against the Laravel 12.x backport branch:

• PHP 8.4 + Inertia 1 + Livewire 3: passed
• PHP 8.4 + Inertia 1 + Livewire 4: passed
• PHP 8.4 + Inertia 2 + Livewire 3: passed
• PHP 8.4 + Inertia 2 + Livewire 4: passed
• PHP 8.4 + Inertia 3 + Livewire 3: passed
• PHP 8.4 + Inertia 3 + Livewire 4: passed
• PHP 8.5 + Inertia 2 + Livewire 3: passed
• PHP 8.5 + Inertia 2 + Livewire 4: passed
• PHP 8.5 + Inertia 3 + Livewire 3: passed
• PHP 8.5 + Inertia 3 + Livewire 4: passed

Inertia 1 was not installable on PHP 8.5 because inertiajs/inertia-laravel 1.x only allows PHP through 8.4.

Tests

Run with PHP 8.4 after refreshing local dependencies for the 12.x branch:

• php84 vendor/bin/phpunit tests/Routing/RouteStaticMethodTest.php tests/Http/Middleware/CacheStaticResponseTest.php tests/Integration/Routing/RouteStaticResponseTest.php tests/Foundation/Http/KernelTest.php
• php84 vendor/bin/phpunit tests/Routing/RoutingRouteTest.php tests/Http/Middleware/CacheTest.php
• vendor/bin/pint config/cache.php src/Illuminate/Foundation/Http/Kernel.php src/Illuminate/Routing/Route.php src/Illuminate/Routing/Router.php src/Illuminate/Routing/Middleware/CacheStaticResponse.php tests/Foundation/Http/KernelTest.php tests/Routing/RouteStaticMethodTest.php tests/Http/Middleware/CacheStaticResponseTest.php tests/Integration/Routing/RouteStaticResponseTest.php

The example given in https://docs.cachethq.io/api-reference/schedules/create-schedule does not work out of the box:

• missing --header 'Accept: application/json as described in https://github.com/cachethq/cachet/issues/4587#issuecomment-4660661133
• scheduled_at and completed_at use ISO timestamp but the API does not
• linked components require a status

Here is a fixed version:

curl --request POST \
  --url http://localhost/api/schedules \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json' \
  --data '
{
  "name": "<string>",
  "message": "<string>",
  "scheduled_at": "2023-11-07 05:31:56",
  "completed_at": "2023-11-07 05:31:56",
  "components": [
    {
      "id": 123,
      "status": 1
    }
  ]
}
'

Is LDAP support planned? I saw there was a lot of interest in this with version 2. Would be nice to have this onboard for v3. There is a package available https://github.com/DirectoryTree/LdapRecord-Laravel https://chrispian.com/laravel-filament-tutorial-customize-login-to-use-ldap

Laravel Version

13.9.0

PHP Version

8.3

Database Driver & Version

No response

Description

When using the async feature of the http client facade without pool, the promises that are returned are mutable which to me is quite unexpected since guzzle promises are immutable and the promises returned are typed as the guzzle PromiseInterface.

The comment on PromiseInterface::then even state that it returns a new instance

/**
 * Appends fulfillment and rejection handlers to the promise, and returns
 * a new promise resolving to the return value of the called handler.
 *
 * @param callable $onFulfilled Invoked when the promise fulfills.
 * @param callable $onRejected  Invoked when the promise is rejected.
 */
public function then(
    ?callable $onFulfilled = null,
    ?callable $onRejected = null
): PromiseInterface;

In this example $pomise1, $promise2 and $promise3 all point to the same promise since the then function returns $this.

Artisan::command('promises', function () {
    $promise1 = Http::async()
        ->get('https://www.laravel.com')
        ->then(fn (Response $response) => $response->status());
    $promise2 = $promise1->then(fn ($records) => 'one');
    $promise3 = $promise2->then(fn ($records) => 'two');

    $result1 = $promise1->wait();
    $result2 = $promise2->wait();
    $result3 = $promise3->wait();

    dump($result1, $result2, $result3);
});

The output is:

"two"
"two"
"two"

The expected output would be:

200
"one"
"two"

Steps To Reproduce

Artisan::command('promises', function () {
    $promise1 = Http::async()->get('https://www.laravel.com');
    $promise2 = $promise1->then(fn ($records) => ['one', 'two']);
    $promise3 = $promise2->then(fn ($records) => ['three', 'four']);

    $result1 = $promise1->wait();
    $result2 = $promise2->wait();
    $result3 = $promise3->wait();

    dump($result1, $result2, $result3);
});

Octane Version

2.11.0

Laravel Version

12.20.0

PHP Version

8.3.23

What server type are you using?

FrankenPHP

Server Version

1.8.0

Database Driver & Version

No response

Description

I have an octane app running inside a docker container and use a bind mount for the application code. When editing files, fs events are not sent across the bind mount to the container, so the watcher does not detect them. I have the same issue reported in #487. There is also an open issue on the frankenphp repository https://github.com/php/frankenphp/issues/1616.

A potential solution would be to add an option to octane:frankenphp, like --chokidar to use chokidar instead of frankenphp's watcher.

Steps To Reproduce

Same as #487, but using frankenphp.

I just tried upgrading webpack-dev-server to v6, but it fails to start:

> encore dev-server

Running webpack-dev-server ...

node:internal/modules/cjs/loader:714
    throw e;
    ^

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './bin/webpack-dev-server' is not defined by "exports" in /app/node_modules/webpack-dev-server/package.json
    at exportsNotFound (node:internal/modules/esm/resolve:314:10)
    at packageExportsResolve (node:internal/modules/esm/resolve:662:9)
    at resolveExports (node:internal/modules/cjs/loader:707:36)
    at Module._findPath (node:internal/modules/cjs/loader:774:31)
    at Module._resolveFilename (node:internal/modules/cjs/loader:1502:27)
    at wrapResolveFilename (node:internal/modules/cjs/loader:1071:27)
    at defaultResolveImplForCJSLoading (node:internal/modules/cjs/loader:1095:10)
    at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1122:12)
    at Module._load (node:internal/modules/cjs/loader:1294:5)
    at wrapModuleLoad (node:internal/modules/cjs/loader:255:19)
    at Module.require (node:internal/modules/cjs/loader:1617:12)
    at require (node:internal/modules/helpers:153:16)
    at Object.<anonymous> (/app/node_modules/@symfony/webpack-encore/bin/encore.js:70:12)
    at Module._compile (node:internal/modules/cjs/loader:1871:14)
    at Object..js (node:internal/modules/cjs/loader:2002:10)
    at Module.load (node:internal/modules/cjs/loader:1594:32)
    at Module._load (node:internal/modules/cjs/loader:1396:12)
    at wrapModuleLoad (node:internal/modules/cjs/loader:255:19)
    at Module.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:154:5)
    at node:internal/main/run_main_module:33:47 {
code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
}

Tried all the possibilities to install Symfony Demo (with symfony and composer) but when start Symfony Demo website, assets are not loaded.

Hi,

I've just migrated from v2.32.0 to v2.36.0. Since then, I have some issues with my twig component and more precisely the nullsafe operator :

Before migration :

<twig:Page
    title="Commandes - Affaire : {{ affaire.numero }}"
    breadcrumb="Accueil > <a href='{{ pathIndex }}'>Affaires</a> > {{ lienParent }} {{ lienAffaire }} > Commandes"
    pageTitle="Affaire : {{ affaire.numero ~ ' - ' ~ affaire.commune?.organisation?.raisonSociale ~ ' - ' ~ affaire.libelle }}"
    :menuTabs="menu_tabs"
    :menu="menu"
>

In Page.html.twig :

<h2 class="page-title">
   {{ this.pageTitle }}
</h2>

Was working fine.

But now, if organisation is null, I get : "Impossible to access an attribute ("raisonSociale") on a null variable".

I have to set the variable before : {% set pageTitle = "Affaire : " ~ affaire.numero ~ ' - ' ~ affaire.commune?.organisation?.raisonSociale ~ ' - ' ~ affaire.libelle %} And then : :pageTitle="pageTitle"

I've migrated to v3.2.0 to see if there was a little regression that was corrected but no.

Am I missing something ?

Thank you !

Ps : I'm using twig/twig version v3.28.0 and <twig:Page :pageTitle="affaire.commune?.organisation?.raisonSociale" /> not working neither

Covers the dev command, customizing and filtering dev processes, and the dev:list command.

Summary

Slim v1 of symfony/ux-image — responsive image components addressing all feedback from the original PR #3188.

What's Included

<twig:ux:img> — Simple responsive images

• Viewport-based width syntax (100vw md:80vw)
• Automatic srcset/sizes generation
• Density support (densities="x1 x2")
• Fallback format for older browsers

<twig:ux:picture> — Art direction

• Breakpoint-specific aspect ratios (sm:1:1 md:16:9)
• Ratio cascading (CSS-like inheritance)
• Exclusive media queries for correct aspect ratio

Key Changes from Original PR

Provider Architecture

• PassThroughProvider (default) — works with local files, no CDN required
• UrlPatternProvider — generic CDN via URL template (Cloudflare, imgix, etc.)
• Custom providers — implement ProviderInterface and tag with ux_image.provider

Usage

{# Simple responsive image #}
<twig:ux:img src="/images/hero.jpg" alt="Hero" width="100vw md:80vw" />

{# Art direction #}
<twig:ux:picture src="/images/banner.jpg" alt="Banner" width="100vw md:80vw" ratio="sm:1:1 md:16:9" />

{# Without Twig components #}
{{ ux_image('/images/hero.jpg', 'Hero', { width: '100vw md:80vw' }) }}

Configuration

# config/packages/ux_image.yaml
ux_image:
    default_provider: passthrough
    providers:
        cloudflare:
            pattern: '/cdn-cgi/image/w={width},f={format},q={quality}/{src}'

This addresses feedback from @WebMamba, @smnandre, and @Kocal on the original PR. Happy to iterate further!

Hi there,

I've just integrated Mistral AI and related models into my application and I realised that I did not have any information about cached token usage. Here is a detailed note about it. Do not hesitate to correct me if I'm wrong into my appreciation.

Description

Mistral's Chat Completions API (/v1/chat/completions) supports prompt caching and returns the number of cached prompt tokens in the response under usage.prompt_tokens_details.cached_tokens (cached tokens are billed at 10% of the input price). See the official docs: https://docs.mistral.ai/studio-api/conversations/advanced/prompt-caching

It seems that the Mistral bridge's TokenUsageExtractor never reads that field, so the resulting TokenUsage always has cachedTokens === null. Any application relying on TokenUsage for cost accounting or cache observability cannot see Mistral cached tokens, which leads to an input-cost overestimate (the cached portion is billed at full rate instead of 10%).

Affected code

Symfony\AI\Platform\Bridge\Mistral\Llm\TokenUsageExtractor (src/platform/src/Bridge/Mistral/Llm/TokenUsageExtractor.php)

Current implementation only maps prompt_tokens, completion_tokens, total_tokens and the rate-limit headers:

return new TokenUsage(
    promptTokens: $content['usage']['prompt_tokens'] ?? null,
    completionTokens: $content['usage']['completion_tokens'] ?? null,
    remainingTokensMinute: null !== $remainingTokensMinute ? (int) $remainingTokensMinute : null,
    remainingTokensMonth: null !== $remainingTokensMonth ? (int) $remainingTokensMonth : null,
    totalTokens: $content['usage']['total_tokens'] ?? null,
);

cachedTokens is missing. The TokenUsage value object already supports it (TokenUsage::__construct(..., ?int $cachedTokens = null, ...)), and the OpenAI bridge populates it from input_tokens_details.cached_tokens in Symfony\AI\Platform\Bridge\OpenAi\Gpt\TokenUsageExtractor, so there is an established pattern.

How to reproduce

1. Send two consecutive chat-completion requests that share a long common prefix (e.g. a large system prompt) to a Mistral model, with prompt_cache_key set on the request.
2. Inspect the returned TokenUsage.

Expected: getCachedTokens() returns the value of usage.prompt_tokens_details.cached_tokens (a non-zero multiple of 64 once the cache is warm).

Actual: getCachedTokens() is always null.

Versions

• symfony/ai-platform / Mistral bridge: 0.10 (also present on main at time of writing)
• PHP: 8.4

Hope it is clear. Do not hesitate if I'm doing something wrong. Thanks for your amazing work and support.

Best !🤘

Documents the new BeforeAuthenticateEvent added in symfony/symfony#64304.

The event is dispatched right before an authenticator's authenticate() method is called, primarily for auditing/logging authentication attempts (including ones targeting an unknown user, which CheckPassportEvent cannot observe).

Updated make:command to generate a command with __invoke method.

Also added an option to use the old structure.

The original round-trip issue for UserMessage images (base64 vs. data URL mismatch) was already fixed by 8ca2ab09. This PR addresses the remaining case reported in the issue's follow-up: AssistantMessage content.

MessageNormalizer::normalizeAssistantParts() only handled Text, Thinking and ToolCall parts and silently dropped anything else. So an AssistantMessage carrying an Image (e.g. a generated image returned by Gemini) was lost on the way to the store and could not be read back.

File/Document/Image/Audio (as data URL) and ImageUrl/DocumentUrl parts are now handled on both the normalize and denormalize sides, mirroring what is already done for UserMessage content. Added a round-trip test for an AssistantMessage holding an Image.

Companion PR to symfony/ux#3469. Adds the Toolkit/Shadcn docs page for the sidebar recipe.

Kept as draft until symfony/ux#3469 (which introduces the upstream recipe) is merged.

Split out from the original #54 so each component can be reviewed/merged independently alongside its upstream recipe.

Hi, I am trying to deploy cachetv3.x for test. But in my deployment I get this error when I try to login with a previous created admin user:

 Symfony\Component\HttpKernel\Exception\MethodNotAllowedHttpException 

 The POST method is not supported for route dashboard/login. Supported methods: GET, HEAD. 

PHP 8.2.27 — Laravel 11.38.2

Here is my .env file:

    APP_NAME=Cachet
    APP_ENV=local
    APP_KEY=
    APP_DEBUG=true
    APP_TIMEZONE=UTC
    APP_URL=http://localhost

    APP_LOCALE=en
    APP_FALLBACK_LOCALE=en
    APP_FAKER_LOCALE=en_US

    APP_MAINTENANCE_DRIVER=file

    BCRYPT_ROUNDS=12

    LOG_CHANNEL=stack
    LOG_STACK=single
    LOG_DEPRECATIONS_CHANNEL=null
    LOG_LEVEL=debug

    DB_CONNECTION=mysql
    DB_HOST=mysql
    DB_DATABASE=cachet
    DB_USERNAME=cachet
    DB_PASSWORD=cachet
    DB_PORT=3306

    SESSION_DRIVER=database
    SESSION_LIFETIME=120
    SESSION_ENCRYPT=false
    SESSION_PATH=/
    SESSION_DOMAIN=null

    BROADCAST_CONNECTION=log
    FILESYSTEM_DISK=local
    QUEUE_CONNECTION=database

    CACHE_STORE=database
    CACHE_PREFIX=

    REDIS_CLIENT=phpredis
    REDIS_HOST=redis
    REDIS_PASSWORD=null
    REDIS_PORT=6379

    VITE_APP_NAME="Cachet"

    CACHET_BEACON=true
    CACHET_EMOJI=false
    CACHET_AUTO_TWITTER=true
    CACHET_PATH=/

The hostname of redis and mysql can be resolved locally.

Bumps webpack-dev-server from 5.2.4 to 5.2.5.

Hello! There is a strange issue I've found where if I'm running Panther in non-headless mode the site gets scraped as expected, however if I add --headless arg, it returns just: <html><head></head><body></body></html>. This is not isolated for just 1 site, I've already come across couple of them suffering from this issue.

Code snippet:

$client = Client::createChromeClient(__DIR__ . "/drivers/chromedriver", [ '--headless']);
$crawler = $client->request('GET', 'https://www.chanel.com/gb/fashion/p/G31318Y50006C8378/slingbacks-goatskin-grosgrain/');
echo $crawler->html();

When removing the headless option actual HTML of the site is obtained correctly. I'm using using chromedriver version 126.0.6478.126 for mac-x64 platform, but using the same version for linux yields the same result. The version of Panther is newest - 2.1.1.

Hi !

I am trying to deploy Cachet on an Openshift Cluster using this docker image. And no matter what type of config I try or what version I try, there is always an error somewhere or a feature not working.

Maybe I am doing something wrong in my deployment, but I tried to follow documentation and to do a deployment similar to the docker-compose one.

I am open to any suggestions to have a working deployement on an Openshift cluster.

Here is all the things I tried and the corresponding errors (I haven't tried everything because it takes time) :

Image from dockerhub

memcached is not available in this image and there is no variable to configure connection to anoher memcached instance, hence I have not tested with memcached for cache or sessions.

Image latest

updated 3 months ago, digest : sha256:1b1bcb00e588c6b43249a3a875140ecedca189c5a38f1b72593eb7415c1efde6

queue: Redis

queue: database

Image 2.3.15

most recent tag other than latest, updated 3 months ago, digest : sha256:c09a0e3ef78a88f7c1be8e67cc81545d13ff08b112fc54bf2e08c26af3e297a8

Little bug with this image, sometimes even if we are not logged in, there is a link logout at the bottom of the page with no effect when we click on it. And as soon as we leave the dashboard we are logged out. But sometimes this link is not present and we are not logged out when leaving the dashboard to see the status page for example. I have not diagnosed why and when this happens. There is some logs when clicking Dashboard in this situation : error 5
With this image when APP_DEBUG is set to true, the debug bar is not enabled.

queue: Redis

queue: database