Transfert du site https://francegenweb.org dans SPIP

Historique

Le propos général est la généalogie à travers plusieurs thèmes, chacun traité dans une base séparée.

Le site est semblable à une mutualisation. Plusieurs bases dans une interface commune.

Le site existe depuis 1998. Créé par des développeurs amateurs à l’aide de scripts en « php procédural ».

A très bien fonctionné jusqu’à l’apparition de mySQLi. Il a fallu injecter un patch de conversion de toutes les fonctions mySQL=> mySQLi.

Fonctionnement

Ce sont essentiellement des bases de données alimentées par tous nos bénévoles.

Dans la partie publique chaque visiteur peut :

  • interroger une base à l’aide d’un formulaire,
  • signaler une erreur dans une fiche,
  • déposer une nouvelle fiche via un formulaire sécurisé,
  • envoyer un fichier.csv contenant un dépôt multiple.

Dans la partie privée, le gestionnaire de la base peut :

  • Vérifier et valider les fiches déposées,
  • corriger les erreurs signalées,
  • vérifier et importer les fichiers.csv déposés.

Limites

Le site supporte php 7.n mais semble de plus en plus fragile et passera mal à php 8 et +

Si on ne fait rien, toutes ces ressources accumulées en bientôt 30 ans vont disparaître.

Demande

Besoin d’un sérieux coup de main pour apprendre à maîtriser les formulaires tant pour l’affichage public que pour le traitement en backoffice. J’ai un gros besoin d’être cornaqué pour passer l’une des bases sous SPIP. Ensuite je me débrouillerai pour adapter aux autres bases.

J’ai commencé avec la base « MairesGenWeb »

MairesGenWeb dans https://00fgw.spipfactory.org

Merci de vos conseils.
Sandy
sandy.andriant@francegenweb.org

Je ne comprend pas la question « maitriser les formulaires ».

Salut,

« Maîtriser les formulaires » : je veux dire par là, avoir la possibilité - en backoffice - de contrôler les données déposées par nos bénévoles grâce au formulaire public et après corrections éventuelles, valider les données, c’est-à-dire les intégrer à la base de données.

Merci d’avoir pris le temps de me lire

Il faudrait que tu donne une explication plus détaillées du « process » que tu veux avoir pour voir ce qui est le mieux. Mais en SPIP en general, les formulaires du privées passent mal dans le public lorsqu’il s’agit de redactionnel. Il est svt plus simple de former à la proposition d’article.

OK,

Dans le site https://francegenweb.org (FGW dans la suite), les bénévoles peuvent déposer un nouveau relevé par le formulaire en ligne :

Ce dépôt est enregistré dans la base de donnée avec le statut « 0 » : fiche non validée.
Le coordinateur passe dans le backoffice où il a accès à la liste de l’ensemble des fiches à valider.
Il clique sur une et voit un formulaire semblable dont il peut modifier les données (orthographe, date, lieu, etc) puis valider la fiche qui prend alors le statut « 1 » : fiche validée.
Cette fiche est alors accessible en ligne via le moteur de recherche général qui est prévu pour n’afficher QUE les fiches dont le statut est 1.

Il y a également le statut « 2 » : fiche annulée qu’on utilise en cas de doublon.
Ces fiches restent accessibles en backoffice dans une page qui ne recense que ces fiches dont le statut est 2.
ça sert à conserver des fiches qu’on ne veut pas afficher sans les supprimer.

Je pense qu’à ce moment là, le plugin Formidable est le meilleur outils.

Tu peux configurer des formulaires souples. Ensuite tu peux avoir plusieurs statuts de réponses. Je traduits dans ton vocabulaire

Proposé → 0 / Non validé
Publié → 1 / Validé
Refusé → 2 / Annulé

Pour l’affichage publique, tout depend de ce que tu en fais après.

Ma principale difficulté est de récupérer les valeurs enregistrées dans la table et de les afficher proprement dans le formulaire.

Donc ton problème est un problème de migration de donné si j’ai bien compris ?

Non, pas du tout.
Mon pb est de changer d’outil pour interroger la même base.
Passer de php procédural à SPIP que je maîtrise bcp moins.

J’ai fait des essais. Sur l’affichage public pas de pb (malheureusement le site « miroir » en SPIP est provisoirement en rideau) mais je n’arrive pas à valider les dépôts des bénévoles.

