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.

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! :)

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

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 :)

However from v3 the TestLogger was removed, so that the psr/log package would focus solely on the Interface.

If you used the TestLogger in your project and you or some of your dependencies upgraded psr/log to >= v3 you most likely saw this error:

Class "Psr\Log\Test\TestLogger" not found

Thanks to the community there is already a replacement for the TestLogger:
So just install the https://github.com/colinodell/psr-testlogger and replace the definition:

Psr\Log\Test\TestLogger:

with

ColinODell\PsrTestLogger\TestLogger:

in your code and you are good to go.

One file libs for the win :)

Disclaimer: No legal advice, just a little experience report.

If you sell digital things (services, digital goods etc.) to EU countries, you might have to calculate the VAT at the rate of the customer’s country (and even pay it there afterwards).
The latter is even the more inconvenient part, but at least the first part can be done quite easily with good old PHP.

Originally released as a Laravel plugin (or whatever it’s called in their bubble..), there is this very handy library that does the whole complex calculation starting from the seller’s country:

https://github.com/driesvints/vat-calculator

Even more interesting for my purposes was this fork here:

https://github.com/spaze/vat-calculator/

Works on the one hand as a complete standalone version, and still includes updates and is actually also rather a further development than a fork :thuink:
With this then the VAT can be calculated in a few easy calls and life is exceptionally easy.
Not only the country of the customer is taken into account, but also the postal code, because in Germany alone there are several different VAT rates, depending on the island you happen to find yourself on.

// Easy to use!
use Spaze\VatCalculator\VatCalculator;

$vatRates = new VatRates();
$vatCalculator = new VatCalculator($vatRates);
$vatCalculator->calculate(71.00, 'DE' /* $countryCode */, '41352' /* $postalCode or null */,  true /* Whether the customer you're calculating the VAT for is a company */);
$vatCalculator->getTaxRateForLocation('NL');
// Check validity of a VAT number
$vatCalculator->isValidVatNumber('NL123456789B01');

With the appropriate VAT identification number, the annoyance of the collection is then also accordingly omitted.

So nice one, definitely saved me a lot of worries. Github-starred – Cheers guys!

This is how it could be done with PHP:

header("Content-type: text/xml; charset=utf-8");

//create your XML document, using the namespaces
$urlset = new SimpleXMLElement('<?xml version="1.0" encoding="UTF-8"?><urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns:image="http://www.google.com/schemas/sitemap-image/1.1" /><!--?xml version="1.0" encoding="UTF-8"?-->');

//iterate over your sites pages or whatever you like

foreach (getMyPagesOrWhatEver() as $item):

    //add the page URL to the XML urlset
    $url = $urlset->addChild('url');
    $url->addChild('loc', $item->URL );
    $url->addChild('lastmod', $item->LASTMOD );
    $url->addChild('changefreq', 'daily');  //weekly etc.
    $url->addChild('priority', '1.0');

    //add an image
    if ( $item->IMAGE ):
        $image = $url->addChild('image:image', null, 'http://www.google.com/schemas/sitemap-image/1.1');
        $image->addChild('image:loc',$item->IMAGE->URL, 'http://www.google.com/schemas/sitemap-image/1.1');
        $image->addChild('image:caption',$item->IMAGE->ALT_OR_TITLE , 'http://www.google.com/schemas/sitemap-image/1.1');
    endif;

endforeach;

//add whitespaces to xml output (optional, of course)
$dom = new DomDocument();
$dom->loadXML($urlset->asXML());
$dom->formatOutput = true;
//output xml

echo $dom->saveXML();

That’s about it.

I found it kind of tricky to figure out how to use googles namespaces when working with SimpleXML, so hopefully this might help someone :)

I’m running OSX 10.7.3 with macports which usually does the job, but  Google’s V8 Javascript Engine is not available as a port yet.

So… homebrew to the rescue:

installed it:

/usr/bin/ruby -e "$(/usr/bin/curl -fsSL https://raw.github.com/gist/323731)"

and installed v8

brew install v8

wait, this seems too easy.

PECL installed some beta version of the PHP extension.

sudo pecl install channel://pecl.php.net/v8js-0.1.2

added

extension=v8js.so

to the php.ini file.

und bitteschön:

$v8 = new V8Js();
var_dump($v8->executeString("

//hey i'm Javascript Code

//INSIDE PHP !

//wow.
var hello = 'Hallo';

function helloWorld( string ){
return hello + ' ' + string;
}

helloWorld('World');

"));

Such things might come in handy one day, you know.

//example array
$array = array('a' => array(array(243,453,435,232)));

foreach ($array['a'] as &$value) {
         $value[3] = $newvalue;
}

This works, but now the $value var is in the array by reference which can lateron lead to:
Notice: Array to string conversion
EDIT:
see below in the comments for when…

This works better:

Using reference, array_walk und lambda functions works:

array_walk($array[$key], function(&$value, $key, $newvalue) {
                                   $value[3] = $newvalue;
                          },$newvalue);
//works

or that (thanks lars):

foreach ($array['a'] as $k => $value) {
         $array['a'][$k][3] = $newvalue;
}