Restriction (disparition ?) annoncée de Framaforms

Bonjour,

J’utilise régulièrement les Framaforms. C’est un outil vraiment formidable et j’invite régulièrement les utilisateurs de Googleforms à migrer vers Framaforms. J’ai découvert récemment le billet déframatisons internet de septembre 2019 dans lequel des restrictions sont annoncées dès mi-2021. Je comprend la nécessité de supprimer des services inutilisés, inaboutis ou chronophage en modération. Mais je ne comprend la disparition du service Framaforms et je suis très inquiet, car c’est un outil stratégique de part sa nature même (collecte d’information) qui n’a pas à ma connaissance d’alternatives libres. Je ne serai pas contre l’installer sur notre serveur (association), mais la page Framacloud n’existe pas encore et je ne sais pas si il serait possible de l’installer sur un serveur mutualisé ? J’ai vu quelque part que Framaforms s’appuyait sur Postgresql. Pour quoi ce type de SGBD plutôt que le classique MySQL ? Faut il des extension spécifiques ?

La case « Et après ? » étant encore vierge est ce qu’une intégration dans Nextcloud ne serait pas envisageable. Nextcloud dispose actuellement d’une app de formulaire mais elle est sans commune mesure avec les Framaforms tant dans la conception que les fonctionnalités et le rendu.

J’espère qu’une solution pourra être trouvée car c’est vraiment un très très bon outil.

Cordialement,
Cédric.

hello,

Je viens justement de le mettre en place sur un serveur mutualisé avec MySQL, et ça fonctionne quasiment à 100%, quasiment à l’identique.
Plus de détails ici : [Framaforms] - comment retrouver "validation du formulaire" sur une instance perso?

Pour ce qui est de sa disparition chez Frama, il faut se souvenir du but de la campagne « dégooglisons internet » : nous libérer en nous montrant voire expliquant comment faire (« la voie est libre, mais la route est longue »).

2 « J'aime »

Bonjour,

Merci @Ned pour ces infos. Qu’est ce que tu entend par « quasiment à 100% » ? A quel niveau se trouve le 0,5% manquant ? Bon après il y a des hébergeurs qui proposent des bases Postgres en mutu, soit en natif soit en offre complémentaire, donc c’est gérable, mais ça ajoute à la complexité (coût supplémentaire et/ou nouvel hébergeur…). D’après ce que j’ai vu des différents post, l’installation sur un mutu n’est pas très évidente. Une autre chose m’inquiéte, l’un des post dit que Framaform est basé sur du Drupal 7. Or le support de Drupal 7 s’arrête à la fin 2021. Est ce que Framaform sera porté sous Drupal 8 ?

Franchement je n’ai pas eu d’autre souci que tout casser et devoir recommencer quand j’ai accepté de mettre à jour le module FormBuilder vers sa version Alpha. Si tu te limites aux version annoncées dans l’autre fil de discussion, ça fonctionne.

Les différences sont surtout esthétiques. Exemple pas de page d’accueil du formulaire : il faut en faire une DANS le formulaire sous forme de « balise HTML » suivie de « saut de page ».

Il a fallu aussi que je me tape les trads des modules, je ne sais pas pourquoi elles n’ont pas suivies à leur installation (si tu fais une install identique à la mienne, je peux te passer le fichier de trad’, ça te fera gagner un paquet de temps).
Le problème en utilisant Drupal 8, c’est que FormBuilder n’y est plus en drag&drop, il faut déclarer les composants dans une liste, et c’est ergonomiquement rébarbatif pour mes utilisateurs. Peut-être que d’ici 2021 ils auront remis le d&d en fonction ?

2 « J'aime »

Oui effectivement sans le Drag&Drop ça perd beaucoup de sa fonctionnalité. Le portage du Module vers D8 n’est en cours que depuis 5 ans apparemment. Mais peut être que l’arrêt du support de D7 va booster les portages des modules :wink:

