[spip-dev] Customiser le Formulaire Forum

Dev
1

Je reformule ma question d'hier soir.

Je voudrait changer le look et le contenu du formulaire forum standard
Par exemple, je ne veux pas que le visiteur puisse changer le titre, et je ne veux pas la partie "Lien hypertexte (optionnel)" et enfin, je veux changer le bouton pour poster.

Ma question est : est ce que la bonne methode est de modifier la fonction retour_forum du fichier SPIP/inc-forum.php3, ou est ce que il y a un moyen de rediriger la balise FORMULAIRE_FORUM vers une fonction à moi, ou est ce que je me fais ma petite page PHP en vais ajouter les enregistrements directement dans la table?

Merci
Jean

2eme

2

@ Christian Lefebvre <christian.lefebvre@atosorigin.com> :

  Je pense que l'idéal serait d'avoir des fonctions qui retournent
la liste des choses à mettre dans le formulaire, par exemple une
fonction qui retourne un tableau des champs avec leurs valeurs par
défaut.
  Ça permettrait de boucler dessus pour générer son propre formulaire.

Exemple :
  #FORM_FORUM_HIDDEN => retourne un tableau des champs hidden à mettre
    (tableau ou chaine de caractères dans un format facile à spliter)
  #FORM_FORUM_FIELD => un tableau des champs texte
  #FORM_FORUM_DEST => l'url où il faut poster le résultat.

  On peut alors utiliser ces balises pour mettre un bout de php générant
le formulaire qui va bien.

Euh, non, il vaudrait mieux avoir un système pour surcharger (ou remplacer)
les fonctions qui se trouvent dans inc-formulaires..., en les plaçant dans
mes_fonctions ou ailleurs (si je crée function mon_truc(), je surcharge
la fonction truc())... évidemment il sera impossible de garantir que les
mises à jour de spip se passeront sans problème, mais au moins c'est hyper
souple (si on trouve comment faire sans tout casser)

-- Fil

3

Alors, tout d'abord, c'est ce que j'ai proposé y'a 15 jours :wink:
  Si certaines fonctions internes de spip avaient leur nom de stocké
dans des variables ou des meta, il suffirait de les réaffecter avec le
nom d'une fonction à soi pour les surcharger.
  J'avais fait ça une fois pour surcharger la méthode de recherche des
squelettes, c'est facile et ça pénalise moins les perfs qu'un "si la
fonction mon_truc existe je l'appelle, sinon j'appelle truc".

  Mais dans ce cas précis, ce qui m'embète c'est qu'il faut alors
recoder les trucs pas simple genre "faut il mettre le lien voir ou celui
confirmer". Avoir une fonction qui retourne la liste des hidden par
exemple, ça permet d'y mettre le code compliqué, quite à ce que
#FORMULAIRE_FORUM appelle cette fonction là en interne, histoire de
factoriser le code.

4

Je suis en train de regarder le code de inc-forum, pour voir comment
faire ça, car j'ai moi aussi ce besoin (toujours à cause du wap : les
formulaires ont pas du tout la même syntaxe).
  Je viens de penser à une solution qui serait peut être
plus "élégante" :
  Dans inc-calcul-squel, il y a un énorme switch sur les balises en tous
genres. Dans son "default", on pourrait mettre un parcours d'un tableau
de la forme nom_de_balise => fonction_à_appeler
  Si on trouve une entrée qui colle, on génère un
milieu='$'.$nomvar.' = "$fonction_à_appeler()";';

  Ainsi, il suffit d'ajouter des entrées dans ce tableau (depuis
mes_fonctions) pour définir ses propres balises, quite à ce qu'elles
contiennent un copier/coller/adapter d'une fonction spip .

  Là ou je sèche c'est sur les arguments qu'il faudrait passer à cette
fonction pour qu'elle sache ou elle est. J'ai du mal à suivre le contenu
de $contexte.
  Est-ce que $pile_boucles[$id_instance]->type_requete et $contexte
suffisent ?
  Est-ce qu'un pro de la question à un avis ?

