filter_var( $email, FILTER_VALIDATE_EMAIL );

seit längerem hatte ich erfolglos versucht den Ouput der Symfony Tasks auf meinem Mac farbig dargestellt zu bekommen.

Nach Experimenten mit verschiedenen Color Themes und AddOns für die Terminal.app und / oder iTerm hatte ich dann die tollsten Ansi Farben, Prompts und VI-Themes.

Nur die Symfony Tasks waren immer noch einfarbig.

RTFM….

In dem Fall sogar noch einfacher:
check_configuration.php einfach mal laufen lassen:

php lib/vendor/symfony/data/bin/check_configuration.php

[[WARNING]] The posix_isatty() is available: FAILED  
*** 
Install and enable the php_posix extension 
(used to colorized the CLI output) 
***

wie gesagt: d’oh.

via macports schnell installiert:

sudo port install php5-posix

und farbiger Output bei allen Symfony Tasks. Und das unter Snow Leopard.
Vielleicht hat das ja noch jemand übersehen und erspart sich hiermit die lange Suche.

//wenn "local" in der Domain vorkommt, sind wir lokal unterwegs

if(strpos($_SERVER['HTTP_HOST'], 'local.') !== false ){
  define('DB_NAME', 'mydbname');
  define('DB_USER', 'mydbuser');
  define('DB_PASSWORD', 'mydbpassword');
  define('DB_HOST', 'mydbhost');
}

//ansonsten auf dem Produktiv Server

else{ 
  define('DB_NAME', 'mylivedbname');
  define('DB_USER', 'mylivedbuser');
  define('DB_PASSWORD', 'mylivedbpassword');
  define('DB_HOST', 'mylivedbhost');
  //wenn man möchte, kann man hier noch die FTP Daten eintragen 
  //und damit "one-click" die automatischen Updates laufen lassen
  define('FTP_HOST', 'myFTPhost');
  define('FTP_USER', 'myFTPuser');
  define('FTP_PASS', 'myFTPpassword');
}

//damit die ganze Kiste dann auch ohne Anpassungen funktioniert,
//muss man hier aber noch die WP_SITEURL und WP_HOME aus der DB überschreiben
//(und zB. dynamisch halten oder eben in die if Abfrage mit reinpacken)

define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] );
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST']);

#wipe old version of build db
mysql -uUSER -pPW drop build-db

#wipe the build workspace
rm -rf ./build-workspace

#checkout the sourcecode
git clone git@my-domain.com:my-repository ./build-workspace

cd build-workspace

#(re)configure database for build server
php ./symfony configure:database "mysql:host=build-db-server;dbname=build-server-sql-user"

#(re)build db
php ./symfony doctrine:build-db

der Einfachkeit halber liegt der zu migrierende sql dump schon im repository.
Könnte man natürlich auch jetzt von remote holen.

#import some test data
mysql -uUSER -pPW --force database_name < data/sql/some_data_to_migrate.sql

hier sollte keine Handarbeit mehr nötig sein,
da man ja alle DB Änderungen per doctrine migrations gemacht hat.
Im Gegensatz zu schema Änderungen bleibt man so abwärtskompatibel zu Vorgängerversionen.

#migrate the test data / db if necessary
php ./symfony doctrine:migrate

zum guten Schluss alles testen

#run test, save results as xml
php ./symfony test:all -xml=path/to/results.xml

Es lohnt sich in mehrfacher Hinsicht wirklich das komplette Projekt inkl. DB automatisiert von 0 installierbar zu machen.
Auch wenn es vielleicht erstmal nur auf ein paar Instanzen laufen soll.

Man kann erstens bei verteiltem Arbeiten schnell mal eine weitere Arbeitskopie auf einem anderen Rechner erstellen.

Zweitens kann man relativ einfach ein continuous integration setup auf die Beine stellen und sofort ruhiger schlafen ;)

Außerdem kann man ständig die Migration von aktuellen Live Daten, oder einer Vorgängerversion in die Entwicklungsversion testen.
“Continuous Migration” ;)