Avec un utilisateur non connecté, un formulaire CVT me génère une erreur en spip 3.1 :
Fatal error: Call to undefined function sql_getfetsel()
mais pas en spip 3.0
J'utilise sql_getfetsel() dans _verifier.
J'ai débuggé get_included_files(), et je vois que ecrire/base/abstract_sql.php n'est pas inclus en 3.1, alors qu'il l'est en 3.0
Avec un utilisateur non connecté, un formulaire CVT me génère une erreur en spip 3.1 :
Fatal error: Call to undefined function sql_getfetsel()
mais pas en spip 3.0
J'utilise sql_getfetsel() dans _verifier.
J'ai débuggé get_included_files(), et je vois que ecrire/base/abstract_sql.php n'est pas inclus en 3.1, alors qu'il l'est en 3.0
Ça ressemble à ce vieux bug :
http://comments.gmane.org/gmane.comp.web.spip.devel/61656
Est ce qu'il faut repatcher de la même façon ?
Revert du commit précédent ... c'est à mettre dans les formulaires en ayant besoin
Donc ce serait "normal", et au développeur de l'inclure au besoin ?
Pourtant, en 3.0 abstract_sql est bien chargé.
Ce qui me parait logique, un CVT a quand même de grandes chances de manipuler des données et de faire appel à l'API.
Et ça peut éviter les mauvaises surprises (développer et tester un CVT en étant connecté, sans se rendre compte qu'il est pété pour les visiteurs non connectés).
> Revert du commit précédent ... c'est à mettre dans les formulaires en ayant besoin
Donc ce serait "normal", et au développeur de l'inclure au besoin ?
Pourtant, en 3.0 abstract_sql est bien chargé.
Ce qui me parait logique, un CVT a quand même de grandes chances de manipuler des données et de faire appel à l'API.
Et ça peut éviter les mauvaises surprises (développer et tester un CVT en étant connecté, sans se rendre compte qu'il est pété pour les visiteurs non connectés).
On pourrait charger automatiquement le fichier en prealable a l'appel à verifier() et traiter().
Mais attention, si on le fait dans balises/_formulaire.php cela chargera le fichier à chaque affichage de formulaire et donc de page, y compris en cache, et c'est mauvais en perfo. Les charger() des formulaires des pages publiques ne doivent jamais faire appel à la base de donnée sinon on créé une connexion SQL à chaque affichage de page. Les cas particuliers qui dérogent sont à traiter avec des pincettes.
On pourrait charger automatiquement le fichier en prealable a l'appel à verifier() et traiter().
Mais attention, si on le fait dans balises/_formulaire.php cela chargera le fichier à chaque affichage de formulaire et donc de page, y compris en cache, et c'est mauvais en perfo. Les charger() des formulaires des pages publiques ne doivent jamais faire appel à la base de donnée sinon on créé une connexion SQL à chaque affichage de page. Les cas particuliers qui dérogent sont à traiter avec des pincettes.
Avec un utilisateur non connecté, un formulaire CVT me génère une erreur en spip 3.1 :
Fatal error: Call to undefined function sql_getfetsel()
mais pas en spip 3.0
J'utilise sql_getfetsel() dans _verifier.
J'ai débuggé get_included_files(), et je vois que ecrire/base/abstract_sql.php n'est pas inclus en 3.1, alors qu'il l'est en 3.0
Ça ressemble à ce vieux bug :
http://comments.gmane.org/gmane.comp.web.spip.devel/61656
Est ce qu'il faut repatcher de la même façon ?
Je ne pense pas, cf : https://core.spip.net/projects/spip/repository/revisions/18783
Donc ce serait "normal", et au développeur de l'inclure au besoin ?
Pourtant, en 3.0 abstract_sql est bien chargé.
Ce qui me parait logique, un CVT a quand même de grandes chances de manipuler des données et de faire appel à l'API.
Et ça peut éviter les mauvaises surprises (développer et tester un CVT en étant connecté, sans se rendre compte qu'il est pété pour les visiteurs non connectés).
On pourrait charger automatiquement le fichier en prealable a l'appel à verifier() et traiter().
Mais attention, si on le fait dans balises/_formulaire.php cela chargera le fichier à chaque affichage de formulaire et donc de page, y compris en cache, et c'est mauvais en perfo. Les charger() des formulaires des pages publiques ne doivent jamais faire appel à la base de donnée sinon on créé une connexion SQL à chaque affichage de page. Les cas particuliers qui dérogent sont à traiter avec des pincettes.
Appliqué par commit r22330.
Statut changé à Fermé