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:
tobla schriebDa 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 schriebKommentiere 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 schriebVerstehe 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!
Das genaue Command welches ausgeführt wird, wird in Packages/Framework/TYPO3.Flow/Classes/Core/Booting/Scripts.php::buildSubprocessCommmand() nachsehen.
Bei mir in der Installation (Neos 1.0.1) finde ich den von Dir angegebenen Pfad nicht wieder.
Stattdessen habe ich bei mir:
/TYPO3-Neos/Packages/Framework/TYPO3.Flow/Classes/TYPO3/Flow/Core/Booting/Scripts.php
Ist das der Pfad den Du meinst?
Da sieht man auch, dass man das ini File in den Settings explizit setzen kann (über TYPO3.Flow.core.subRequestPhpIniPathAndFilename).
Sind damit diese Angaben in den /TYPO3-Neos/Configuration/Settings.yaml gemeint?
TYPO3:
Flow:
core:
# Path and filename of the PHP binary
# The constant PHP_BINDIR usually contains the path, but on Windows this doesn't work reliably
phpBinaryPathAndFilename: '/usr/bin/php'
# Set which php.ini file should be used for the CLI sub requests.
# If not set (that is value equals NULL) the php.ini file of the executing process (usually the web server's) is used.
# If set to a path and filename, the specified php.ini file is loaded.
# If set to boolean FALSE, Flow does not try to specify any php.ini file to the sub process.
subRequestPhpIniPathAndFilename: '/path/to/TYPO3-Neos/php-cli.ini'
Ich habe diese Angabe, aber Neos scheint sie nicht zu verwenden (oder sie werden von irgendwas wieder überschrieben).
Der Inhalt der in der Settings.yaml angegebenen php-cli.ini sieht übrigens 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