Neos Alpha5 Update - Flow requires the PHP setting "date.timezone" to be set.

Hallo Zusammen

Ich betreibe eine Ubuntu32Bit Vagrant Box zum Testen von Neos. Bisher hatte ich eine Neos Aplha4 installiert. Hat soweit alles geklappt.

Jetzt habe ich mit dem Composer auf Alpha 5 aktualisiert. Hat soweit auch alles geklappt.
Nur das Löschen des Cache klappt nicht. Flow schreit jetzt plötzlich "Flow requires the PHP setting "date.timezone" to be set.", obwohl date.timezone in der php.ini auf Europe/Berlin gesetzt ist, die Zeile einkommentiert ist und gemäss php_info auch diese php.ini Datei interpretiert wird. Bei Alpha4 gab es keine Probleme mit dem Cache löschen.

Hat jemand von euch eine Idee, woran es liegt? Langsam geht mir dieses date.timezone Zeug auf die Nerven. Wenn es Probleme bei einer Flow installation gibt, dann garantiert damit.

Ich helfe mir mal selbst.

Obwohl php info folgendes ausgibt:
Directive Local Value Master Value
date.default_latitude 31.7667 31.7667
date.default_longitude 35.2333 35.2333
date.sunrise_zenith 90.583333 90.583333
date.sunset_zenith 90.583333 90.583333
date.timezone Europe/Berlin Europe/Berlin

Werfen diese Zeilen in ./Packages/Framework/TYPO3.Flow/Classes/TYPO3/Flow/Core/Bootstrap.php einen exit:

                if (ini_get('date.timezone') === '') {
                      echo('Flow requires the PHP setting "date.timezone" to be set. (Error #1342087777)');
                      exit(1);
                }

Nach meiner Einschätzung kann es sich hier nur um einen Bug in der ini_get Funktion handeln.

Ist grundsätzlich zwar keine gute Idee, im Core was auszukommentieren, aber es ist die einzige Lösung, den Cache leeren zu können.

Ich bitte jeden, der das liest, dies NIEMALS auf einem Produktivsystem zu machen. Dies ist ein Hack und keine Lösung!

Hallo,

sorry war ein paar Tage unterwegs. Also diesen Check gibt es eigentlich schon ne ganze Weile in Flow und Neos, ich vermute dass du die php info im Web gemacht hast? Wahrscheinlich ist die timezone für PHP CLI nicht gesetzt. Auf Debian und abgeleiteten Distributionen gibt es meist getrennte php.ini Dateien. Check mal /etc/php5/cli/php.ini bzw. mach mal auf der command line ein
php -i | grep timezone

Viele Grüße
Christian

Tatsächlich. In etc/php5/cli/php.ini war die Zeitzone nicht gesetzt. Gut zu wissen, das man die Zeitzone für's cli einzeln setzen muss.
Danke.

Kommt wie gesagt aufs System an. Bei Debian und allen Derivaten ist das so. Bei anderen Distributionen mal so mal so.

Ich muss diesen Thread nochmal ausgraben, da ich gerade selbst über das Problem gestolpert bin - wenn auch bei TYPO3 Neos 1.0!

Vorweg: Ich nutze ein shared hosting Paket (mit Debian Squeeze), in dem man allerdings viele Freiheiten hat.

php -i | grep timezone

liefert bei mir allerdings bereits:

Default timezone => Europe/Berlin
date.timezone => Europe/Berlin => Europe/Berlin

Mein Ausgangspunkt war ebenfalls, dass ich nach dem Update auf den Development Master den Cache löschen wollte per

./flow flow:cache:flush --force

Dies bescherte mir zunächst den Hinweis

