One click away in PHP Runtime Configuration docs you will find that in the php.ini the default value is “60”.
In case you wonder what unit these “60” is, you will find (in seconds) a bit down below the config table.
– Yeah, seconds was my first guess, but I need to assure it is not microseconds by any chance. –

And thats it! Thats the post.

P.S: It is funny how scattered information sometimes is, although is all there.
AI did know, but did not name a source.
And since AI is not to trust, I still had to look it up via Search.

This is a common pitfall when writing integration tests in Symfony and using custom HTTP headers: the necessity to add an HTTP_ prefix to the header in the test.
If you do not add the prefix to the custom header, it will silently not be added to the request, and you have to debug why the request fails.

So this will fail:

static::$client->request('GET', '/ping', [], [], ['X-Custom-Header' => 'custom']);

And this will work:

static::$client->request('GET', '/ping', [], [], ['HTTP_X-Custom-Header' => 'custom']);

According to the documentation, you would actually also need to transform it to uppercase and replace the dash with an underscore but it will work with just the HTTP prefix.

HTTP_X_CUSTOM_HEADER

The prefix is however not necessary for not custom but standard headers like ‘Content-Type’.

This is not an intuitive requirement, and I wish it were not necessary.
At the very least, a warning would be nice when the test client encounters a non-prefixed, non-standard header.

A related StackOverflow Post: https://stackoverflow.com/questions/11549672/symfony-functional-test-custom-headers-not-passing-through

use Symfony\Component\HttpFoundation\BinaryFileResponse;

$file = 'path/to/file.txt';
$response = new BinaryFileResponse($file);

But in some cases you might want to create an image dynamically and return it directly from the controller without storing it on the filesystem.
So you can create your image with the GD library and directly stream the GDImage object from the symfony controller with the StreamedResponse class.

$image = imagecreatetruecolor($imgWidth, $imgHeight);
// do something with the image
return new StreamedResponse(fn () => imagepng($image), 200, ['Content-Type' => 'image/png']);

Great that was easy, but not so obvious ;)

Another thing you might wonder is how to add the OpenAPI annotation when streaming images to generate a proper documentation for your endpoints.
Just use MediaType class in the Response annotation and set the format to binary.

responses: [
	new OA\Response(
		response: 200,
		description: "dynamic image",
		content: new OA\MediaType(
			mediaType: 'image/png', 
			schema: new OA\Schema(
				type: 'string',
				format: 'binary'
			)
		)
	),
]

Then finally you should test the StreamedResponse from the controller.
For this you can not use the normal $client->getResponse() but instead use the getInternalResponse which holds the binary data as string however.
So to test the binary response in your test add this:

$response = static::$client->getInternalResponse();
$image = $response->getContent();
		
self::assertInstanceOf(GdImage::class, imagecreatefromstring($image));

This seems to be valid from Symfony 4 upwards.
Before Symfony 4 you could get the binary data from $client->getResponse().

So since version 5.1 symfony will log deprecations to a dedicated log channel when it exists and ships with this monolog config:

monolog:
    channels:
        - deprecation # Deprecations are logged in the dedicated "deprecation" channel when it exists

This is added already in the recipe and ships when installing symfony.

Ok, but the handler for this deprecation channel is not configured, so you have to do this yourself.
How? Add this to your monolog config:

...
when@dev:
   monolog:
       handlers:
           main:
	       type: stream
	       path: "%kernel.logs_dir%/%kernel.environment%.log"
	       level: debug
	       channels: ["!event", "!deprecation"]
	   deprecation:
	       type: rotating_file
	       path: "%kernel.logs_dir%/%kernel.environment%.deprecations.log"
	       max_files: 2
	       channels: [deprecation]
	   console:
	       type: console
	       process_psr_3_messages: false
               channels: ["!event", "!doctrine", "!console", "!deprecation"]
...

What is happening here?
We declare a new handler for deprecations named deprecation when in dev environment.
This handler listens to the deprecation channel.
We declare it as a rotating file since the assumption is we dont need to keep this log entries for longer.
The other handlers will ignore the deprecation channel by adding a !deprecation to the channel directive.

The deprecation channel was already created and so all deprecations are now not in the main log file but in a dedicated deprecation log file.

For production we dont need to edit configuration since the log level here is info and therefore deprecations will not be considered anyway.

Since i am using symfony anyway i can use the String component which has a handy slugger which converts any characters into safe ascii characters.
It is very flexible and can be customized with locales, custom replacements and closures.

$umlautString = "Müller Meier";
$slugger = new Symfony\Component\String\Slugger\AsciiSlugger('de');
$slugger->slug($umlautString, $seperator = ' ')->toString();
echo $umlautString; // mueller meier

