Ou bien ton inscription se fait par un formulaire spécifique, tu peux y
mettre les 2 lignes de code qui font loger l'auteur dans le traiter() de
ton inscription.
Non, ça utilise le formulaire fourni par SPIP, modifié ou pas.
Ou bien ton inscription se fait par le formulaire standard qui envoie un
mot de passe par mail et je vois pas le principe de le loger sans rien
vérifier...
Comme déjà dit, je ne vois pas le rapport entre l'envoi du mot de passe et le fait de se connecter directement.
Tout comme on peut vouloir confirmer dans les deux cas, on peut vouloir connecter dans les deux cas : c'est sans rapport avec le mot de passe (donc aussi valable pour le formulaire dist).
Le lien-jeton de confirmation n'a aucun rapport avec le mot de passe (d'ailleurs il connecte justement la personne SANS taper le mot de passe) : il sert à confirmer son email, pas son mot de passe.
Confirmer que l'email existe c'est un choix qu'on peut vouloir faire (c'est le choix par défaut) que ce soit SPIP qui génère le mot de passe OU que ce soit la personne qui le choisit à l'inscription. Dans les deux cas on peut vouloir confirmer l'email avant que son compte ne s'active vraiment.
Et parfois inversement, en ayant conscience de ce qu'on fait, on veut passer outre la confirmation de l'email, parce qu'on estime qu'on aura pas ou très peu de merde et que notre base sera qualitative de toute façon. Dans ce cas on décide de connecter la personne directement.
Moi je ne vois pas en quoi ce serait à chacun de trouver le bon endroit pour le faire, sachant en plus qu'il n'y a pas de pipeline de fin d'inscription. Un formulaire CVT ce n'est pas une API : c'est une interface qui appelle ensuite possiblement des fonctions communes dans le traitement (fonctions qui peuvent être utilisées par d'autres types d'interfaces que les formulaires web).
On peut faire l'inscription depuis le formulaire fourni (ce que je fais parfois), ou depuis un autre formulaire perso (ce que je fais parfois aussi) : dans les deux cas on utilise action/inscrire_auteur, et c'est *ça* qui est commun. Donc c'est là que doit se faire la connexion d'après moi, et non pas par-ci par-là disséminé dans des composants d'interface web.
je vois pas tant la généricité que ça
Ce qui est générique, c'est de le faire dans une fonction commune d'API, et pas dans tel ou tel composant d'interface web précis. Ça me parait quand même clairement plus propre, et s'il y a plusieurs manières d'être inscrit (pas toujours par le même composant), dans tous les cas on a le même comportant attendu à la fin.
Propreté, mutualisation, cohérence, toussa…
(mais on me dit dans l'oreillette que c'est une bonne pratique de développement), c'est que ce n'est *absolument pas* à des composants d'interface de faire tels et tels traitements génériques communs d'édition, d'inscription etc. C'est d'ailleurs bien pour cela que l'on a, au moins théoriquement, des API (pas encore assez ! il y a justement encore trop de choses qui sont faites dans les CVT d'après moi). C'est aux CVT ou à d'autres canaux d'appeler ces API génériques.