Le futur de FluxBB

adaur · 22-04-2015 10:01:28

Lors de la dernière version, ils ont décidé de réintroduire les hooks dans le plus grand des calmes siffle

Et ils parlent de faire une 1.6 dans laquelle ils feraient du refactoring de code, quitte à remettre les hooks à grande échelle, etc en attendant la 2.0 sous flarum (cf la discussion sur le org et ma réaction la bas et ici même)

Bref, je ne suis plus très confiant quant à la direction que prend flux, c'est un euphémisme de le dire

Mpok · 22-04-2015 18:40:15

Ben en fait, autant la décision de passer à Flarum me semble mauvaise (tout en respectant le côté personnel de la chose), autant je suis pour cette "éventuelle future" version 1.6.
C'est peut-être l'occasion de garder ainsi FluxBB dans la même structure générale que toujours, sans devoir passer à une sorte de "FlarBB".

adaur · 22-04-2015 23:47:55

Oui, mais la dénomination même des versions fait que la branche 1.* que nous connaissons sur est amenée à disparaître au profit du FlarBB (dont on attend toujours un premier jet)

mangafan · 23-04-2015 00:54:45

Après avoir mieux regardé le système de "hook" réintroduit, ça me parait à la fois cool et moyen. Cool parce qu'il montre ce qu'il y a de bien dans la POO et moyen parce que même en ajoutant des

flux_hook('mon_hamecon_avant_ceci');
/*...*/
flux_hook('mon_hamecon_apres_cela');

partout, ça ne fait que montrer par la suite à quel point tout le reste du code n'est pas fait pour ça. Et puis ça fait bizarre de voir tout ça calé dans dans un buffer au final.

Genre, j'ai ajouté des champs aux profils des utilisateurs mêmes avec des hooks sur la page profil, vu la structure du code, je devrais quand même aller le modifier directement. Donc l’intérêt s'en trouve amoindri encore que je dis ça. Si j'ai une idée de comment ajouter les champs au formulaire et le retour à l'affichage. Mais même pas, je ne vois pas comment toucher une requête via les hooks.

D'ailleurs, je ne suis pas le seul : https://fluxbb.org/forums/viewtopic.php … 800#p42800 Je ne saisis pas ce que la solution adoptée a de très différent sur ce point. J'ai le sentiment que ce système de hook a été bricolé dans l'urgence pour l'antispam et livré différemment derrière pour faire patienter.

Bref, je ne veux pas lancer de débat HS ici. happy

Mpok · 24-04-2015 21:19:23

