Fatal error: Class 'BaseForm' not found in … sfFormObject.class.php on line 20

Bonjour,

suite à une migration de structure de base nécessaire et les indications trouvées sur ce lien (http://stackoverflow.com/questions/9...only-one-table) je tombe sur l'erreur indiquée en titre.

L'erreur se produit dans la vue en appelant link_to avec un paramètre de confirmation :

Code:

---

<td><?php echo link_to('<img src="/.../supprimer.png"/>', 'action/delete?action_id='.$action->getActionId(), array('method' => 'delete', 'confirm' => '&Ecirc;tes-vous s&ucirc;r de vouloir supprimer cette action ?')) ?></td>

---

Bien entendu BaseForm.class.php existe bien dans /lib/form/.

J'ai effectué les commandes indiqués dans le lien ci-dessus :

Code:

---

1 2 3

php symfony doctrine:generate-migrations-diff php symfony doctrine:migrate php symfony doctrine:build --all-classes

---

Il y a eu de nombreuses erreurs de contraintes à la deuxième phase résolues en lançant la commande plusieurs fois (d'où d'autres erreurs sur les modifications déjà faites).

La dernière commande finie aussi par générer cette erreur (je ne l'avais pas aperçue au départ).

J'ai essayé de contourner le problème en générant le schéma depuis la base, en bon état, puis les modèles et les classes, le tout entre-coupé de cache:clear régulier.
Résultat : néant.

Recherches sur le web.
Résultat : néant (sauf les logs des sites ayant la même erreur).

Recherche dans la doc Symfony.
Résultat : néant.

Je soupçonne un problème de chemin mal configurés (bien que rien n'ai changé de ce point de vue) et ai cherché à trouver comment le configurer, sans résultat.


Quelqu'un aurait une solution ou à défaut une idée ?
Comment faire en sorte que la migration soit terminée, sauter cette erreur ou indiquer où trouver la classe ?

Merci.

peut etre que la génération par doctrine n'est pas complete.
pourquoi ne pas faire un doctrine:build-all?
Attention a bien mettre "No" lorsqu'il demande d'ecraser les données en bdd
(fait un backup de ta base on sait jamais)

Ps: j'utilise propel, donc j'pourrai pas t'aider plus que ca

Merci pour cette réponse.


Sans doute parce que la doc n'indique pas la présence de cette protection et que j'en ai assez de restaurer à la main table par table la base exportée par phpmyadmin sans tenir compte des contraintes (insertions avant que toutes les tables ne soient créées ...).

Je viens d'essayer et effectivement il m'averti ... et quitte immédiatement.

Résultat : néant.

Symfony : 10 - moi : 0


Manifestement le problème vient de l'ordre de chargement des classes.

La ligne ajoutant le lien semble faire appel à sfFormObject qui dérive de BaseForm avant que celui-ci ne soit chargé, donc plante, et si je force le chargement par un include, cela plante plus tard au chargement normal de BaseForm, que je ne peux/sais pas court-circuiter (class_exists() dans ce fichier ne détecte pas qu'elle existe !).


L'état actuel est :
- je ne change pas ma base et ne peux terminer le développement de l'appli,
- je change avec l'aide de Symfony et certaines pages plantent ; je pourrais éventuellement bidouiller cela pour que ça finisse par marcher, par exemple en écrivant mon bout de code de confirmation en cliquant sur le lien,
- je ne touche plus aux commandes symfony et modifie à la main les classes du modèle, jusqu'au prochain crash.


La conclusion est qu'avec n tentatives de migrations depuis 11h ce matin, symfony m'a en effet fait gagné du temps de développement : la prochaine fois, je choisirai un autre environnement de développement !

un truc que tu dois essayer (j'ai eu le probleme en travaillant en root), c'est de faire un chmod 777 sur tout ton dossier.

parce que si tu exécutes les commandes en root, tu donnes les droits qu'au root et ca empeche la lecture.

@hardy021, la seule commande root que je fais, c'est le nettoyage du cache parce que ce n'est pas autorisé autrement il me semble.


Bon finalement le problème venait en partie de moi : la base du logiciel que j'ai repris contenait une table "base". Je me suis emmêler dans les messages d'erreurs entre lib/form/baseForm.php et lib/form/doctrine/base/baseForm.php ; il y a de quoi, l'inclusion forcée du premier était suivie de l'erreur de chargement du suivant.

Néanmoins dès le début il y a eu une double erreur de Symfony :
- il s'est bien planté en tombant sur cette table, sans doute parce que "base" est un préfixe utilisé dans forms/, model/ et filters/
- rien ne permet clairement ensuite d'identifier le problème, de l'expliquer, de le résoudre. Je n'ai rien trouvé dans la doc de symfony qui liste les messages d'erreurs, les explique et leur donne une explication.


Finalement j'ai résolu le problème en supprimant les fichiers inutiles de ces dossiers à la main, sauf baseFormDoctrine et forms/baseForm.php bien sûr !