Je ne comprends pas ce que tu exprimes, là.

et le remplissage de la base, tu va faire comment ? ton besoin est VRAIMENT pas clair…

Je ne sais justement pas comment interagissent les formulaires et les bdd… Où sont stockées les données déposées via un formulaire ?

OK,

je suis allé voir le tuto et j’entrevois les difficultés.
Les données du formulaire ne sont pas stockées dans la table de la base mais dans une table du formulaire sous forme sérialisée… donc il va falloir « inventer » la façon de faire ce transfert.

Tout cela n’est pas très claire encore une fois.

  1. Est-ce que tu veux conserver la structure de la table tel qu’elle existe ? Si oui dans ce cas il faut plutot créer un « Objet » spip correspondant à cette structure de table, et dans ce cas là écrire tes propres formulaires selon le standard CVT de SPIP + faire des requetes en boucle SPIP
  2. Soit tu veux utiliser un système de formulaire configurable facilement en interface, formidable, et dans ce cas il faut
    a. Créer le formulaire
    b. Faire la migration de donnée (c’est le plus complexe sans doute, mais pas impossible non plus)
    c. Ecrire ensuite ton propre squelette pour faire l’affichage correspondant à tes besoins

Ps : ce tuto n’en est pas un, c’est une doc complémentaire et non finalisée qui a été déplacé d’un wiki briouillon vers un site plus officiel, sans que l’on sache pourquoi

Je ne peux pas être plus clair désolé. Nous ne parlons pas « le même langage ». (Je ne comprends pas par exemple la notion d’objet SPIP)
J’envisageais d’utiliser SPIP pour avoir un « moteur » fiable et qui suit régulièrement les mises à jour de PHP et les alertes de sécurité.

Pour la structure de la base, ça n’a aucune importance du moment que les données restent accessibles et modifiable aisément.

C’est ce que j’ai fait pour la partie publique. Mais je me trouve justement coincé quand je veux récupérer ces données et les modifier avant validation.

Je pense qu’on n’est pas raccord sur l’idée de formulaire. Il ne s’agit pas d’un formulaire dans lequel le visiteur ajoute un avis, un commentaire… Mais d’un interface particulier permettant d’ajouter - dans une base existante - des données qui seront interrogeables par tous après modification/validation par le coordinateur de la base.

C’est ce que j’expliquais (mal apparemment) dans ma demande initiale

Voici le fonctionnement de FGW par un exemple concret.

Dans la base « Actes-en-Vrac », le visiteur dispose d’un formulaire de recherche pour interroger la base.
Si je recherche le patronyme « Tavardon », j’obtiens la réponse suivante

et si je clique sur le lien détail, j’obtiens la fiche popup :
image

Cette fiche a un id dans la table : 215869 que je peux interroger dans la partie privée pour la modifier au besoin en cliquant sur MOD:

J’aimerais bien pouvoir faire l’équivalent avec SPIP car il y a de nombreuses bases dans FGW avec un coordinateur pour chacune d’elles. Je ne peux sérieusement pas demander à chacun de modifier totalement son mode de fonctionnement. Il faut que le système reste le plus proche possible de l’existant - en terme de validation des données - sinon je n’aurai plus personne…

Je crois bien que ce que tu cherches, c’est ceci : Formulaires CVT par l'exemple - SPIP

Autrement dit, comment faire un formulaire qui ensuite stockera des données dans une base (c’est la partie traitements).

Et un autre formulaire qui lira le contenu de cette table (c’est la partie Charger), et permettra d’enregistrer les modifications (de nouveau traiter).

Merci pour cette page très claire, très proche des scripts PHP que j’utilise ordinairement. Je ne suis pas complètement perdu !

Mais 2 points m’interpellent :

  1. où les données seront-elles enregistrées ? Dans une table formidable ou dans une table contenant toutes les autres données de la table ?

  2. Ensuite ces nouvelles données sont-elles interrogeables et consultables par tous ?

  1. Où tu veux : c’est toi qui écrit les traitements PHP, donc, tu choisis où tu enregistres.
  2. Comme tu peux les enregistrer où tu veux, tu peux garder tes affichages actuels en enregistrant au même endroit.

Bonus : les boucles SPIP permettent de boucler sur n’importe quelle table (en écrivant le nom de la table en minuscule).