@adaur : ben justement, c'est ce qu'il faudrait éviter… Pour moi, FluxBB et Flarum sont 2 softs DIFFÉRENTS, et ce n'est pas parce que le principal (et seul au fil du temps… neutral ) développeur de FluxBB a décidé de bosser sur Flarum que le projet initial doit mourir huh . C'est d'ailleurs ce que je reproche à Franz : si je respecte tout à fait sa décision personnelle de travailler désormais sur un autre projet, je n'ai pas aimé "la forme" de son annonce. On ne "mixe" pas comme cela des projets aussi différents (entre FluxBB 1.4/1.5 et Flarum 0.0, c'est la réalité actuelle). Lui, compare FluxBB "2.0 beta" avec Flarum, il y trouve des similitudes dans le code, et je le crois. Sauf que POUR NOUS, FluxBB 2.0 n'existe pas (en production), la différence ACTUELLE entre les deux projets est bien plus importante.

mangafan a écrit :

Bref, je ne veux pas lancer de débat HS ici.

Et bien VOILÀ !! mdr Ton message (ainsi que ceux d'adaur et mes réponses) NE SONT PLUS HS ! siffle
J'ai créé une discussion "Le futur de FluxBB" et j'y ai mis nos derniers échanges.
Donc allez-y mangafan et adaur, continuez à nous donner vos avis smile (perso, j'avoue que je n'ai jamais regardé le système de hooks… J'ai pas d'avis pour l'instant).

mangafan · 25-04-2015 22:27:32

Pour faire simple, j'aime beaucoup Pluxml dont la philosophie est très proche de FluxBB ou en tout cas du PunBB d'origine hormis pour le mysql bien entendu.

Aujourd'hui quand je regarde le code de Pluxml, je trouve ça cohérent, c'est de la POO et j'arrive à m'adapter facilement avec le moteur de base, c'est ultra simple de créer une fonction au sein d'une classe pour la reprendre ensuite au sein d'un template sans tripatouiller partout comme un damné et j'en apprend concrètement en l'utilisant.

Tandis que FluxBB semble à mes yeux devenir de plus en plus un amas de rustines. Je viens de faire une maj de 1.4 à 1.5 en passant par Winmerge pour voir les différences et c'est dingue ce que le code a stagné au fond. Pourtant, je suis sûr qu'en restant dans l'esprit de base simple et fluide, on peut récrire le code en POO sans devoir se coller un framework.

FluxBB via un framework, c'est pas un moteur de forum pour moi, c'est juste un forum adapté basé sur un moteur de framework. J'attendais plus un standalone de forum orienté objet avec Fluxbb. J'ai le sentiment que les framework ont globalement retiré des compétences aux devs php. On a eu du mal à s'adapter à la POO (personnellement en tous cas mais je ne suis qu'un vilain autodidacte) et les framework ont mâché le boulot. J'ai utilisé Code Igniter et son modèle MVC, j'en ai saisi les avantages ; Mais je n'en ai pas appris beaucoup sur les notions de POO, j'ai juste exploité un modèle que je me suis imposé à base de didacticiel en respectant des règles de nommage. La belle affaire, ce n'est pas ça apprendre, certes j'ai gagné un temps fou mais j'ai rien appris.

Qu'on utilise un framework pour développer une application au sein d'une entreprise pour rendre cohérent le travail d'équipe et réduire les temps de dev, je peux le comprendre mais pourquoi au fond faire un outil optimisé et communautaire via un framework. Ça me parait contre productif, un non-sens même. Comment on peut optimiser le code en employant un outil qui va vers une standardisation des méthodes. Si ces méthodes devaient être standards pourquoi ne font-elles pas parti du corps de PHP. Mais je peux me tromper, je n'ai pas la science infuse.

Je n'imagine pas les autres moteurs de forum se fondre dans un framework. Et on connait des CMS qui sont passé à la POO sans utiliser de framework avec un grand succès et qui ont vite saisi l'intérêt d'être standalone. Quoi de plus simple que de créer une extension à Wordpress sans mettre le Bronx dans le core.

Pour revenir à l'apprentissage par la pratique, par exemple dans PunBB/FluxBB, j'ai découvert à l'époque un emploi de la mise en tampon que je n'ai pas vu ailleurs de manière si simple et fonctionnelle pour la gestion des thème, c'était judicieux pour du Php4, ça m'a donné une vision, en PHP5 POO est-ce que ça l'est encore ? Qu'est-ce que j'apprendrai avec un FluxBB/Flarum, l'emploi optimisé de la POO ou le bon emploi de Laravel ? Certains diront les deux, moi je dis qu'au mieux, j'apprendrai à me servir de Laravel comme je me sers de Code Igniter.

Edit: Bon pardon pour la tartoche, ça m'avait paru plus court dans ma tête.

Dernière modification par mangafan (25-04-2015 22:32:17)

adaur · 26-04-2015 01:21:05

Content de voir que certains partagent ma vision de la chose smile cf http://fluxbb.fr/forums/viewtopic.php?p … 37#p112937

S'il ne reste qu'un développeur et que ça n'avance pas, c'est à cause de leurs multiples redémarrages (et ils ne semblent pas apprendre de leurs erreurs) et incapacité à prendre une décision.

Mpok · 26-04-2015 01:22:06

mangafan a écrit :

Bon pardon pour la tartoche, ça m'avait paru plus court dans ma tête.

Au contraire !! tongue C'est génial de pouvoir lire ce genre d'avis, argumenté et bien écrit. smile
Malheureusement, je ne peux répondre "qu'à priori" parce que :

je n'ai jamais utilisé (ni même regardé) de framework.
la POO reste pour moi assez "abstraite". Je connais les principes, mais c'est principalement resté dans l'état de quelques cours dont je me souviens vaguement. Bon, c'est suffisant pour que j'arrive à me débrouiller s'il s'agit de modifier ou d'utiliser ce genre de code, mais je ne peux pas dire que j'ai vraiment "développé" en POO. Et mes quelques 'intrusions' dans ce domaine étaient en C, pas en PHP (mais je suppose que ça marche de la même façon).

Ceci dit, je pense être totalement d'accord avec toi.
Je ne vois pas bien l'intérêt de passer par une sous-couche (le framework, quel qu'il soit) pour améliorer notre soft de forum. Comme tu le dis :

mangafan a écrit :

je suis sûr qu'en restant dans l'esprit de base simple et fluide, on peut récrire le code en POO sans devoir se coller un framework.

Ce qui est sûr par contre (selon moi), c'est que la prochaine étape de FluxBB DOIT être la séparation totale du code de l'affichage, c'est à dire basiquement enlever tous les "?> … <?php" dans les fichiers php. Est-ce qu'il faut un framework pour cela ? C'est la question…
Pour "défendre" Franz et les autres partisans, je dirais qu'ils ont sans doute réfléchi avant de prendre cette décision. Mais comme toi, j'ai "l'impression" que ce n'est pas nécessaire.

Et en ce qui concerne "l'apprentissage par la pratique", je te rejoins également. Je ne connaissais RIEN à PHP (ni à MySQL en dehors de mes cours "de base") avant de me mettre à PunBB à l'époque. Et c'est grâce au code simple du soft que j'ai appris. Il est clair qu'en nous "mâchant le travail", l'utilisation d'un framework ne va pas dans le sens de l'apprentissage, ni d'ailleurs dans le sens originel du projet : "simple, light, fast".
Mais d'un autre côté, je ne me vois pas refaire le code de FluxBB en POO moi-même (y compris avec quelques aides).
Donc, il va falloir suivre les devs. En revanche, je compte bien me battre pour que le projet "FluxBB" ne se transforme PAS en "FlarBB"… hmm

Mpok · 26-04-2015 02:34:11

@adaur : bien sûr que nous partageons ton avis (lien).

J'ai du mal tho à comprendre ta réponse (sur le .org) : peu importe la discussion de principe entre les NOMS de version (1.6 vs 2.0), il reste que la future version (en tout cas comme je l'imagine) "tuera" toutes les mods. Et alors ?…
Il est NORMAL qu'en cas de gros changement les mods doivent être… well, 'modifiées' ! wink