En tout cas Framaform est un très bel outil et j’espère que persisteront des instances hébergées pour tout ceux qui ne peuvent pas se lancer dans une installation complexe dès qu’ils ont besoins d’un formulaire :slightly_smiling_face:

Sincèrement l’installation n’est pas difficile, en dehors du piège dans lequel je suis tombé (et encore c’est de ma faute, je n’avais pas fait de backup avant la mise à jour) et de la galère de traduire (mais je le répète, je refile mon fichier .po à qui le souhaite).

Après, oui, j’espère qu’ils vont finir de porter ce module vers Drupal 8, histoire de pas tourner sur une version obsolète l’an prochain… Mais bon, là il y avait urgence pour dépanner des collègues.

1 « J'aime »

A défaut de page Framacloud il y a les instructions d’installation dans la forge de Framaforms : Framasoft / framaforms · GitLab

Pour information, nous avons actuellement une personne (coucou @thelem :wink:) qui travaille d’arrache pied sur Framaforms pour corriger les bugs récalcitrants, apporter quelques fonctionnalités attendues depuis longtemps et surtout pour simplifier son installation afin de permettre que d’autres personnes / entités que Framasoft puissent s’approprier Framaforms :slight_smile: (pour ce dernier point, on promet rien niveau date !)

1 « J'aime »

Merci @Gavy. Je testerai probablement un de ces quatre une installation avec Apache sur un mutualisé OVH avec MySQL et/ou un Postgresql en SQL Privé pour voir si c’est viable. @Ned je ne connais pas du tout Drupal et je ne connais pas les fichiers .po . Lorsque tu parles de traduction, tu parles de l’UI qui reste en anglais dans une installation MySQL c’est ça ?

@Gavy Pour ce qui est de la date, si ça pouvait être avant la date des restrictions prévues, ce serait top :wink: mais je sais que l’équipe et les bénévoles de frama dont ce qu’ils peuvent. :slightly_smiling_face:

1 « J'aime »

Quelques réponses supplémentaires :

  • une solution plus facile pour installer Fforms est prévu d’ici fin juin (la fin de mon stage ^^), donc avant la restriction de service.
  • effectivement le fait que ça soit basé sur D7 est un problème, et aucune force vive n’est actuellement disponible pour passer à D8. Dans la mesure où Framasoft prévoit la fermeture du service prochainement et que y’a plein d’autres choses à faire (toujours hein) ce travail ne sera a priori pas pris en charge par l’asso. Pas de solution donc pour le moment, donc dans la même idée que @CATER-COM pour la fin de support, j’espère que les restrictions de services par Framasoft va motiver la communauté à contribuer aux logiciels pour les pérenniser.
2 « J'aime »

:grinning: super nouvelle

@thelem puisque tu es dans le technique jusqu’au cou, est ce que le portage sur D8 des différents modules Drupal suffirait à rendre Framaforms compatible D8 ? Dans le cas cas contraire est ce qu’il y aurait un gros travail d’adaptation de Framaforms à ces nouvelles version des modules ?
Ne connaissant pas du tout Drupal, je n’ai aucune idée de l’écart technologique entre la v7 et la v8.

Oula non, il faudrait du boulot. Autant le passage D5-D6-D7 a eu l’air de se faire en douceur (encore que j’étais pas là), autant il y a un vrai écart entre D7 et D8. Non que ce soit spécialement compliqué pour quelqu’un de familier avec D8 à mon avis, @pyg qui est à l’origine de Fforms, avec ses super-talents en D7 n’a pas eu trop de problème à brancher tous les modules.
Par contre le fait que des modules disparaissent entre D7 et D8 est effectivement un problème.

1 « J'aime »

Exactement.
Mes utilisateurs sont tout sauf des geek, et encore moins anglophones. Donc je dois me taper toutes les trad’, qui sont rassemblées par Drupal dans un fichier .po

