Skip to content

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

Create php repository and want to quickly develop and test it everywhere? Add a fanzy shell script to it!

I have to maintain a big bunch of repositories with different languages and different language versions.

After some iterations, I came up with a simple idea by using docker for it. To ease up things for any kind of users who have to deal with this code (even qa), the last iteration is to add a "" script into the repository.

Following an example script for a php repository.
Given is, that the script is located in <project_root>/bin.
Given is, that the docker file exists in <project_root>/data/docker.

# Starts a fitting container and creates image if needed.
# @todo
# @author stev leibelt <>
# @since 2018-05-09

PATH_OF_THIS_SCRIPT=$(cd $(dirname "$0"); pwd)

if ! (docker image ls | grep -q "${DOCKER_IMAGE_NAME}\s\+${DOCKER_IMAGE_TAG}")
    PATH_TO_THE_DOCKER_SOURCE=$(realpath ${PATH_OF_THIS_SCRIPT}/../data/docker)
    echo ":: We have to build the docker container first."
    echo ":: Please do the following steps first."
    #this is usefull since you have to copy some ssh keys to a path
    # or configure some files.

    read -p ":: Hit <ENTER> to continue."                                                                                                                       


docker container run --mount type=bind,source="${PATH_OF_THIS_SCRIPT}"/..,target=/application -it ${DOCKER_IMAGE_NAME}:${DOCKER_IMAGE_TAG} /bin/ash

And thats it. If the image is not found on the host, we have to setup things and build the image. Afterwards we start the container and mount the repository code into /applicationof the container.

Translate to de es fr it pt ja

Hint, never ever name a column "database_name" or "table_name" when you are using PHP's Propel

Defining a column name inside a table definition "database_name" or "table_name" will result in duplicated generated constant definition which will be an evil fail you have to debug for some minutes.

Super hint! Name them "the_database_name" and "the_table_name" :-D.

Translate to de es fr it pt ja