Ne nous trompons pas de combat :
- nous sommes CONTRE le mix avec flarum (voire même à l'utilisation d'un framework comme sous-couche, cf. mangafan et moi).
- nous sommes POUR une évolution de FluxBB (quitte à rendre les mods actuelles obsolètes). Avec POO (re-factoring global), schéma MVC strict, tout en restant simple d'accès (donc pas de framework). Pour l'instant, la proposition "1.6" semble la meilleure dans ce sens…
(my cents, tho)

Note @all, n'hésitez pas à exprimer vos avis…

Otomatic · 26-04-2015 10:26:07

Bonjour,

Je suis un « vieux de la vieille » qui a commencé à programmer en logique câblée puis aux interrupteurs ; le tout pour des programmes de test d'équipements aéronautiques, donc en séquentiel.
J'ai quelques difficultés à appréhender correctement la POO, surtout en étant totalement autodidacte en PHP et MySQL. Néanmoins, d'après ce que j'en comprends, j'en perçois l'intérêt pour FluxBB, même si mes mods devront être réécrites.
En fin de compte, même si j'ai mis à disposition Mod Installer et les mods afférentes, ce « truc » a d'abord été écrit pour mon usage personnel et me faciliter les mises-à-jour de FluxBB - je suis un très vieux partisan du moindre effort.
Je ne souhaite pas-du-tout utiliser une sous-couche avec un Framework ou tout autre machin du même style.
En séparant bien le code de l'affichage et avec la POO, on devrait pouvoir intégrer facilement des addons sans avoir à modifier le corps.

adaur · 26-04-2015 10:29:09

Je voulais dire que la remise à zéro du code anéantira les mots actuelles, à contrario avec une évolution du code où l'on pourrait adapter les mods.

Je vous suis sur la non utilisation de framework ne cadrant pas avec le motto de fluxbb, j'ai aussi appris le php avec flux.