@Ned merci. Si je ne peux pas utiliser Postgresql, je serai effectivement preneur des fichiers de traduction :grinning:.

@Ned @thelem je reste quand même un peu perplexe sur cette histoire de BDD, si ça fonctionne bien avec MySQL et que donc Framaforms n’exploite pas de fonctionnalités propres à Postgresql, pourquoi mettre comme pré-requis, et avoir initier un développement avec un SGBD qui n’est souvent pas disponible en standard dans les hébergements web ? :roll_eyes:

@Ned as tu aussi testé les fonctions d’export des résultats dans différents formats ? As tu testé les fonctionnalités de validation de formulaire ? Il me semble que ce sont les processus les plus complexes qui pourraient tirer parti de Postgresql le cas échéant.

Je n’ai pas encore tout testé car cette implémentation est une des trouze tâches auxquelles je dois faire face en ce moment (je bosse dans la formation pro, donc je te laisse imaginer la vague de surcharge que la coronacrise vient de nous coller en nous forçant à tout basculer à distance).

Le validation des formulaires, avec le module indiqué dans l’autre fil, fonctionne bien (j’ai fait des tests avec ces fichues-surpuissantes-mais-imbitables regex :wink: )
Les exports aussi, même si je n’ai pas fait de test exhaustif.

Pour ce qui est du fichier.po, je doute qu’il dépende de la base de données qui est derrière, ce format est un standard des problématiques d’internationalisation (« i18n » & « l10n ») il me semble.

Je pense pas que ça avait été testé, et je t’avoue être très surpris que ça fonctionne ^^ à voir à l’usage si ça a pas cassé quelque chose, mais tant mieux.

Si ce SGBD a été choisi malgré sa faible disponibilité, c’est forcément qu’une fonctionnalité non dispo dans MySQL était nécessaire. Mais peut être que depuis le développement initial cette/ces fonctionnalité(s) a/ont été implémentées dans MySQL et que la restriction Postgresql n’est plus nécessaire. @thelem pourquoi es tu étonné ? As tu déjà une idée de ce qui ne devrait pas marché avec MySQL ? Ce serait intéressant de savoir pour éviter, au bout de plusieurs semaines ou mois de fonctionnement, de se rendre compte que finalement il y a bien une fonctionnalité cassée :crazy_face:. D’un autre côté ce serait ballot de payer une offre Postgresql spécifique si finalement ça tourne aux petits oignons sous un MySQL livré en standard avec un hébergement web mutualisé :money_with_wings: :money_with_wings: :grinning:

C’est pas qu’on avait besoin de telle ou telle fonctionnalité, c’est qu’on anticipait la forte utilisation de framaforms et qu’on ne souhaitait pas avoir des performances toutes moisies. L’adminSys (moi) a donc dit : utilise PostgreSQL comme base de données. Comme nous n’avons pas des moyens humains infinis, ça n’a jamais été testé sur MySQL. Donc on ne peut pas se permettre de le conseiller. Ça peut marcher, comme ça peut foirer. Et vu qu’on n’a pas de temps à y consacrer si ça fonctionne pas, on dit « Utilisez PostgreSQL ».

1 « J'aime »

Petite précision : je ne suis pas parti des sources git de Framasoft, j’ai installé Drupal 7 et les modules qui vont bien (cf l’autre fil que je mentionne plus haut), donc je n’ai pas eu à me soucier d’une éventuelle compatibilité avec le SGBD, vu que Drupal est annoncé compatible MySQL.

1 « J'aime »

@Framasky :slightly_smiling_face: c’est plutôt une bonne nouvelle. Si vous n’avez pas utilisez de fonctionnalités propre à Postgresql, il n’y a pas de raison majeur que ça plante, en particulier au regard de l’expérience de @Ned.
@Ned, je vais essayer l’installation git avec MySQL et je ferai un retour.

ha oui, s’il te plaît, ça m’intéresse beaucoup.