Flow requires the PHP setting "magic_quotes_gpc" set to Off. (Error #1224003190)

Daraufhin kam ich dahinter, dass ich eine eigene php-cli.ini nutzen müsse. Die nächste Schwierigkeit lag darin, TYPO3 Flow mitzuteilen, dass diese auch Verwendung finden soll. Die php-cli.ini im Wurzelverzeichnis der Neos-Installation anlegen hat nicht funktioniert, obwohl die Default Settings.yaml mit

subRequestPhpIniPathAndFilename: NULL

aktiv war.

Die folgenden Einstellungen der eigenen Configuration/Settings.yaml berücksichtigten für den Cache flush ebenfalls nicht die nötigen selbst abgelegten Einstellungen in der php-cli.ini:

TYPO3:
  Flow:
    core:
      phpBinaryPathAndFilename: '/usr/bin/php'
      subRequestPhpIniPathAndFilename: '/pfad/zu/TYPO3-Neos/php-cli.ini'

Meine php-cli.ini sieht so aus:

date.timezone = "Europe/Berlin"
memory_limit = 256M             ; default ist 128M
xdebug.max_nesting_level = 500  ; Einkommentieren sofern xdebug verwendet wird
detect_unicode = Off
magic_quotes_gpc = Off

Ich habe mir schlussendlich damit beholfen, dass ich die Shebang-Zeile der Datei flow angepasst habe:

#!/usr/bin/php -c /Pfad/zu/TYPO3-Neos/php-cli.ini

Damit erhalte ich nun NICHT mehr den oben erwähnten Fehler

Flow requires the PHP setting "magic_quotes_gpc" set to Off. (Error #1224003190)

...also scheint meine php-cli.ini nun endlich Gehör bei Flow zu finden!

Allerdings bekomme ich stattdessen nun den Fehler

Flow requires the PHP setting "date.timezone" to be set. (Error #1342087777)

Wenn ich in der Kommandozeile allerdings ein Testscript starte per

php -c php-cli.ini test.php

mit dem Inhalt von test.php

[...]
echo ini_get('date.timezone');
[...]

erhalte ich korrekterweise

Europe/Berlin

Also ist meine php-cli.ini korrekt.

Die Frage ist nur, warum die Einstellung von ini_get('date.timezone') nicht korrekt im Skript

TYPO3-Neos/Packages/Framework/TYPO3.Flow/Classes/TYPO3/Flow/Core/Bootstrap.php

landet, denn von dort kommt die Fehlermeldung beim leeren des Caches.

Nachtrag: Wenn ich als Workaround für date.timezone direkt in die Zeile vor der Abfrage dies einfüge

ini_set('date.timezone',date_default_timezone_get());

erhalte ich keine Fehlermeldung bzgl. einer fehlenden date.timezone, aber dafür wieder die Fehlermeldung

Flow requires the PHP setting "magic_quotes_gpc" set to Off. (Error #1224003190)

Also bleibt die Frage, warum die Einstellungen aus der eigenen php-cli.ini nicht beim Skript ankommen!

Noch ein Nachtrag:

Wenn man die Shebang-Zeile des Skriptes flow im TYPO3-Neos Verzeichnis abändert in

#!/usr/bin/php -d magic_quotes_gpc=0 -d date.timezone="Europe/Berlin"

gelingt wohl der Cache flush - aber es kommt auch eine Fehlermeldung von PHP:

user@machine:~/path/to/TYPO3-Neos$./flow flow:cache:flush --force
PHP: syntax error, unexpected '=' in Unknown on line 7
Force-flushed caches for "Development" context.

Und wenn du deine php.ini im etc ablegst, wo auch meine war: etc/php5/cli/php.ini?

Im shared hosting habe ich auf diese zentralen Verzeichnisse auf dem Server keinen Zugriff.

Für PHP via FastCGI haben wir die M-öglichkeit, eine eigene php.ini in das fastcgi-bin zu legen, die dann von PHP mit ausgewertet wird. Aber das ist ja nur der Zugriff auf PHP-Skripte über den Webserver.

Für PHP-CLI habe ich bisher noch keinen Hinweis bekommen, wo ich in meinem Paket eine eigene php-cli.ini ablegen könnte, sodass sie auch Berücksichtigung finden würde.

php -i

sollte dir auch Info über den Pfad der ini Datei ausgeben.

Ruf doch innerhalb vom Bootstrap.php mal die Pfad Info ab. Dann siehst du, auf welche ini Datei er zugreift.

Was den Cache selbst angeht, so hatte ich schon das Problem, das sich der Cache wie verklemmt. Ich hab dann jeweils einfach die Cache Files im Web Directory von Hand gelöscht. Aber pass auf, das du die Ordnerstruktur beibehältst.

In der Kommandozeile geprüft:

user@machine:~$ which php
/usr/bin/php

und

user@machine:~$ php -i | grep ini
Configuration File (php.ini) Path => /etc/php5/cli
Loaded Configuration File => /etc/php5/cli/php.ini
Scan this dir for additional .ini files => /etc/php5/cli/conf.d

Da du bei Flow ein anderes Verhalten feststellst als in der Konsole, wäre es gut die Information wie von mir beschrieben innerhalb von Bootstrap abzurufen. Nur so findest du heraus, was und woher Flow seine Konfiguration bekommt.

Wo PHP(-CLI) die ini-Dateien erwartet ist ja hier beschrieben:
http://www.php.net/manual/de/configuration.file.php

Der Zusammenhang ist aber stark von den Installationsparametern auf dem Server abhängig- und sich dort in den verschiedenen Abhängigkeiten als Außenstehender zurecht zu finden ist schwierig.

Übrigens gibt es im 1.0er Neos noch dieses grundsätzliche Problem bzgl. der Prüfung auf date.timezone:

http://forge.typo3.org/issues/54593

tobla schrieb

Da du bei Flow ein anderes Verhalten feststellst als in der Konsole, wäre es gut die Information wie von mir beschrieben innerhalb von Bootstrap abzurufen. Nur so findest du heraus, was und woher Flow seine Konfiguration bekommt.

Ja, das ist ein guter Gedanke.

Direkt abgegriffen per echo phpinfo(); innerhalb der Bootstrap.php:

Configuration File (php.ini) Path => /etc/php5/cli
Loaded Configuration File => /etc/php5/cli/php.ini
Scan this dir for additional .ini files => /etc/php5/cli/conf.d

Da sehe ich keinen Unterschied zwischen innerhalb und außerhalb.

Kommentiere diese date.timezone Abfrage doch temporär aus, bis das Team es gefixt hat.

Ich verstehe ehrlich gesagt auch nicht ganz, warum die Entwickler einen Exit werfen wollen, wenn diese Konfiguration nicht vorhanden ist und nicht auf einen sinnvollen Default Value zurückgreifen.

Verstehe ich das richtig: Obwohl du beim Aufruf von Flow dein eigenes ini als Parameter mitgibst, nimmt er das Standardfile? Wenn dem wirklich so ist, übersteuert Flow wohl den Parameter. In dem Fall kann uns wohl nur kitsunet weiterhelfen.

tobla schrieb

Kommentiere diese date.timezone Abfrage doch temporär aus, bis das Team es gefixt hat.

Bei den magic_quotes_gpc würde das Problem ebenfalls bestehen und ich weiß ja nicht, ob die benötigten Einstellungen tatsächlich bei den beteiligten Skripten landen. Auskommentieren ist daher nicht wirklich die Lösung.

tobla schrieb

Verstehe ich das richtig: Obwohl du beim Aufruf von Flow dein eigenes ini als Parameter mitgibst, nimmt er das Standardfile? Wenn dem wirklich so ist, übersteuert Flow wohl den Parameter. In dem Fall kann uns wohl nur kitsunet weiterhelfen.

Ja, so sieht es aus.

Wenn ich allerdings date.timezone und magic_quotes_gpc per -d mitgebe, dann läuft der flush Befehl durch (wenn auch mit dem oben geposteten Fehler).

Also Flow macht quasi einen weiteren Aufruf von sich selbst mit dem compile command, dabei wird die von php gemeldetete php.ini benutzt um den neuen Aufruf zu machen. Das genaue Command welches ausgeführt wird, wird in Packages/Framework/TYPO3.Flow/Classes/Core/Booting/Scripts.php::buildSubprocessCommmand() nachsehen. Da sieht man auch, dass man das ini File in den Settings explizit setzen kann (über TYPO3.Flow.core.subRequestPhpIniPathAndFilename).
Damit sollte es gehen 🙂

Viele Grüße und frohes Neues!