Je suis bien évidemment pour la reprise de flux en poo (et des que j'aurai du temps cet été je compte bien essayer d'en faire quelque chose, et apprendre l'oriente objet et la mvc par la même occasion) mais pour moi une telle version de flux devrait être la 2, pas une hypothétique 1.6. Rien que par son nom, une 1.6 serait destinée à mourir au profit de la 2 (comme feu 1.2 et 1.4).

La seule solution que je vois est de motiver des personnes prêtes à coder ensemble pour faire avancer flux sur la base actuelle en poo et mvc pour présenter à Franz une solution en disant que c'est ce qu'on veut pour la suite, qu'on est plusieurs et motivés à le faire. S'il n'est pas d'accord, fork.

Par ailleurs, un vieux fork russe (fluxbb power edition) avait été fait en mvc

Dernière modification par adaur (26-04-2015 10:35:58)

fanf73 · 26-04-2015 12:10:01

Même si je n'ai pas appris la programmation PHP par son biais, FluxBB reste le logiciel sur lequel j'ai le plus fait mes armes, que ce soit pour le modifier lourdement afin qu'il réponde à mon besoin une base / plusieurs sites, pour aider les utilisateurs ici ou pour développer des mods qui ne dénaturent pas le fonctionnement normal du forum. Un vrai entraînement qui me sert tous les jours dans le milieu professionnel.

Cela fait plusieurs années que je suis de plus loin son évolution car j'attendais ce que l'on considère un peu tous comme le Saint Graal maintenant : la refactorisation du code en POO et le passage en MVC. Mes différents projets personnels utilisant en partie FluxBB comme Framework (connexion + bdd), j'espérai pouvoir les faire évoluer en même que la sortie de la 1.3, puis de la 2.0, qui n'ont jamais vu le jour...

Je me suis remis un peu à jour suite à l'annonce de Flarum (que je ne considère pas comme FluxBB 2.0 moi non plus) et ce que j'ai vu m'a pour le moins dérangé : utilisation massive de JS, fonctionnalités new school par défaut, fonctionnalités basiques en options, ... Je n'y retrouve pas du tout l'esprit de FluxBB et, me faisant peut-être vieu jeu du haut de mes 30 ans, regrette un peu l'outil simple a appréhender qui m'a offert tant d'heures magiques de développement.

Je ne sais pas si un groupe de développeurs va réussir à travailler ensemble pour faire renaître ce beau projet de ses cendres, mais voici la vision que j'en ai personnellement :

POO et MVC : changement obligatoire. Je ne comprenais par trop l'intérêt au début mais maintenant que je maîtrise un peu mieux le principe je trouve que cela apporte un plus énorme, que ce soit pour le développement ou la maintenance. Il ne m'a jamais été aussi simple de rajouter une fonctionnalité que depuis que j'y suis passé
Framework : même si j'en comprends l'intérêt (ne pas ré-inventer la roue), je préférerai qu'il en développe un maison répondant aux besoins spécifiques de l'outil. J'utilise personnellement un mini-framework dérivé de celui que le cours de POO d'OpenClassroom nous fait développer, et qui ne fait que le basique : lancement de l'application, route, request, view et quelques fonctionnalités de base pour les Model et Controller. C'est largement suffisant, rapide, et je développe ensuite la surcouche nécessaire au nouveau projet.
Versions : l'un des points que je n'ai jamais vraiment compris... mais ça reste perturbant. Il faudrait pour moi aussi passer en 2.0 avec le passage en POO/MVC.
Hooks / Extension : je pense que c'est LA grosse épine dans le pied. Il n'y aurait pas eu la problématique des extensions, une 1ère version full POO et MVC serait sortie depuis longtemps à mon sens. Le fait de devoir trouver une solution pour gérer tous les cas d'extensions avant de refactoriser le code est ce qui a fait couler le navire. Il faudrait pour moi presque laisser ce point de côté si on veut voir naître rapidement une version plus moderne de FluxBB, mais je sais que c'est utopique et que l'ajout des extensions après-coup demanderai énormément de modification du code.

Dernière modification par fanf73 (26-04-2015 12:14:37)

Askelon · 27-04-2015 20:04:17

J'ai pas mal réfléchi à cette histoire ces dernières semaines, et malheureusement, peu importe comment je tourne le problème, j'arrive à la même conclusion que FluxBB 1.6 est une pure perte de temps et que le projet va avoir de gros problèmes à régler à moyen terme. C'est dramatiquement simple : la moindre évolution détruira tout l'écosystème des styles et des mods et créera un bordel monstrueux en conséquence pour le support. Objectivement, la version 1.6 telle qu'elle devrait être signerait une coupure totale avec la version 1.5, et devrait donc devenir une version 2.0 pour clairement marquer le changement ; or cela n'arrivera vraisemblablement pas, puisque FluxBB 2.0 s'oriente vers Flarum…

Je rejoins Mpok là-dessus, la priorité absolue doit être la séparation HTML/PHP ; les fichiers enchaînant 400 ligne de PHP impératif puis 200 ligne de HTML mêlé de PHP, ce n'est plus possible, c'est ingérable. Or je ne vois pas comment faire ça proprement sans rendre obsolète la quasi totalité des styles et mods disponibles. Même chose pour les hooks, qu'il est à mon sens irréaliste de vouloir introduire en l'état actuel de FluxBB : les mods modifient tout et n'importe quoi. Inclure des hooks pour modifier telle ou telle requête, telle ou telle action n'a aucun sens si un mod installable en deux clics écrase en dur la requête ou si la même requête est répétée à plusieurs endroits différents dans le code comme c'est parfois le cas (encore plus fréquemment pour les actions : combien de fois affiche-t-on les infos utilisateurs comme le nom ou le titre ? On ne va pas coller un hook à chaque fois…).

Les propositions pour la version 1.6 vont dans le bon sens, mais il n'est − selon moi, évidemment − pas possible de faire proprement sans exploser la compatibilité avec la version 1.5 ; j'ai bien peur qu'on se dirige vers une version 1.6 bâclée qui ne satisfera pas grand monde.

Personnellement, j'ai pris la décision de purement et simplement abandonner FluxBB pour le moment. J'ai commencé à adapter mes forums vers Luna, le fork de Studio384, qui correspond assez à ce que je veux. C'est loin d'être parfait, mais je suis en train de mettre en place des trucs que je veux avoir dans FluxBB depuis 4 ans et qui ne verront jamais le jour sur la 1.x pour les raisons évoquées plus haut : suppression définitive du système foireux des referrers ou profit des nonces, utilisation de gettext pour les traductions avec des fichier pomo, un code mieux séparé du thème, une transition vers de l'objet et donc l'introduction propre et fonctionnelle des hooks, etc. Si d'aventure des trucs que j'aurais développé pour Luna peuvent s'adapter à FluxBB je partagerais ; et si à terme, FluxBB 1.6 se révèle intéressant, je reviendrais sur mon choix et repasserais sous FluxBB. Mais à court terme, j'utiliserais autre chose.

Édition, note sur le choix de Laravel et Flarum : à mon avis le choix de Franz se justifie totalement. L'état actuel de FluxBB fait qu'il faut tout cramer et reprendre à zéro pour proposer une solution correcte, or utiliser un framework simplifie beaucoup les choses que cela soit pour le développement, le support ou l'évolution. Il ne faut surtout pas oublier cela : la position de Franz n'est pas, n'a jamais été, de se soucier de la facilité d'apprentissage des développeurs utilisant FluxBB. Sa position est de développer et gérer un projet qui fonctionne. Or pour cela, rien de mieux que d'utiliser des outils fiables et qu'il maîtrise. D'où le choix de Laravel. Au fond, ça se résume simplement à cela. La question est d'approuver ou non.

Dernière modification par Askelon (27-04-2015 20:12:54)

Xanathos · 27-04-2015 20:05:30

Bonsoir,

Je suis avec grand intérêt l'évolution de FluxBB ainsi que vos interrogations au sujet de son futur.
Ayant plusieurs forums tournant sous Flux, je m'inquiète moi aussi de la direction prise par le projet...

Que pensez-vous du fork d'il y a un an ou deux, ModernBB ?
Je ne l'ai jamais testé, mais peut-être devrais-je m'y intéresser happy

Cordialement,
Xan'

Askelon · 27-04-2015 20:21:56

Xanathos a écrit :

Que pensez-vous du fork d'il y a un an ou deux, ModernBB ?
Je ne l'ai jamais testé, mais peut-être devrais-je m'y intéresser

Luna que j'évoque ci-dessus est la suite du projet ModernBB : http://getluna.org. Comme ModernBB, c'est loin d'être parfait, mais c'est prometteur et ça évolue vite. À mon avis une bonne transition entre un hypothétique FluxBB 1.6 et un tout aussi hypothétique fork en alternative à Flarum.

adaur · 27-04-2015 21:36:46

Luna est sympa visuellement, mais trop actif et finalement peu évolué niveau code je trouve (pas de PDO ou POO, pas de hooks) c'est presque un grand gâchis à mon sens hmm

mangafan · 27-04-2015 21:45:56

Askelon a écrit :

Édition, note sur le choix de Laravel et Flarum : à mon avis le choix de Franz se justifie totalement. L'état actuel de FluxBB fait qu'il faut tout cramer et reprendre à zéro pour proposer une solution correcte, or utiliser un framework simplifie beaucoup les choses que cela soit pour le développement, le support ou l'évolution. Il ne faut surtout pas oublier cela : la position de Franz n'est pas, n'a jamais été, de se soucier de la facilité d'apprentissage des développeurs utilisant FluxBB. Sa position est de développer et gérer un projet qui fonctionne. Or pour cela, rien de mieux que d'utiliser des outils fiables et qu'il maîtrise. D'où le choix de Laravel. Au fond, ça se résume simplement à cela. La question est d'approuver ou non.

Moi j'aurais dit oui s'il n'y avait pas Flarum. Qu'on me dise, il faut que FluxBB se couple à un framework et qu'on m'explique pourquoi et comment. Mais qu'on me propose de fusionner avec le système de forum déjà basé sur un framework. Là, je tique, ce n'est plus la même chose. FluxBB, c'est simple et fluide, une fusion de deux outils de forums n'a rien de simple.

Soit Laravel est vraiment simple, évolué et concis et là je dis mais alors quel intérêt pour Flarum de voir FluxBB arrivé dans son girond ? Sinon, c'est qu'il manque toujours quelque chose à Flarum que FluxBB peut lui offrir ?

Si j'étais mauvaise langue, je dirais que Flarum est un bon outil en devenir, d'où c'est "être mauvaise langue" certains diront, il lui manque la notoriété de FluxBB ; Et oui, ça se situe là. Donc Franz a fait Flarum, il y a mis de l'énergie, de l'engagement et il s'est écarté de la vision de FluxBB. De là, il propose ou plutôt il impose que la 2.0 de FluxBB deviendra Flarum, on a pas la choix la discussion et comme toujours posée mais la décision est déjà prise, ça se passe ainsi depuis le fork.

Moi, je n'en veux pas. Clairement il faut casser le système de mod actuel et même de style, tout le monde le veut, oui on devrait tous changer de nos habitudes mais on le sait déjà ; On est en demande même, ça nous gonfle de gérer les mods et les thèmes ainsi et ce malgré les outils proposés par la communauté.

Le portage vers la POO d'ailleurs ne me parait pas aussi hard qu'annoncé, dans le sens qu'on ne part pas de rien. Au fond les fonctions, elles existent toutes, il faudrait apprendre à les organiser dans un système de classes pour commencer à se rendre compte ensuite du boulot à faire pour évoluer. Et la philosophie du soft, c'est pareil, on l'a déjà. C'est assez différent que de partir de zéro sans framework.

Flarum n'a pas du tout cette démarche. Il y a combien de forum sous Laravel ? Pleins, autant que de développeurs. Lequel fait consensus auprès des utilisateurs ? Aucuns et pour la bonne raison que si un utilisateurs de Laravel à besoin d'un forum, il le crée ou alors il crée le lien avec un moteur de forum existant. Lequel fera consensus si FluxBB l'adoube ? Flarum ?

Après qui a déjà installé Laravel en local pour développer un projet dessus ici ? Moi par exemple. Pensez-vous si vous avez fait cette expérience comme moi que l'utilisateur moyen de FluxBB (ce n'est pas péjoratif) va s'en sortir juste pour installer Flarum et le modifier à sa guise ? Moi je dis en grand "NON".

