Poursuivant la mise en squelette des balises nécessitant une deuxième passe de PHP, la CVS d'aujourd'hui contient un nouveau squelette qui fournit sans interpolation de PHP la mise en page des balises LOGIN_PRIVE et LOGIN_PUBLIC (cette dernière aussi implicitement appelée lors d'une intervention dans un forum sur abonnement).
Ces deux balises réalisant presque la même chose, un seul squelette est fourni pour les 2: formulaire_login-dist.html. Leurs scripts d'appel, également nouveaux, se nomment inc-login_prive.php3 et inc-login_public.php3 qui remplacent inc-login définitivement inutile. Les noms de ces deux balises ne commençant pas par "FORMULAIRE" contrairement aux 7 autres réécrites récemment, les 7 scripts d'appels ont finalement été renommés
(inc-signature.php3 est devenu inc-formulaire_signature.php3 etc) afin d'avoir une interface de programmation cohérente.
Comme pour les squelettes à formulaire, ce nouveau squelette repose sur un grand nombre de HTTP_VARS fourni par les scripts d'appels. Ces HTTP_VARS contiennent en particulier l'intégralité de la ligne SQL concernant l'auteur ayant le login indiqué. Une application immédiate, exploitée par ce nouveau squelette, est de visualiser le logo de l'auteur lors la phase de saisie du mot de passe.
Cerise sur la buche: les deux balises acceptent à présent un paramètre indiquant le login dont on veut la saisie du mot passe. Cette possibilité permet par exemple de construire une page d'accueil de l'espace privé sous forme de la suite des logos des auteurs, chaque logo étant associé à la saisie du mot de passe spécifique. Cet effet (avec une mise en page évidemment très améliorable) pourra être obtenu en remplaçant dans le squelette
de la page d'accueil (l'historique login-dist.html, à ne pas confondre avec le nouveau) la balise #LOGIN_PRIVE par:
Comme pour les squelettes à formulaire, ce nouveau squelette repose sur un grand nombre de HTTP_VARS fourni par les scripts d'appels. Ces HTTP_VARS contiennent en particulier l'intégralité de la ligne SQL concernant l'auteur ayant le login indiqué. Une application immédiate, exploitée par ce nouveau squelette, est de visualiser le logo de l'auteur lors la phase de saisie du mot de passe.
Une petite question comme cela en passant...
Où exactement passe cette ligne SQL?
Est-ce qu'il n'y a pas un danger de SQL injection ou un pirate (qui pourrait avoir le status d'auteur) modifie la commande SQL et la remplace par une autre bien plus méchante.
Si je me trompe et que je n'ai rien compris (vu d'ici en tout cas j'ai pas tout compris)... alors oublie.
Non. L'information que je donne ici concerne les balises et variables disponibles hors boucle dans un squelette.
De meme que le squelette article.html a la balise #ID_ARTICLE (et le critere {id_article}) prédéfinie (par l'URL ou un INCLURE)
je dis que les squelettes à formulaire ont des balises préféfinies (par un INCLURE implicite) issue d'une requête SELECT.
Ce n'est donc qu'en lecture que la requete se fait, et en fait elle était déjà là avant.
Simplement on précise le contexte inclus lors de l'utilisation de ces squelettes.
J'attends avec impatience une contrib utilisant ces nouvelles possibilités, je pense que ça clarifiera beaucoup de choses.
Je tiens d'abord à saluer ce bel effort de mise en squelette des formulaires qui va permettre aux webmestres d'étendre leur champ d'action et d'aller plus loin dans la personnalisation de SPIP.
Précision : j'ai constaté avec plaisir que les formulaires personnalisés n'avaient pas besoin de se trouver à la racine mais pouvaient être placés dans le même répertoire que les squelettes habituels.
Dysfonctionnement : j'utilise #LOGIN_PUBLIC pour réserver l'accès d'une partie du site aux membres de mon association. Le comportement de #LOGIN_PUBLIC est le même que #LOGIN_PRIVE : on est redirigé systématiquement vers l'espace de rédaction (cvs 04/01).
En attendant, j'essaye d'y voir un peu plus clair dans le fonctionnement des nouvelles balises contextuelles liées aux variables GET, notamment dans le cadre d'utilisation des formulaires.
