Doctrine: WHERE IN with array of integers

Since I stumbled across this the other day, here’s how you build an SQL query with a WHERE IN condition for an array of integers.

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.

Continue reading “Doctrine: WHERE IN with array of integers”

Typed Arrays with PHPStan types

When dealing with legacy data, you often encounter arrays or associative arrays. These arrays are untyped, which PHPStan, of course, does not accept, resulting in numerous PHPStan errors.

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++;
}Code language: PHP (php)

A typical error could be:

Parameter #1 $number of method TestClass::funcWithInt expects int, mixed given.Code language: PHP (php)
Continue reading “Typed Arrays with PHPStan types”

Deploy local build with Deployer7


Deployer is a great tool to deploy your PHP Project.

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.

Continue reading “Deploy local build with Deployer7”

Invalid table or database name mysql.sock


In a development Docker setup, I needed to upgrade the MySQL database from version 5.6 to version 8. The data was stored as a Docker volume in a data directory. After the update, I encountered the following error:

my_db.mysql      | 2024-08-16T09:40:21.463770Z 2 [ERROR] [MY-010520] [Server] Invalid (old?) table or database name 'mysql.sock'
my_db.mysql | 2024-08-16T09:40:21.468287Z 2 [ERROR] [MY-010784] [Server] Failed to open dir /var/lib/mysql/mysql.sock

Apparently, MySQL 8 treats every file or directory in the data directory as a database table, whereas in the previous version, MySQL 5, only directories were recognized as database tables.

As the the changelog of MySql 8 states:

Because the data dictionary provides information about database objects, the server no longer checks directory names in the data directory to find databases. Consequently, the --ignore-db-dir option and ignore_db_dirs system variable are extraneous and have been removed. Update system configurations and application programs accordingly.

As a result, all files in the data directory volume, in addition to the directories, are mistakenly recognized as database tables–for example, the mysql.sock file, which is created by Docker.

Continue reading “Invalid table or database name mysql.sock”

Symfony integration tests custom header is missing

I am writing an integration test in Symfony with a request that includes custom headers. However, the request fails because the custom header is apparently missing.
What happened was I forgot to add an HTTP prefix to the custom header.

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']);Code language: PHP (php)

And this will work:

static::$client->request('GET', '/ping', [], [], ['HTTP_X-Custom-Header' => 'custom']);Code language: PHP (php)
Continue reading “Symfony integration tests custom header is missing”

Monorepo with NPM workspaces

I recently converted a project into a Monorepo.
I had a cli part and an Astro StaticSiteGenerator part.
At some point I felt like these parts would be entangled too much so I decided to separate them. Since they were still related they should stay in one repo but have their own dependencies and separate processes. I still could have kept this in one Astro project with a cli folder but so it feels cleaner structured.

I chose NPM as my package manager since it comes bundled with node and so I decided to try out NPM workspaces as my MonoRepo approach.

So here are my takeaways

Continue reading “Monorepo with NPM workspaces”

Astro component for DarkMode Switcher for PicoCSS

I am currently evaluating PicoCss V2 in Astro project. PicoCss is a CSS / SCSS framework I used for some of my projects because it is small and brings sufficient styling for most HTML Elements. It has integrated light and dark mode, but no theme switcher.
So i was looking for one and found this one for Pico V1:
https://github.com/RWDevelopment/theme_switch

Continue reading “Astro component for DarkMode Switcher for PicoCSS”

Obfuscate Web Component

Typically, when integrating emails into websites, I obfuscate the email address to prevent spam bots from collecting them. For React, there were already components that handled this task; however, without React, I couldn’t find a suitable solution.

Therefore, I created a web component: obfuscate-wc that now provides an HTML element capable of obfuscating your email (and some other contact data).

 <obfuscate-link id="obfuscate" email="aXZvQGxvY2FsLmRldg==">custom link</obfuscate-link>Code language: HTML, XML (xml)
Continue reading “Obfuscate Web Component”

Composer bump

Do you miss that the version numbers of your PHP dependencies are automatically updated in the composer.json file after a composer update?
Just like npm or yarn are updating the version numbers in the package.json file.

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.

Continue reading “Composer bump”

Testing PDF creation with headless chrome and PHP

I had the task the other day to use a headless chrome to generate PDF files from websites in a PHP app.

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

Continue reading “Testing PDF creation with headless chrome and PHP”