(je sens venir la réponse du genre "ça va faire usine à gaz" :wink:

À+, Pif.

5

  Alors, tout d'abord, c'est ce que j'ai proposé y'a 15 jours :wink:

Comme quoi, ça percole doucement.

  Mais dans ce cas précis, ce qui m'embète c'est qu'il faut alors
recoder les trucs pas simple genre "faut il mettre le lien voir ou celui
confirmer". Avoir une fonction qui retourne la liste des hidden par
exemple, ça permet d'y mettre le code compliqué, quite à ce que
#FORMULAIRE_FORUM appelle cette fonction là en interne, histoire de
factoriser le code.

#FORMULAIRE_FORUM appelle une fonction qui gère tout ; cette fonction est
actuellement assez lourde, tu l'as remarqué. Je pense que la bonne solution
serait de la reprogrammer plus proprement en éclatant ses diverses étapes en
autant de sous-fonctions (elles-mêmes surchargeables, donc).

Par ailleurs, euh, tu peux nous épargner le nianiania ci-dessous :wink:

Ce message est strictement confidentiel. Son intégrité n'est pas
assurée sur Internet. Le contenu de ce message ne peut engager la

.../...

-- Fil

6

Ouaip ... 260 lignes quand même :slight_smile:
  Je vais essayer d'y regarder de plus près, je tente de découper un
peu, et on en recause, ok ?

À+, Pif (sans le nianiania réglementaire :wink:

7

  Ouaip ... 260 lignes quand même :slight_smile:
  Je vais essayer d'y regarder de plus près, je tente de découper un
peu, et on en recause, ok ?

Euh, oui, cette liste est là pour ça :wink:

À+, Pif (sans le nianiania réglementaire :wink:

Autres bugs signalés, si tu as envie/temps de regarder :
1) la table spip_meta n'est pas sauvegardée (ni restaurée)
2) le surlignage n'est pas compatible utf-8

je crois que c'est tout ce qui reste, d'ailleurs...

-- Fil

8

Bonjour à tous,

Il a y a qqes temps, je posais ici la question de savoir comment permettre aux simples intervenants en forum sur abonnement de pouvoir se présenter en qqes lignes. Pas de réponse. Question trop éloignée du concept SPIP, trop complexe ou m'intéressant que moi ? Sans doute les trois à la fois ;-).

Alors, bien que n'ayant jamais abordé PHP et n'étant pas très enclin à ce genre d'exercice, je m'y suis collé. Je n'aurai pas ramené ma fraise à nouveau sur ce sujet si Fil n'avait parlé de "reprogrammer" #FORMULAIRE_FORUM. Du coup, on ne sait jamais, peut-être mes réflexions peuvent-elles servir aux autres ? On peut rêver. Sinon, désolé pour le bruit.

Voici donc ce que j'ai retenu et qui fonctionne sur SPIP 1.5.2, avec forums avec abonnement (sinon tout cela n'a pas de sens), sans mots-cales (pour l'instant).

Fonctionnalités

9

Voila un premier résumé de mes cogitations sur ce sujet, toutes les
remarques sont les bienvenues :

but du jeu : découper la fonction retour_forum afin d'avoir des
sous fonctions utilisables pour définir des formulaires personnalisés.

actuellement, on a :
  function retour_forum(
           $id_rubrique, $id_parent, $id_article, $id_breve, $id_syndic,
           $titre='')

dedans, il y a :
-> init des variables
  $new, $redac => test pour des hidden
  $afficher_groupe => pour mots clés
  $afficher_texte => ? pour tester le contenu du post ?
  $forums_publics => test pour afficher un message d'avertissement
  $lien => destination du formulaire (uri bizarre ?)
  $retour => destination du redirect à la fin => hidden

on pourrait découper ça en sous fonctions de ce type :
- formulaire_forum_get_spec : retourne un tableau
  - action => destination du formulaire
  - envoyer => 'name' du bouton pour prévisualiser
  - confirmer => 'name' du bouton pour confirmer l'envoi

- formulaire_forum_get_hidden : retourne un tableau
    id_message, ajout_forum, forum_id_rubrique, forum_id_parent,
    forum_id_article, forum_id_breve, forum_id_syndic, alea, hash,
    retour_forum, new, redac

- formulaire_forum_get_textes : retourne un tableau
  - titre => titre mis en argument, ou defaut
  - texte => texte déjà saisi (relecture) ou rien, ou msg d'origine
      en indent selon option ?
  - auteur, email_auteur => si relecture, ou identifié
  - nom_site_forum, url_site => si relecture
  - affichage => si relecture, texte à mettre en forme (=> à passer
      dans propre())

- formulaire_forum_get_mots : là, j'ai rien compris au code :slight_smile:
    liste des groupes/mots à afficher ? + option un_seul ?

À+, Pif.

10

Salut tous,
  Voici un premier jet de réécriture de la fonction retour_forum, faite
à partir de celle de la version 1.6.
  Je crois que tout y est sauf ce qui tourne autour des mots clé.

  Principe :
- retour_forum prend les même arguments qu'avant, et retourne la même
  chose, mais elle appelle les fonctions décrites ensuite
- formulaire_forum_get_destination retourne l'url à mettre comme
  destination du formulaire
- formulaire_forum_get_hidden retourne la liste des champs hidden à
  mettre dans le formulaire. elle a à peu près tous les arguments de
  retour_forum (sauf le titre) et en plus la valeur pour $retour.
- formulaire_forum_get_textes retourne le contenu des différents champs
  textuels (texte, titre, auteur ...)
- formulaire_forum_get_mots là ... je sèche :slight_smile:

  Étapes suivantes :
- valider cette étape là
- ajouter la gestion des mots clé
- voir comment utiliser proprement les fonctions créées depuis un
  squelette (surcharge de retour_forum ? test dans retour_forum ?
  balise à part ?)

  Pour ce qui est des mots clé, si quelqu'un peux m'expliquer le
principe de cette partie du code, ça m'aiderait pas mal, car je n'ai
jamais utilisé les mots clé dans les forums et je ne comprend pas trop
comment ça marche.

  À+, Pif.

modif.forum.php3 (7.7 KB)