Bumps php from 7.4.28-fpm to 8.1.5-fpm.

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 merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @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)

we've ignored php8 when running php7, now that we've updated to php8 we don't get any dependabot alerts still

that ignore should be invalidated automatically once updated IMHO, and is a rather annoying bug currently

invoking translator service is relatively easy also :+1:

bump-deps

it's probably best to provide a reproducer: https://symfony.com/doc/current/contributing/code/reproducer.html

Description

This would solve #49653 and also play nice with #[WithHttpStatus(4xx)].

The idea is any HttpException can be given a translatable message:

throw new HttpException(400, t('id'));

~Im just not sure if the normalizer should expose any translatable message, or just 4xx ones.~ edit: actually i think translatable messages should always be exposed, even 5xx responses could use some helpful hints for the user :sweat_smile:

but then the line between what's exposed, and what's not becomes super thin, so maybe this needs a new new ExposedHttpException() / new HttpException(expose: true)

Example

No response

closing in favor of #49138, that's sufficient.

see also https://github.com/symfony/symfony/pull/49138#discussion_r1136221587

i figured 200 + json null / empty string is just fine also :)

Description

Hi,

in #49518 i realized we have 2 ways of handling null as a controller result

1. json encode as null + http 200
2. no content + http 204

i figured having a controller utility builtin creates better autocompletion due the use of $this->... already

considering #49518, this allows doing:

#[Serialize(201)]
endpoint(): mixed {
    if ($someSpecialCase) {
        return $this->noContent(); // 204
    }

    return $someOtherSpecialCase ? ['data' => true] : null; // 201
}

Example

No response

just tested 6.2.7 real quick, and i get empty array for variadic arg by default with autowiring ... as expected kinda.

so i believe it works actually :shrug:

@ddr5292 please open an issue if you believe anything's wrong still.

But how to test is given key is array or scalar value.

you know what your application expects

getting the raw value is done using all()['key']. Please open a doc PR if it's unclear.

a deprecation breaks your code?

IIUC it should be possible to provide nothing for the variadic arg during autowiring :thinking: https://3v4l.org/rST30

i believe nullable args that cant be autowired are also skipped

bump-deps

Update README.md

Update README.md

Update composer.json

Delete AsyncBundle

Delete .php_cs

Update composer.json

Update WorkerClass.php

Merge remote-tracking branch 'origin/2.10'

Update WorkerClass.php

Update composer.json

Delete .php_cs

Delete AsyncBundle

Description

Hi,

in #49518 i realized we have 2 ways of handling null as a controller result

1. json encode as null + http 200
2. no content + http 204

i figured having a controller utility builtin creates better autocompletion due the use of $this->... already

considering #49518, this allows doing:

#[Serialize(201)]
endpoint(): mixed {
    if ($someSpecialCase) {
        return $this->noContent(); // 204
    }

    return $someOtherSpecialCase ? ['data' => true] : null; // 201
}

Example

No response

Description

Hi,

in #49518 i realized we have 2 ways of handling null as a controller result

1. json encode as null + http 200
2. no content + http 204

i figured having a controller utility builtin creates better autocompletion due the use of $this->... already

considering #49518, this allows doing:

#[Serialize(201)]
endpoint(): mixed {
    if ($someSpecialCase) {
        return $this->noContent(); // 204
    }

    return $someOtherSpecialCase ? ['data' => true] : null; // 201
}

Example

No response

well, the AbstractController is already a response factory in disguise, and 204 is a relatively common case :shrug:

but i understand we're abusing AbstractController its purpose maybe? though i thought its purpose was to act as a HTTP DSL sort of speak

my idea was self-discovery mostly:

a controller utility builtin creates better autocompletion due the use of $this->... already