I guess this will become my go-to method resp. slugger to convert umlaute in any PHP application.

One example why the PHP native ways have their downsides is iconv.
Iconv can transliterate umlauts:

$string = iconv('UTF-8', 'ASCII//TRANSLIT', $string);

But it can not handle the locale in a convenient way but relies on the system wide locale instead.
You need to use the global method setlocale before using it and reset the locale after usage again, which can cause sideeffects and is not very convenient.

From: https://www.php.net/manual/de/function.iconv.php#105507

$utf8_sentence = 'Weiß, Göbel';
//transliterate
$trans_sentence = iconv('UTF-8', 'ASCII//TRANSLIT', $utf8_sentence);
//gives [Weiss, Gobel]
//Germany
setlocale(LC_ALL, 'de_DE');
$trans_sentence = iconv('UTF-8', 'ASCII//TRANSLIT', $utf8_sentence);
//gives [Weiss, Goebel]

Thanks to this StackOverflow answer for the tip with the symfony String component. https://stackoverflow.com/a/68742023/541949

An exception occurred while executing 'INSERT INTO user (id, email, roles, password, is_verified) VALUES (?, ?, ?, ?, ?)' with params [3, "dev@dev.de", "[]", "your-encrypted-password", 0]:
SQLSTATE[42601]: Syntax error: 7 ERROR: syntax error at or near "user"
LINE 1: INSERT INTO user (id, email, roles, password, is_verified) V...

To fix this you have to escape the table name on your entity, fe. User.php:

@ORM\Table(name="`user`")

(note the backticks inside the quotes!)

If you generate the entity with maker bundle: bin/console make:entity directly on Postgres the backticks are added automatically.
But not when you switch the DB type. Then you have to add them manually. :)

Since symfony/dotenv 5.1: Passing a boolean to the constructor of “Symfony\Component\Dotenv\Dotenv” is deprecated, use “Dotenv::usePutenv()

To fix this, go to config/bootstrap.php and remove the false from the Dotenv constructor:
(new Dotenv(false))->loadEnv(dirname(DIR).'/.env');
to
(new Dotenv())->loadEnv(dirname(DIR).'/.env');
See: https://github.com/symfony/symfony/issues/37195

Actually the file config/bootstrap.php has been removed from symfony 5.1 and was replaced in public/index.php.

But since the project was updated from an symfony 4 version the bootrap file is still present.

So another option would be to remove the boostrap file and update the project entirely to symfony 5.1 recipe.
This is not trivial though as you can see in this corresponfing PullRequest.

To disable them you can set the ENV var
SYMFONY_DEPRECATIONS_HELPER=disabled
and the warnings will not be displayed anymore and CI/CD will pass again.
Update from comments:
SYMFONY_DEPRECATIONS_HELPER=weak does also work and will still show the deprecation warnings count. (Thx Max)

This was introduced a while ago with this PullRequest and works for symfony >= 3.1.

So for running the tests manually, do like this:

SYMFONY_DEPRECATIONS_HELPER=disabled vendor/bin/phpunit

Or add it to the phpunit.xml

<php>
    <ini name="error_reporting" value="-1" />
    <env name="KERNEL_CLASS" value="App\Kernel" />
    ...
    <env name="SYMFONY_DEPRECATIONS_HELPER" value="disabled" />
</php>

With bitbucket pipelines it looks like this:

pipelines:
   branches:
     master:
       - step:
           script:
             - curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
             - composer install
             - SYMFONY_DEPRECATIONS_HELPER=disabled composer test
             - composer check-style

Did you know you can also directly render those as PDF files?

It’s actually quite easy. Like so:

php bin/console workflow:dump myWorkflow | dot -Tpdf > data/workflow/myWorkflow.pdf

When working with this constellation you will sooner or later come across the i18n topic. Most likely you would want to share translations between front- and backend. So that you could keep translations in one single location while using it for frontend templates as well as server-side error messages etc.

One approach would be to store translations in the symfony yml or xml files and deliver those to the frontend via an api endpoint.
Given that front- and backend-code run on the same server, there is an even simpler solution.

Since symfony does not only read yml or xml but also translations in the json format, you can simply keep translations in the frontend and read those files with symfony directly.

All you need to do to achieve this is symlink the angular translation files to your symfony translation catalog location.

messages.de.json -> ../../../web/ng/I18n/de_DE.json
messages.en.json -> ../../../web/ng/I18n/en_EN.json

Disclaimer: This works only for relatively simple use cases with no complex translation patterns. But hey…