Den upgrade haben die Entwickler von symfony schon gut durchdacht und sollte dank der guten Anleitung auch ohne Probleme klappen.
Vorneweg: symfony 1.3 und 1.4 haben den selben Funktionsumfang und unterscheiden sich i.G. nur dadurch, dass 1.3 ein Abwärtskompatibilätslayer hat.
Daher sollte man erst auf 1.3 upgraden und -wenn man mutig ist- dann auf 1.4.
Ein paar Fallstricke gabs dennoch, daher hier mal mein Erfahrungsbericht:
Also symfony 1.3 geholt:
svn export http://svn.symfony-project.com/branches/1.3 symfony1.3
und wie in der Anleitung angegeben den symfony core in /lib/vendor/symfony upgegradet.
Dabei am besten das alte symfony vorher löschen und dann das neue rein kopieren.
cd lib/vendor/symfony rm -r * mv /pathbla/symfony1.3/* /pathhinda/lib/vendor/symfony
Kopiert man es einfach drüber, bekommt man solche Fehler nachher in der Konsole:
“The task named “propel:data-dump” in “sfPropelDumpDataTask” task is already registered”
Dann die Schritte ausgeführt wie in der Anleitung beschrieben:
php symfony project:upgrade1.3 php symfony propel:build --all-classes php symfony cache:clear
Da das Projekt hier noch relativ frisch ist, bin ich mal mutig und upgrade auf 1.4 DEV:
Den neusten stand geholt:
svn export http://svn.symfony-project.com/tags/RELEASE_1_4_0_RC2/ symfony1.4.dev
und wie oben rüberkopiert.
Hierbei hatte ich vergessen den empfohlenen Task:
php symfony project:validate
vorher auszuführen der einem alle veralteten Elemente aufzeigt.
Naja dann muss man sich halt durch die Fehlermeldungen hangeln:
Wie z.B. in der ProjectConfiguration.class.php noch das veraltete Plugin rausnehmen:
$this->enableAllPluginsExcept(array('sfDoctrinePlugin', 'sfCompat10Plugin'));
nach
$this->enableAllPluginsExcept(array('sfDoctrinePlugin'));
Dann bekam ich noch folgendes zu sehen:
Unable to load “FormHelper.php” helper
Mmm, einfach mal Cache leeren und dann ging auch das.
Mal sehen was da noch so auftaucht.
Schöner Erfahrungsbericht!
Ich würde in der ProjectConfiguration Klasse noch auf sfProjectConfiguration::enablePlugins() umstellen, damit nicht automatisch alle Plugins eingeschaltet werden. Ist zwar mehr Aufwand immer jedes Plugin einzeln einzuschalten, aber auch um einiges sicherer. :)
Was hast du Erfahrungen mit Deinen Forms und dem Routing gemacht? Ich befürchte, dass einem ein Projekt doch ganz schön um die Ohren fliegt, wenn man viel custom-stuff nutzt…
@denderello
yop kann/sollte man so machen
@joshi
das project was ich upgegradet hab war w.g. noch relativ frisch und hatte nur ein paar filesystem operations und hat propel nur mit raw queries benutzt (MSSQL is schuld).
forms waren gar nicht dabei, kann ich gar nix zu sagen.
routing war auch noch nicht so viel, aber das funtionierte ;)
die aufwändigeren projekte warten noch auf den upgrade.
ich muss auch erstmal die ganzen server upgraden, da symfony 1.4. ja >= 5.2.4 ist
und die ganzen debian etch teile hier bei 5.2.0 stehen geblieben sind…
IIck… immer noch besser als das “klassische” PHP 5.0.x in der Etch Standarddistri :D
ha die meinte ich ;)
So, hab’ bei einem kleineren Ding auch mal die Migration gewagt. Exzessives Admin-Generator-Geschrummel mit custom Theme (erster böser Konflikt), sfDoctrineGuardPlugin (zweiter böser Konflikt, auf alle Fälle Jonathans 1.3/4 branch aus’m SVN benutzen!), ein paar Dinge an Doctrine 1.1 und sfForms (1.2 kann nun auch Relationships via sfDoctrineForm speichern, ohne das man das nochmal explizit machen muss, juchu ^^) – das war eigentlich alles. Insgesamt ca. 3 Stunden Aufwand, davon 2,75 Fehlersuche im Cache. Alles in allem würde ich das als Erfolg verbuchen… aber Größeres möchte ich lieber nicht umbiegen.