#hoopla

After migrating an extension of the dd_googlesitemap from T3 4.5 to 6.2, I noticed a very strange behavior which occurred after every cache clear in the install tool. Every call of index.php?eID=dd_googlesitemap or a custom sitemap index.php?eID=dd_googlesitemap&sitemap=customsitemap resulted in the following error:

#1: PHP Warning: Invalid argument supplied for foreach() in [...]/typo3_src-6.2.3/typo3/sysext/core/Classes/Utility/RootlineUtility.php line 269


The error is misleading, because it seems to have nothing to do with the skipRootlineCheck option the extension provides. The error simply disappears when accessing the frontpage after the cache clear, just before accessing the sitemap.

I was about to check out a remote repository when I got the following error:

git clone https://xyz git-repo/
Cloning into 'git-repo'...
Username for 'https://xyz': xyz
Password for 'https://xyz':
remote: Counting objects: 138872, done.
remote: Compressing objects: 100% (35137/35137), done.
Receiving objects: 100% (138872/138872), 24.25 MiB | 10.10 MiB/s, done.
remote: Total 138872 (delta 67002), reused 137198 (delta 66062)
Resolving deltas: 100% (67002/67002), done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.


In this case, it was due to a missing master branch. I needed to add a branch name to the checkout command with -b and the checkout worked as expected.

In our standard webserver configuration, we use Apache + PHP-FPM on Ubuntu. Apache runs with a different user and a different group than PHP. This implies that all files that are to be readable by Apache need to be world-readable. PHP creates files that are not world-readable by default.

I intended to set the creation mask within php.ini or better on a per-pool basis. Sadly, both seems not to be possible.

I finally managed to change this behavior by changing umask in the start script /etc/init.d/php5-fpm from 0007 to 0000.

In our new web server config, there is a separate admin user and webserver user, which share the same group. Whenever a file or directory is to be writable by the web server, it has to be writable by the group. This does not work with Drupal: It only checks for the user, so the hosting directory and all hosting files need to belong to the user which runs the corresponding PHP instance.
Furthermore, we use a chroot for PHP with a local tmp directory. If the installation is moved from another server, this needs to be configured within Drupal as well. The temp folder can be changed within /admin/config/media/file-system.

After an update the frontend refused to work:

Scanner besetzt!
Nochmals probieren?

Kein Scanner gefunden.
Ist der Scanner frei?
Überprüfen Sie, ob der Scanner angeschlossen ist, und vom Programm scanimage -L gefunden wird.

Running scanimage -L on the command line with the Apache user gave the following error:

$ scanimage -L

No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate). Please read the documentation
which came with this software (README, FAQ, manpages).

Since I'm using an HP multifunction device, I found the following useful command:

$ hp-check -r

Beside some minor warnings, it told me that the Apache user was not in the group "lp". After adding the user to this group and restarting Apache, the Apache user could run scanimage -L again with the output of the scanner and PHPSane also ran again.