Skip to content

Zabbix: Required parameter $sql_parts follows optional parameter $table_alias

We are running our monitoring solution zabbix on an arch linux system. Arch linux tends to be "up to date" since it philosophie is "patch current code base, not legacy".

I've updated the monitoring system and with that, the php version jumped from 7.4.x to 8.0.x.

After that, a lot of "widgets" (boxes) in the zabbix frontend displayed me a lot of the following error.

Required parameter $sql_parts follows optional parameter $table_alias [zabbix.php:22 → require_once() → ZBase->run() → CSettingsHelper::getGlobal() → CSettingsHelper::loadParams() → API::getApiService() → CRegistryFactory->getObject() → CApiService->__construct() → CApiService->pk() → CApiService->getTableSchema() → CAutoloader->loadClass() → require() in include/classes/core/CAutoloader.php:77]

I've researched it and found that the error exists in the DB.php class. I've opened the issue Ticket ZBX-18984 and created the pull request 39 on the github source code. Hopefully, this fix will make it quickly into the code. I've added a git patch file to the issue. You can download and apply it on your system.

Translate to de es fr it pt ja

Using thecodingmachine docker images with podman

I wanted to quickly develop something. I thought this is the perfect timing to migrate mentally from the insecure and almost dead docker to the alive and secure podman.

I went to the page of thecodingmachine and tried it with the following one-liner:

podman run -p 80:80 --rm --name php-bazzline -v "$PWD":/var/www/html thecodingmachine/php:7.4-v3-apache

Sadly nothing is working so I've created a feature request asking for podman support.

My current workaround is following

sudo -c "echo '<username>:100000:65536' >> /etc/subuid"
sudo -c "echo '<username>:100000:65536' >> /etc/subgid"
sudo reboot

And adapt the start up as following to prevent port issues (you are not allowed - by default - to use ports below 1024).

podman run -p 8080:80 --rm --name php-bazzline -v "$PWD":/var/www/html thecodingmachine/php:7.4-v3-apache

Thats it.

Translate to de es fr it pt ja

Running Contao 3.x version and upgrading from PHP 5.x to PHP 7 results in a 500 Status?

I had the joy to debug a not working contao system line by line.

Why line by line? Because there was no entry in any logs, even with "log all motherfucker"-php.ini values on.

After parsing the lines, I ended up into this error message.

Fatal error: Cannot use 'String' as class name as it is reserved in ... system/modules/core/library/Contao/String.php on line 28

Well, nice to know the error but where was this triggered? So another round with joy and I ended up with an extension, of course installed "by hand" which means not possible to update by the contao updater and this lovely line.


After I've changed that line to the following line, all the gizmos where working again.


So, what should you do when you where faced with a 500 Apache Status Code after a contao installation moved from an PHP 5.x runtime environment to a PHP 7.x runtime environment?

cd <project root> grep -ir "import('String');" *

Replace >>import('String');<< with >>import('StringUtil');<< and that is it.

But all would be better if you are not installing extensions by hand.

Translate to de es fr it pt ja

Zend Framework Kickstart or quick start script available

I was so bored setting up a zend framework application after another that I've created a simple script.

Sharing is caring, so you can find it on github with the lovely repository name phpzendframework_kickstarter.

This repository provides you two scripts to quickly create a new application from scratch (like a breeze and blazing fast within seconds ;-)).

git clone
bash php_zend_framework_kickstarter/create_application /path/to/the/application

See it working and that is it. All mandatory parts are a bash.

Translate to de es fr it pt ja