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.
« 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.
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.
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.
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 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.
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
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
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…
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).
