When deviated from its default value, it can lead to inexpected behavior in common functions like json_encode() and serialize().

The Problem

If you change the serialize_precision setting from its default value of -1, the float precision will be more digits than 2 decimal places.
If you are not aware of this setting, it can lead to hard-to-debug issues in your application.

This behavior can silently break payload validation, API responses, or any logic that relies on exact string comparisons of numeric values or which assumes that float values come with 2 decimal places.

Impact on Functions

When serialize_precision is set to something other than -1, the following functions are affected:

• json_encode()
• json_decode()
• serialize()
• unserialize()

Consider the following example.
Setting a high precision changes the number in the JSON output:

<?php
// High precision
ini_set("serialize_precision", 100);
echo json_encode(12.12);
// Output: 12.1199999999999992184029906638897955417633056640625

// Default (recommended) precision
ini_set("serialize_precision", -1);
echo json_encode(12.12);
// Output: 12.12

How to Check Your Configuration

So better verify your current setting, especially when dealing with mysterious floating-point issues in legacy environments.
When on shared hosting, you might even not know that the setting was changed.

You can check it via code:

echo ini_get("serialize_precision");

Or, if you are using PHP 8.5 or newer, you can conveniently check for configuration differences using the CLI:

php --ini=diff

This will highlight any settings that differ from the PHP defaults, making it much easier to spot such dangerous configurations.

Conclusion

If you encounter unexpected floating-point behavior in your PHP application, check the serialize_precision setting first. It’s a simple fix that can save you hours of debugging.

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.

Composer-patches is a handy Composer plugin that applies diff patches to specific packages during installation.

Basically, you store a diff patch in your project, specify which vendor package it should be applied to in your composer.json, and the plugin will apply the patch to the original code of the vendor package after it got installed by composer.

The documentation provides detailed instructions on how to set up the plugin.
In short, you need:

• Install the plugin (we’re using the v2 beta) with:
  composer require cweagans/composer-patches:^2.0.0-beta2
• Create a patch. The plugin relies on Git as the patcher, so you can use Git to generate the patch file. (See below)
  However, I recommend using another package to create the patch file:
  https://github.com/symplify/vendor-patches
  This package provides an opinionated but reasonable way to create and store your patches. vendor-patches takes care of the correct paths in the patch file, which might not be immediately obvious: Pathes should be relative to the vendor package root and not relative to your projects root dir.
• Add the patch instructions to your composer.json by including a patches section under extra. For example:

"extra": {
  "patches": {
    "oxid-esales/oxideshop-ce": {
      "Disable user registration due to spam attacks": "./patches/disable-registerUser.patch"
    }
  }
}

On your next composer install the vendor package will be patched and the vendor’s
code will be altered according the patch.

Some notes: If you encounter the error:

Could not apply patch! Skipping. The error was: Cannot apply patch disable-registerUser.patch

You might have incorrect paths in your patch file. As mentioned above, the paths need to be relative to the vendor root directory, not your project’s root directory.
So to manually create the diff patches, run this command:

diff --git a/source/Application/Component/UserComponent.php b/source/Application/Component/UserComponent.php

This is wrong usage from project root dir:

diff --git a/vendor/oxid-esales/oxideshop-ce/source/Application/Component/UserComponent.php b/vendor/oxid-esales/oxideshop-ce/source/Application/Component/UserComponent.php

Happy patching! :)

This is surprisingly not intuitive, as you cannot simply pass an array of integers to a prepared statement. Instead, you need to add special binding types to inform Doctrine that this is indeed an array of integers.

It’s very well explained in the documentation under the Parameters Conversion section:
https://www.doctrine-project.org/projects/doctrine-dbal/en/current/reference/data-retrieval-and-manipulation.html#list-of-parameters-conversion
But it is rather hard to find and it took me a while.

The trick is to add the array binding types to the the types parameters to the query method. In the case of integers, it is \Doctrine\DBAL\ArrayParameterType::INTEGER.
Now Doctrine knows how to handle the types in the array while binding the values.

Example:

$sql = 'SELECT * FROM items WHERE id IN (?)'; 
$numbersAsStrings = "1,2,3";
$numbers = array_map('intval', explode(',', $numbersAsStrings));
$users = $con->fetchAllAssociative(
  $sql, 
  [$numbers], 
  [ArrayParameterType::INTEGER]
);

If you omit the types, Doctrine will simply try to bind the array as string, which will fail and you get this error:
Array to string conversion