Et ce n'est pas la POO qui bloque, c'est bien le framework. Des outils fait en POO, vous en avez tous déjà installé et utilisé pleins sans vous prendre là tête.

Et puis n'oublions pas, Flarum n'est qu'une promesse comme l'était FluxBB 1.3/2.0.

Franz a écrit :

As it stands, there is a need for modern, well-architected, powerful forum software that is easy to use and self-host. That’s what Flarum is. But I'm a full-time student and I don't have time to do this by myself. So I'm opening up Flarum to the world — let's build it together.

Il n'est pas prêt, il n'a pas de communauté et il n'a pas de devs au pluriel. Github n'est pas une vision, personne ne commit un gros bout de core sur Github sans que l'auteur d'origine n'est montré une voie claire à suivre, genre :

function qui_fait_le_cafe($grain_a_moudre) {/* YOUR IDEA HERE */}

car en général le commit est refusé et ça a sèché les ardeurs de tout le monde et multiplié les fork. Quand on te refuse un commit deux ou trois fois, t'arrêtes d'en faire de manière spontanée. Github, c'est bien pour combler les failles.

Askelon · 28-04-2015 00:41:02

adaur a écrit :

Luna est sympa visuellement, mais trop actif et finalement peu évolué niveau code je trouve (pas de PDO ou POO, pas de hooks) c'est presque un grand gâchis à mon sens