If you try to pass it as a comma-separated string yourself and omit the types like $numbers = implode(',',array_map('intval', explode(',', $numbersAsStrings))); You will get an error because Doctrine expects an array of values for the IN clause and not a string.
Error:
count(): Argument #1 ($value) must be of type Countable|array, string given

I hope this helps someone finding out how to make WHERE IN SQL queries with Doctrine more quickly than me next time.

PHPStan, by the way, is a static analysis tool for PHP that enforces strict typing and checks for compliance with PHPDoc annotations, ensuring code is robust and maintainable.
For any serious project you should use it.

For this code:

$array = $this->getUntypedArray();
$res = $this->funcWithInt($array['number']);
...
private function funcWithInt(int $number):int {
    return $number++;
}

A typical error could be:

Parameter #1 $number of method TestClass::funcWithInt expects int, mixed given.

You can try to typecast the value:

$res = $this->funcWithInt((int)$array['number']);

But PHPStan will not accept this and will yield this error:

Cannot cast mixed to int.

To type these untyped arrays, you can use PHPStan types. These types can be defined in a PHP DocBlock, and PHPStan will use them and the error will be gone.
You can also reuse the types throughout the code in this class.

Note that you need to define the PHPStan type in a DocBlock outside of the class.
If defined inside the class or in a function, it will not be recognized by PHPStan!

Example (see also here: https://phpstan.org/r/4ff8a134-4494-46e1-a026-1d5a741289e7):

<?php declare(strict_types = 1);

/**
 * @phpstan-type Test array{
 *     string: string,
 *     number: int,
 *     array?: array{title: string}
 * }
 */
class ExampleClass
{
    /**
     * @return Test
     */
    private function getArray(): array
    {
        return ['string' => 'test', 'number' => 42, 'array' => ['title' => 'title']];
    }

    public function processArray(): void
    {
        $array = $this->getArray();
        $res = $this->funcWithInt($array['number']);

	/** Test $anotherArray */
    	$anotherArray = ['string' => 'test2', 'number' => 66];
	$res = $this->funcWithInt($anotherArray['number']);
		
        echo "Result: " . $res;
    }

    private function funcWithInt(int $number): int
    {
        return $number + 1;
    }
}

Now the code will pass the PHPStan audit and some other benefits come with this:
PHPStan types are also supported beyond PHPStan.
IDEs like PhpStorm can recognize and use the type definitions.
Additionally, PHPStan types are compatible with Psalm (another static analysis tool which is often used in combination with PHPStan).

In general, I would say it is better to map arrays to typed objects, such as DTOs, but sometimes this is not practical, and in those cases, PHPStan types provide a quick way to type untyped data.

You can also use PHPStan types across files by importing the phpstan-type in another file.

To use a phpstan-type across files, you can import it using the @phpstan-import-type annotation in another class’s PHPDocs.
Note that phpstan-import-type must be placed in the class’s docblock.
See: https://phpstan.org/writing-php-code/phpdoc-types#local-type-aliases

/**
 * @phpstan-import-type Test from ExampleClass
 */
class OtherClass
{
  /**
  * @param Test[] $test
  */
  function doSomething(array $test) {
    ...
  }
}

Deployer executes a set of commands on the target server to build your project and enable the newly built version. A typical deployment process with Deployer involves SSHing into the target machine, where it performs a Git checkout of the project, installs dependencies via Composer, runs build commands, and possibly triggers some database migrations. When everything is successful, it will symlink the webroot to the new release.

On some servers, however, there are limitations that make this process unfeasible. For instance, you can’t install Composer, Git isn’t available, the CLI PHP version is different and can’t be changed, or certain asset-building processes aren’t possible because Node.js isn’t installed. This is often the case with shared hosting.

The strategy, therefore, is to build the project locally and upload it to the target machine.
In Deployer 6 there was a buildIn mechanism for building your project on the local host.
However with Deployer version 7 this has been removed and building your project locally has become a bit more fiddly.

With Deployer 6 you could just use the local() method on a task and set the deploy_path to a local dir.

task('build', function () {
    set('deploy_path', __DIR__ . '/.build');
    invoke('deploy:prepare');
    invoke('deploy:release');
    invoke('deploy:update_code');
    invoke('deploy:vendors');
    invoke('deploy:clear_paths');
    invoke('deploy:symlink');
})->local();

Then you could combine this with an upload task in a deploy task an you are done.

task('upload', function () {
     upload(__DIR__ . "/.build/current/", '{{release_path}}', ['--links']);
 });

 task('deploy', [
     'build',
     'upload',
     'cleanup',
     'success'
 ]);

See here for the docs of Deployer 6:
https://deployer.org/docs/6.x/advanced/deploy-strategies#build-server

Since Deployer 7, however, the local() method was removed. Instead, there is now a localhost() method, which defines a host for local builds. Additionally, you still need to define the remote host as the target destination for the upload.
However, you cannot specify a single task to run on a specific host, and therefore you cannot combine tasks for localhost and the remote host within a single task.

To build the project, we now need two separate tasks.
I managed to make it work with two tasks and two hosts: one for local build and one that takes the fresh local build and uploads it to the remote host.

localhost('local')->set('deploy_path', __DIR__ . '/.build');

host('remote')
    ->setHostname('server-host.com')
    ->set('remote_user', 'user')
    ->set('deploy_path', '/www/blog')
    ->set('http_user', 'user');
....

task('build', function () {
    // build it
})->once();

task('upload', function () {
    upload(__DIR__ . "/.build/current/", '{{deploy_path}}', ['--links']);
});

Then I simply run two separate commands: one for building on the local host and one for uploading to the remote host.

vendor/bin/dep build local
vendor/bin/dep upload remote

Not as convenient as previously but it works. :)