Oui, le développeur a commis l'erreur de se focaliser essentiellement sur le design et les fonctionnalités en premier, ce qui lui a fait perdre pas loin d'un an à mon avis. Le visuel est intéressant et prometteur, mais le code reste très proche de FluxBB 1.5.x.

Ça évolue, cela dit. Comme précisé plus haut j'ai personnellement ajouté le support gettext, la prochaine version utilisera des nonces au lieu des referrers ; pour la version 2.0 le dev prévoit un gros travail sur le code, je vais essayer de trouver du temps pour avancer sur un découpage complet du code et du template pour avoir un système de thèmes indépendant, et du coup factoriser le code. La première étape sera de se débarrasser des requêtes SQL qui polluent le code pour se tourner vers des fonctions et de la POO quand c'est adapté (ce n'est pas nécessairement le cas partout). Dès lors il sera plus facile d'intégrer des hooks. C'est de toute façon mon objectif à terme, avec ou sans l'aval du dev : avoir une version de Luna qui fonctionne sans mélange HTML/PHP et qui gère les hooks. Comme on est pas près d'avoir ça dans FluxBB avant deux ans au moins, je pense que ça sera aussi simple avec Luna.

mangafan a écrit :

Moi j'aurais dit oui s'il n'y avait pas Flarum (…)

En fait j'ai l'impression qu'on se focalise beaucoup sur la « fusion » FluxBB/Flarum par rapport à l'importance qu'elle peut réellement avoir. C'est peut-être moi qui ait mal compris, mais de ce que j'ai lu, la jonction des deux projets vient simplement du constat que Franz et le développeur de Flarum sont en train de faire le même boulot chacun de leur côté, avec en prime le même framework ; il est du coup assez logique de mettre en commun les deux projets pour avancer sur une base commune plutôt que s'éparpiller et finalement de perdre du temps… Sur le forum anglais ça a foncé dans le tas parce que la démo de Flarum est farcie de JavaScript , avec un côté trop social-network et un aspect Bootstrap peu développé. Du coup j'ai l'impression que la majorité des intervenants est passé totalement à côté de l'intérêt de la nouvelle, malgré plusieurs tentatives de Franz pour rappeler que rien n'est figé. Montrer cette démo était une grave erreur car personne n'a semblé voire les possibilités, le fond n'a presque pas été abordé et les attaques se sont focalisées essentiellement sur la forme. Plutôt que de discuter des opportunités ouvertes il n'y a eu qu'un rejet massif de la démo. Et depuis c'est bloqué à ce stade.

Personnellement il y a peu de chance que j'utilise Flarum, mais je pense qu'il faut passer au-delà du simple rejet basé sur l'unique impression donnée par une simple démo de travail en cours.

mangafan a écrit :

Le portage vers la POO d'ailleurs ne me parait pas aussi hard qu'annoncé, dans le sens qu'on ne part pas de rien. Au fond les fonctions, elles existent toutes, il faudrait apprendre à les organiser dans un système de classes pour commencer à se rendre compte ensuite du boulot à faire pour évoluer. Et la philosophie du soft, c'est pareil, on l'a déjà. C'est assez différent que de partir de zéro sans framework.

Je ne sais pas à quel point tu t'es penché techniquement sur la question, mais j'ai l'impression que c'est un poil plus compliqué que ça. Déjà parce que tout n'a pas besoin d'être porté en objet, mais que presque tout doit être ré-écrit. Obtenir un tout cohérent à partir de la version actuelle ne va pas être simple ; même en faisant le strict minimum certaines parties sont entièrement à revoir.

mangafan a écrit :

Flarum n'a pas du tout cette démarche. Il y a combien de forum sous Laravel ? Pleins, autant que de développeurs. Lequel fait consensus auprès des utilisateurs ? Aucuns et pour la bonne raison que si un utilisateurs de Laravel à besoin d'un forum, il le crée ou alors il crée le lien avec un moteur de forum existant. Lequel fera consensus si FluxBB l'adoube ? Flarum ?

Si j'ai bien compris le but de Flarum est, précisément, de répondre au fait qu'il n'y aucun logiciel de forum basé sur Laraval qui fasse consensus.

mangafan a écrit :

Après qui a déjà installé Laravel en local pour développer un projet dessus ici ? Moi par exemple. Pensez-vous si vous avez fait cette expérience comme moi que l'utilisateur moyen de FluxBB (ce n'est pas péjoratif) va s'en sortir juste pour installer Flarum et le modifier à sa guise ? Moi je dis en grand "NON".

Si on suit cette logique, le but semble justement être que personne n'ait besoin de modifier Flarum lui-même. Un peu de la même manière qu'il ne viendrait à personne l'idée d'aller modifier le core de WordPress. Effectivement le framework peut rebuter de prime abord ; moi ça ne me tente pas du tout, c'est bien pour ça que je n'ai jamais été bien loin dans cette voie. Mais il y a un intérêt réel derrière que j'entrevois pour la suite.

mangafan a écrit :

Et puis n'oublions pas, Flarum n'est qu'une promesse comme l'était FluxBB 1.3/2.0.

Absolument. Je n'attends rien de ce que côté avant deux ans au moins, d'où ma bascule prochaine vers Luna en attendant de voir.

À la relecture je me fais un peu l'avocat du diable, mais c'est vrai que je vois certains côté très positifs à Flarum, donc j'essaye de contrebalancer un peu les nombreux avis totalement négatifs que je peux lire et qui me semble un peu exagérés parfois cool

mangafan · 28-04-2015 05:01:36

Askelon a écrit :

En fait j'ai l'impression qu'on se focalise beaucoup sur la « fusion » FluxBB/Flarum par rapport à l'importance qu'elle peut réellement avoir. C'est peut-être moi qui ait mal compris, mais de ce que j'ai lu, la jonction des deux projets vient simplement du constat que Franz et le développeur de Flarum sont en train de faire le même boulot chacun de leur côté, avec en prime le même framework...

En fait ce que je comprends, c'est que Franz a trouvé un forum sous Laravel qui est un framework qu'il affectionne et que l'équipe de dev de FluxBB n'entrave rien à Laravel, je ne leur en veux pas pour ça. Du coup c'est peut-être bien 2 ans de plus à ajouter à ton estimation. C'est vrai que je me suis mélangé pensant que Franz était lead sur le projet Flarum, j'ai vu franzliedke authored 7 days ago, j'ai pas fait gaffe qu'il s'agissait juste d'un commit mais il est déjà bien actif.

Askelon a écrit :

Je ne sais pas à quel point tu t'es penché techniquement sur la question, mais j'ai l'impression que c'est un poil plus compliqué que ça. Déjà parce que tout n'a pas besoin d'être porté en objet, mais que presque tout doit être ré-écrit. Obtenir un tout cohérent à partir de la version actuelle ne va pas être simple ; même en faisant le strict minimum certaines parties sont entièrement à revoir.

Justement non, ce qui me semble le plus compliqué, c'est si les gens s'imaginent tout casser et transformer FluxBB en un Wordpress du forum du jour au lendemain avec un back-office monstreux. Mais Wordpress, c'est une usine à gaz en terme de moteur, c'est génial mais ce n'est pas simple, léger et fluide pour faire un forum. Tu aurais trop d'options et trop de charge serveur. Et concrètement depuis le temps, la volonté n'y a jamais été, je n'ai rien vu de renversant sur l'alpha de FluxBB2 et avant ça rien d'autre en POO, jamais. Les devs non jamais étaient sur la même longueur d'onde, Laravel a déboussolé la majorité des devs, il suffit de regarder les commit.

https://github.com/fluxbb/fluxbb2/graphs/contributors

Askelon a écrit :

Si j'ai bien compris le but de Flarum est, précisément, de répondre au fait qu'il n'y aucun logiciel de forum basé sur Laraval qui fasse consensus.

De manière égoïste, je dirais qu'on a nous besoin d'un forum qui est en l'état correct mais à l'identique et en POO avant que tout le code ne soit obsolète. Que la communauté Laravel n'ait pas de forum, alors d'une j'en doute et de deux je m'en fous. Et même si ça peut paraître agressif dit ainsi, je n'ai pas envie de mentir sur ce point. Imagine qu'une autre communauté d'un autre framework n'arrive pas à faire son système de blog, la bonne blague, et se frotte à WP. C'est peu probable que WP soit intéressé mais la communauté WP elle, elle tirerait à boulet rouge. Les gens qui utilisent des framework n'ont pas nécessairement besoin d'outil de forum, ils aiment avoir un couteau suisse et tout faire avec ou avec l'aide de package. Rien ne fait consensus sous Laravel hormis Laravel.

http://forums.laravel.fr/