See this issue for context: https://github.com/deployphp/deployer/issues/2838

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

Then upgrade to Composer 2.4 and say hi to composer dump.
This version introduced a new command composer bump which will update your composer.json file to the precise version which is pinned in the composer.lock file.
It basically will sync the composer.json with the composer.lock versions and will keep the caret version constraints, so you can still make minor or patch version upgrades.

This will have the effect that the version constraints are hardenend and you will not be able to install versions lower than the currently installed version.
With not updated versions in composer.json file you will not have a precise version base and could install lower versions than actually required.

Another benefit is that you can more easily read the currently installed version number of your dependencies.
Otherwise you would need to grep through the composer.lock file which is much less readable and cumbersome.
Some IDEs like PHPSTORM are helping here though by adding the installed version behind the dependency constraint in the composer.json file in the editor pane (see below).

Before composer bump:

After composer bump:

Note that composer dump is benefical on projects but should be avoided in libraries because it could accidently limit the versions in which can you use the library.

Also it might be a good idea to have a option on composer update to integrate composer bump functionality.

The plan was to use chrome-php with a headless chrome to generate the PDF.

Usually you would install chrome/chromium on a linux server via apt and just run chrome from the PATH with chrome.
Since i was on shared hosting i was not sure if this was possible since i was not allowed to run apt commands.
So i tried to use Puppeteer which ships a headless chrome executable and use just this directly.
I installed Puppeteer with npm locally and uploaded the chrome executable to the shared hosting.
Puppeteer will place the headless chrome in the .cache dir in your home directory, f.e.:

~/.cache/puppeteer/chrome/linux-113.0.5672.63/chrome-linux64/chrome

Upload:

scp -r ~/.cache/puppeteer/chrome/linux-113.0.5672.63/chrome-linux64 me@sharedhosting:/usr/home/test

I also created a nice little command line tool to create the pdf with chrome-php.
I used minicli which is a “minimalist, dependency-free framework for building CLI-centric PHP applications”.
So you can create cli commands fast and without all the clutter, exactly what i needed for this small test.
You can find the code on Github: https://github.com/ivoba/chrome-php-minicli
The command is here: https://github.com/ivoba/chrome-php-minicli/blob/main/command.php

Then i tried to generate the pdf:
CHROME_PATH="/usr/home/test/chrome" php command.php pdf url=https://ivo-bathke.name

However this failed because the server lacked required dependencies to run the chrome executable.
You can check this by running this command:

me@sharedhosting:/usr/home/test$ ldd chrome-linux64/chrome | grep not
libatk-1.0.so.0 => not found
libatk-bridge-2.0.so.0 => not found
libxkbcommon.so.0 => not found
libatspi.so.0 => not found
libXcomposite.so.1 => not found
libXrandr.so.2 => not found
libgbm.so.1 => not found

Ok, so it wont work with the uploaded chrome executable.
What a pity but still a finding.

In the end i contacted the support and fortunatly they were willing and able to install chromium via apt. Nice!

Eventually it worked with:
CHROME_PATH="chromium" php command.php pdf url=https://ivo-bathke.name

Pdf created :)

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().