http://forums.laravel.fr/creation-forum … vel-4-t307

Laravel est très dépôt dans la forme, t'installes tout à la ligne de commande, t'as une console, ça défile et tu comprends rien à ce que tu fais. Tu dois faire confiance aux sources que tu emplois aussi, bah oui t'as vite fait d'installer une backdoor. Parfois c'est incompatible, parfois il y a des dépendances inattendues, parfois ça crash tout et t'as plus qu'à te faire les logs et chercher à comprendre ce que tu as fait en une seule ligne de commande qui te paraissait pourtant innocente. Et la le pompon, c'est de chercher de l'aide, le CLI c'est cool mais souvent en conseil on te dit "Réinstalle tout, c'est le plus simple !" après t'avoir conseillé tous les outils qu'il te manquait quand tu as commencé la première fois ; Tu peux tenter de demander si il y a pas moyen de sauver le coup en touchant les fichiers à la main pour pas tout perdre, c'est peine perdu, si l'installation à louper la communauté ne sait pas comment on fait, on entre les lignes et ça marche, point et si ça marche pas c'est parce que tu ne sais pas taper des lignes de commande. Finalement pour un forum, t'as de quoi faire tourner un serveur complet d'application.

Je ne veux pas que FluxBB soit un paquet au milieu de pleins d'autres moi. Au final, tu n'auras plus une communauté FluxBB mais juste une communauté Laravel car les utilisateurs de Laravel sont ainsi, ce qui est fait sous Laravel, c'est du Laravel.

Askelon a écrit :

mangafan a écrit :
Après qui a déjà installé Laravel en local pour développer un projet dessus ici ? Moi par exemple. Pensez-vous si vous avez fait cette expérience comme moi que l'utilisateur moyen de FluxBB (ce n'est pas péjoratif) va s'en sortir juste pour installer Flarum et le modifier à sa guise ? Moi je dis en grand "NON".
Si on suit cette logique, le but semble justement être que personne n'ait besoin de modifier Flarum lui-même. Un peu de la même manière qu'il ne viendrait à personne l'idée d'aller modifier le core de WordPress. Effectivement le framework peut rebuter de prime abord ; moi ça ne me tente pas du tout, c'est bien pour ça que je n'ai jamais été bien loin dans cette voie. Mais il y a un intérêt réel derrière que j'entrevois pour la suite.

Quand je parle de modifier j'entend le b.a.-ba et même juste de l'installation du forum, d'un thème et les quelques modifications simples que chacun finit par faire. Ce framework est le pire pour cette communauté qui a des habitudes qui seraient à tordre pour s'adapter à un tel modèle. On a vu de tout en matière d'adaptation de forums qui partaient de FluxBB. Pour comprendre FluxBB2/Flarum, il faudra comprendre Laravel, ce n'est plus un choix, c'est un fait.

Wordpress lui est un framework à lui tout seul, il a des livres dédiés pour son apprentissage et on peut tout faire avec en terme de cms, tout. FluxBB, c'est juste un forum qui pourrait devenir plus que ça grâce à la POO mais pas en 2 ans, le virage il est loupé depuis un moment. Wordpress, avant d'être ce qui l'est, a fait des évolutions simples, il n'est pas passé du blog à ce qu'il est aujourd’hui en une branche.

Et je ne vois pas comment ils vont trouver le temps de faire une 1.6 et une 2.0, en plus c'était déjà la blague de la 1.5... On va se retrouver avec une 1.9.9 que la 2.0 ne sera toujours pas là. Ou tout simplement avec une 1.6 faite à l'arrache.

Dernière modification par mangafan (28-04-2015 05:03:46)

FluxBB.fr

#1 22-04-2015 10:01:28

Le futur de FluxBB

#2 22-04-2015 18:40:15

Re : Le futur de FluxBB

#3 22-04-2015 23:47:55

Re : Le futur de FluxBB

#4 23-04-2015 00:54:45

Re : Le futur de FluxBB

#5 24-04-2015 21:19:23

Re : Le futur de FluxBB

#6 25-04-2015 22:27:32

Re : Le futur de FluxBB

#7 26-04-2015 01:21:05

Re : Le futur de FluxBB

#8 26-04-2015 01:22:06

Re : Le futur de FluxBB

#9 26-04-2015 02:34:11

Re : Le futur de FluxBB

#10 26-04-2015 10:26:07

Re : Le futur de FluxBB

#11 26-04-2015 10:29:09

Re : Le futur de FluxBB

#12 26-04-2015 12:10:01

Re : Le futur de FluxBB

#13 27-04-2015 20:04:17

Re : Le futur de FluxBB

#14 27-04-2015 20:05:30

Re : Le futur de FluxBB

#15 27-04-2015 20:21:56

Re : Le futur de FluxBB

#16 27-04-2015 21:36:46

Re : Le futur de FluxBB

#17 27-04-2015 21:45:56

Re : Le futur de FluxBB

#18 28-04-2015 00:41:02

Re : Le futur de FluxBB

#19 28-04-2015 05:01:36

Re : Le futur de FluxBB

Pied de page des forums