FeatherBB, un fork de FluxBB au début de son développement

adaur · 11-07-2015 12:19:12

La Beta 1 est sortie smile http://featherbb.org/forums/topic/62/fe … 00-beta-1/

Integration with Slim Framework v2.6.2
New parser
MVC architecture
URL rewriting
Routing system
Responsive default style
Database schema compatible with FluxBB
Antispam protection
Themes fully customizables
PHP 4 support dropped
PSR-2 compliant

Magicalex · 13-07-2015 22:26:45

Otomatic a écrit :

Bonjour,
La totalité des hébergeurs avec Apache utilisent les VirtualHost et il n'y a absolument pas besoin de fichier .htaccess si on travaille dans les règles.

Quel est le rapport avec les variables serveur? et ça change rien au niveau du fonctionnement que tu configures le vhost dans le fichier de config ou dans un htaccess (sauf du point de vu des performances)

M.. · 18-07-2015 23:28:55

Longue vie à Featherbb et bon courage pour la poursuite de cet énorme travail de développement, je vais suivre tout ça avec beaucoup d'intéret, en espèrant que ce soit la relève que l'on attendait. En tout cas ça part sur de meilleures bases que la 2.0 "flarum" smile

Mpok · 19-07-2015 16:29:35

@adaur : étant "en vacances prolongées" lors de ton post initial, je n'ai pas pu réagir directement ; et ensuite, même au courant (par ouie-dire) de ton projet, j'ai volontairement laissé filer… Je m'en excuse, et voici enfin ma réponse. tongue

Écrite au fil des posts…

1) Je suis TOTALEMENT POUR l'idée de base (post initial, #1) . Moi aussi je vois d'un mauvais œil l'utilisation de framework pour la réalisation d'un "simple forum" (in english). Et moi aussi je veux que cela reste simple et léger, comme les spécifications de départ.

2) Le côté "non-MVC" du code m'a personnellement coûté plus d'un an de travail au début, je suis donc complètement d'accord avec cette nouvelle orientation du code. Notons que le même changement DOIT être opéré sur le css : de "properties-given" on doit passer à "bloc-given", et c'est 'normalement' que le passage en MVC devrait le faire. Mais c'est aussi le changement le plus visible pour un utilisateur 'lambda' : il n'en a rien à foutre du code, mais l'aspect css peut l'intéresser. Pouvoir modifer FACILEMENT le css DOIT ÊTRE un objectif du projet (d'autant qu'avec la POO dans le code, on va récupérer la POO native de css wink ).

3) Askelon #11, #12 : "FluxBB repose presque intégralement sur les mods, n'importe quel fork va automatiquement briser cette possibilité en modifiant plus ou moins lourdement le code de base"
C'est clairement à prendre en compte. Je pense qu'il y a un travail à mettre en place (ce que n'ont pas pris le temps de faire les devs du .org, qui sont pourtant confrontés à la même réalité soulignée par Askelon). NON, le système futur ne sera pas aussi "souple" pour les 'mods'. Il FAUT LE DIRE ET LE FAIRE COMPRENDRE. Néanmoins, si on introduit un système de 'plugins', celui-ci PEUT être suffisamment ouvert pour que les différentes mods existantes puissent être considérées comme des plugins… (c'est à dire converties facilement).
=> au-delà du passage en MVC et/ou POO, qui ne sont que des pbms de TEMPS (aucune difficulté technique), c'est sur cette gestion des plugins que sera jugée ka future application. huh

4) #18, #19 : euh… c'est cette mod qui surcharge notre bdd ? hmm siffle

5) post #22 : OK, donc je n'ai rien compris à la démarche… (ou celle-ci a changé). Il n'y a en fait AUCUN NOUVEAU PROJET (lequel nécessiterait au moins quelques mois avant de proposer quelque chose).
Y A-T-IL au moins des spécifications ? (lesquelles sont inhérentes au contexte "dit MVC" du projet).

6) posts suivant (dont #26) : même déception… sad

Conclusion :

Je ne peux que te féliciter, adaur, qui a eu le courage de se lancer dans quelque chose de compliqué. Et je te souhaite de réussir dans cet entreprise. smile
Néanmoins, j'attendais (après lecture du post initial) quelque chose de plus ambitieux, et/ou de plus "professionnel" (j'espère que tu ne m'en voudras pas trop…).
D'une part, ton "MVC architecture" (post #26) est juste l'idée que tu t'en fais. Dans la pratique, il faut commencer par un cahier des charges extrêmement détaillé (et contraignant), des procédures de tests, ainsi que des procédures de contrôle, le tout que tu n'as pas fait, visiblement. neutral
D'autre part, ton affirmation : "Database schema compatible with FluxBB", ne montre AUCUNE AMÉLIORATION concrète. Or, il faudra bien une évolution de la bdd pour pouvoir gérer les mods/plugins.
Enfin, le "Themes fully customizables" me fait sourire… siffle Comme je l'ai dit ci-dessus, le GROS pbm de FluxBB est son css "properties-driven" qui EMPÊCHE (ou réduit) toute "customisation". Et je DOUTE FORT que tu aies résolu ce pbm en quelques semaines… blink

Bref :
Autant je soutiens le projet de "moderniser" FluxBB, autant je voudrais que ce soit un projet "propre et clean" (passant les critères de sélection), et surtout RÉFLÉCHI. Et oui, je considère qu'un fork est actuellement peut-être nécessaire, mais pas n'importe comment. Le dèv d'adaur, ainsi que son implication, montre qu'il y a des personnes qui le veulent. Il s'agit maintenant (imo) de fédérer la communauté autour d'une idée commune, discutable au préalable - sur ce forum. Et donc de repartir d'une feuille blanche (quitte à rependre ensuite des fonctions du FluxBB actuel, et surtout les classes déjà écrites par adaur, qui a visiblement bien avancé sur le sujet).
Avancer à pas forcé comme l'a fait adaur ce dernier mois est certes "awesome", mais il est seul. Et il a 'craqué' pour un framework !

=> pour répondre à Otomatic (#7 et #19) : on ne peut pas ouvrir un forum (voire une catégorie) à chaque fois qu'il y a un fork de déclaré. Surtout en ce moment, où les tentations sont grandes ! wink (nice management, by the way mate cool )

Dernière modification par Mpok (20-07-2015 07:52:22)

adaur · 19-07-2015 23:44:56

Salut Mpok,

1) smile

2) D'accord aussi, mais j'aurai du mal à refaire le CSS seul je pense.

3) Je vois mal comment garder la compatibilité si on veut refaire totalement l'architecture du CMS, ne serait-ce que pour séparer les vues... On pourra toujours s'inspirer de la façon dont sont faites les mods actuelles, mais les réutiliser telles quelles, hormis les plus légères, me semble difficile.

4) Pas compris

5) Le projet est de faire évoluer le code actuel vers une base plus récente (orientée objet et MVC entre autre), d'où l'absence d'AMELIORATIONS comme tu dis. Je n'ai aucune envie de faire une course à l'échalote de fonctionnalités comme certains forks semblent vouloir le faire. Quelles spécifications as-tu en tête? J'ai une idée de là où je veux aller (cf post#1) au niveau des nouvelles fonctionnalités attendues si c'est ce que tu as en tête.

J'ai bien conscience de ne pas faire un projet professionnel, je ne suis pas professionnel et je n'ai pas des journées de 48h pour m'en occuper, même si j'ai un peu plus de temps en ce moment smile .

Je n'ai pas compris si tu me reprochais d'avoir choisi un framework (ce qui est tout à fait compréhensible), mais j'ai fait ce choix en raison de la légèreté elle-même du framework pour avoir un système de routes fonctionnel et robuste rapidement, ainsi qu'une architecture stable sur laquelle s'appuyer.

Je ne vois pas en quoi l'architecture de base des données devrait changer ? La gestion de la modification au sein du core oui, évidemment, mais l'ajout de données en base ne devrait pas poser de problème, si ce n'est rajouter une table pour voir quels plugins sont activés, et encore.

Les thèmes sont en effet totalement customisables, puisqu'on a un fichier vue modifiable par thème. L'intégralité du HTML peut-être modifié pour un seul thème sans compromettre l'intégrité des autres (c'est ce qui est fait pour le thème de base si tu as regardé le code de plus près). Rien ne t'empêche de modifier l'architecture du HTML, que ce soit en ajoutant des propriétés ou en réécrivant totalement le code de ces fichiers vue ainsi que le CSS correspondant, les anciens styles fonctionneront toujours.

Je ne tiens pas à faire cavalier seul, mais au vu de tes absences régulières ici même (un à deux passages par mois voire moins, c'est trop peu pour s'impliquer dans la durée sur un tel projet), je ne pense pas que tu sois le plus apte à gérer la 'communauté' (et j'espère que tu ne m'en voudras pas).

Les prochaines pistes d'améliorations sont:

=> Réécriture des requêtes avec un ORM pour qu'elles soient facilement modifiables, je pense partir sur Idiorm
=> Passage à gettext pour les traductions (@Askelon as-tu reçu mon mail?)

Dernière modification par adaur (19-07-2015 23:51:10)

Mpok · 20-07-2015 08:08:55

adaur a écrit :

Le projet est de faire évoluer le code actuel vers une base plus récente (orientée objet et MVC entre autre), d'où l'absence d'AMELIORATIONS comme tu dis. Je n'ai aucune envie de faire une course à l'échalote de fonctionnalités comme certains forks semblent vouloir le faire.

Ok. Je pense avoir mieux compris.

adaur a écrit :

Je n'ai pas compris si tu me reprochais d'avoir choisi un framework (ce qui est tout à fait compréhensible), mais j'ai fait ce choix en raison de la légèreté elle-même du framework pour avoir un système de routes fonctionnel et robuste rapidement, ainsi qu'une architecture stable sur laquelle s'appuyer.

Non, je ne reproche rien à personne… wink D'autant que je ne connais pas ce framework, et que j'en ai utilisé peu.

adaur a écrit :

Je ne vois pas en quoi l'architecture de base des données devrait changer ? La gestion de la modification au sein du core oui, évidemment, mais l'ajout de données en base ne devrait pas poser de problème, si ce n'est rajouter une table pour voir quels plugins sont activés, et encore.

Ben, je pensais justement aux plugins (ou mods) gérés dans la base, mais on peut certainement faire autrement et s'en passer.

adaur a écrit :

Je ne tiens pas à faire cavalier seul, mais au vu de tes absences régulières ici même (un à deux passages par mois voire moins, c'est trop peu pour s'impliquer dans la durée sur un tel projet).

Ça, c'est clair… happy J'ai d'ailleurs supprimé le dernier paragraphe de mon message ci-dessus, qui était un peu idiot puisque je n'aurai effectivement pas le temps.

Bon dev !! smile

Askelon · 21-07-2015 00:56:59

Mpok a écrit :

adaur a écrit :
Je ne vois pas en quoi l'architecture de base des données devrait changer ? La gestion de la modification au sein du core oui, évidemment, mais l'ajout de données en base ne devrait pas poser de problème, si ce n'est rajouter une table pour voir quels plugins sont activés, et encore.
Ben, je pensais justement aux plugins (ou mods) gérés dans la base, mais on peut certainement faire autrement et s'en passer.

Une entrée dans la table des options suffit : une liste des ID de plugins à charger, dans l'ordre. On récupère la liste, et si les fichiers existent on charge plugin_A.php, puis plugin_B.php, etc.

En revanche, il faut revoir la structure de la base de données. Ajouter une table de métadonnées pour les utilisateurs, par exemple, parce qu'une bonne partie des mods jouera avec ça : on peut pas avoir des plugins qui ajoutent à l'infini des colonnes à la table users et qui modifient les requêtes au kilomètre pour ajouter leurs variables à récupérer. Même logique pour les forums, discussions et messages. L'idée de base dun système de plugin est que les dev n'aient plus besoin de modifier le core ; cette idée s'applique aussi à la base de données.

adaur · 21-07-2015 01:21:14

Effectivement je n'y avais pas pensé sous cet angle, merci de soulever la question (et de toute façon j'en suis encore loin smile ) J'en profite pour te demander - tu n'as pas dû recevoir mon mail - comment tu avais fait les traductions de Luna: j'ai vu que tu avais implémenté le librairie POMO se basant sur gettext: pourquoi alors qu'il est natif à php ? Est-ce éviter un problème de rafraîchissement du cache ?

Merci d'avance wink

Mpok · 23-07-2015 15:00:00

Askelon a écrit :

Une entrée dans la table des options suffit : une liste des ID de plugins à charger, dans l'ordre. On récupère la liste, et si les fichiers existent on charge plugin_A.php, puis plugin_B.php, etc.

Non, ça ne "suffira" pas (imo)… Tu parles d'un 'ordre' ; what is ? Le plugin_B n"en a rien à foutre du plugin_A (et réciproquement). Il faut donc avoir une table dans la bdd pour gérer les incompatibilités.

Askelon a écrit :

L'idée de base dun système de plugin est que les dev n'aient plus besoin de modifier le core ; cette idée s'applique aussi à la base de données.

Nous sommes d'accord . C'est bien pour cela qu'il faut une gestion en bdd des plugins, avec un test sur les incompatibilités.
On pourra certes se fier aux devs, mais s'ils déclarent par exemple modifier la "bdd section 26" et le core "view 11", une simple comparaison pourra déterminer s'il s'agit de leur répondre que leur plugin est incompatible ou non.

@Askelon : une simple "liste" ne semble pas suffisante pour ce faire. Une liste suggère que l'on a rien à faire du précédent ou du suivant. Or là, le fonctionnement des "futurs plugins" fait qu'ils ont besoin de savoir ce qui se passe 'avant' ou 'après' eux.
Note : on pourrait également envisager des plugins "intelligents", qui s'adaptent à la configuration.

adaur · 23-07-2015 21:43:38

J'ai commencé la réécriture des requêtes avec Idiorm, c'est un ORM vraiment sympa à utiliser que je vous recommande.

Dans les faits, une requête lourde comme celle de l'index:

        $result = $this->db->query('SELECT c.id AS cid, c.cat_name, f.id AS fid, f.forum_name, f.forum_desc, f.redirect_url, f.moderators, f.num_topics, f.num_posts, f.last_post, f.last_post_id, f.last_poster FROM '.$this->db->prefix.'categories AS c INNER JOIN '.$this->db->prefix.'forums AS f ON c.id=f.cat_id LEFT JOIN '.$this->db->prefix.'forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id='.$this->user['g_id'].') WHERE fp.read_forum IS NULL OR fp.read_forum=1 ORDER BY c.disp_position, c.id, f.disp_position', true) or error('Unable to fetch category/forum list', __FILE__, __LINE__, $this->db->error());

devient:

        $select_print_categories_forums = array('cid' => 'c.id', 'c.cat_name', 'fid' => 'f.id', 'f.forum_name', 'f.forum_desc', 'f.redirect_url', 'f.moderators', 'f.num_topics', 'f.num_posts', 'f.last_post', 'f.last_post_id', 'f.last_poster');
        $where_print_categories_forums = array(
            array('fp.read_forum' => 'IS NULL'),
            array('fp.read_forum' => '1')
        );
        $order_by_print_categories_forums = array('c.disp_position', 'c.id', 'f.disp_position');
        
        $result = \ORM::for_table($this->feather->prefix.'categories')
            ->table_alias('c')
            ->select_many($select_print_categories_forums)
            ->inner_join($this->feather->prefix.'forums', array('c.id', '=', 'f.cat_id'), 'f')
            ->left_outer_join($this->feather->prefix.'forum_perms', array('fp.forum_id', '=', 'f.id'), 'fp')
            ->left_outer_join($this->feather->prefix.'forum_perms', array('fp.group_id', '=', $this->user->g_id), '', true)
            ->where_any_is($where_print_categories_forums)
            ->order_by_many($order_by_print_categories_forums)
            ->find_result_set();

Et on peut imaginer sans aucun problème des hooks modifiant l'array du select ou where à la volée, on peut même surcharger $result avant ->find_result_set() pour rajouter une jointure au besoin.

On a de plus accès aux résultats sous la forme d'un object:

foreach ($result as $cur_forum) {
    if ($cur_forum->redirect_url != '') {
        ...

Dernière modification par adaur (23-07-2015 21:47:37)

Otomatic · 24-07-2015 09:50:22

Bonjour,

Je suis un « ancien », c'est vrai, mais il y a des moments où je ne comprends pas l'ajout de couches supplémentaires au code et où je me pose réellement la question : Pourquoi faire simple quand on peut faire compliqué.
La requête de l'index, je la comprends parfaitement, il suffit simplement de bien la mettre en forme :

$result = $this->db->query('
	SELECT 	c.id AS cid, c.cat_name, f.id AS fid,	f.forum_name,
			f.forum_desc,	f.redirect_url,	f.moderators,
			f.num_topics, f.num_posts, f.last_post,
			f.last_post_id, f.last_poster
		FROM '.$this->db->prefix.'categories AS c
			INNER JOIN '.$this->db->prefix.'forums AS f
				ON c.id=f.cat_id
			LEFT JOIN '.$this->db->prefix.'forum_perms AS fp
				ON (fp.forum_id=f.id AND fp.group_id='.$this->user['g_id'].')
		WHERE fp.read_forum IS NULL OR fp.read_forum=1
		ORDER BY c.disp_position, c.id, f.disp_position', true)
or error('Unable to fetch category/forum list', __FILE__, __LINE__, $this->db->error());

En revanche, la surcouche Idiorm, je suis loin de bien la comprendre.
Et... quid de SHOW_QUERIES ? ... quid des debuggers ?

adaur · 24-07-2015 11:28:47

En fait, la "surcouche" Idiorm n'est pas plus une surcouche que le DB Layer de FluxBB actuel $this->db->query(...) or error(...). Il est un peu plus abstrait il est vrai, mais je ne pense pas qu'il rajoute à la complexification du code - au contraire.

Telle quelle la requête de FluxBB de base est bien évidemment compréhensible, le problème vient de la modification de celle-ci. Si je veux rajouter un champ au SELECT, je dois la modifier en dur et je casse la possibilité de mise à jour du core. Bien sur, on pourrait imaginer rajouter un $select dans la requête, mais passer tous les champs demandés dans un array et ajouter la possibilité de rajouter des -> pour enrichir la requête me semble important dans une logique de plugins.

De plus, Idiorm permet de passer par la PDO et échappe automatiquement tout ce qu'on lui donne. En théorie, plus d'injection SQL possible.

Le SHOW_QUERIES sera géré par ORM::get_query_log(), je vais regarder pour les debuggers.

Askelon · 24-07-2015 11:50:07

adaur a écrit :

J'en profite pour te demander - tu n'as pas dû recevoir mon mail - comment tu avais fait les traductions de Luna: j'ai vu que tu avais implémenté le librairie POMO se basant sur gettext: pourquoi alors qu'il est natif à php ? Est-ce éviter un problème de rafraîchissement du cache ?

Non, rien reçu en effet ! J'ai utilisé POMO parce que je voulais un système assez puissant qui aurait permis de générer automatiquement des fichiers PO (utile pour les plugins et styles), mais à l'évidence je n'aurais jamais le temps de le faire. De plus dans le cas de Luna la licence est un problème, POMO est sous GPL et Luna sous MIT… Je pense que je vais revenir en arrière et remplacer POMO par une version simplifiée basée directement sur Gettext.

@Mpok : c'est intéressant, mais particulièrement complexe… Je doute qu'on puisse mettre en place un système de plugin aussi avancé. Et dans un cas comme dans l'autre on dépend des développeurs : si un dev ne renseigne pas correctement les parties que son plugin affecte, le test de compatibilité sera erroné…

On peut éviter une part des conflits de plugins en incluant une priorité aux hooks : un plugin qui veut être certain d'agir avant les autres fera en sorte d'utiliser les hooks nécessaire avant les autres plugins. Mais à partir du moment où on laisse des développeurs tiers interagir avec le fonctionnement interne du logiciel, on doit accepter le risque de conflits comme inévitable. Personnellement j'ai tendance à penser qu'on devrait se limiter à offrir la possibilité technique sans se préoccuper des possibles conflits. C'est le rôle de l'administrateur d'un forum que de vérifier que plusieurs plugins qu'il veut utiliser fonctionnent correctement ensemble, et d'informer les développeurs en cas de pépin ; c'est alors aux développeurs de chercher une solution. Tenter de régler ça a priori au niveau du core me paraît à la fois incroyablement complexe et peu fiable.

adaur a écrit :

J'ai commencé la réécriture des requêtes avec Idiorm, c'est un ORM vraiment sympa à utiliser que je vous recommande.

Otomatic a écrit :

Je suis un « ancien », c'est vrai, mais il y a des moments où je ne comprends pas l'ajout de couches supplémentaires au code et où je me pose réellement la question : Pourquoi faire simple quand on peut faire compliqué.

Je ne suis pas non plus trop fan des ORM et autres surcouches SQL, Idiorm me paraît lourd à l'utilisation ; typiquement si je devais coder un plugin pour FeatherBB je n'utiliserai aucune fonctionnalité d'Idiorm, me contentant de coder et exécuter mes requêtes le plus simplement possible.

Mais les surcouches ont un certain intérêt tout de même. Un truc qui j'exècre sur FluxBB est la logique de while ( $row = $db->fetch_assoc( $result ) ) { ... }. Ça donne un code affreusement laid avec des boucles gigantesques et une compréhension peu intuitive ; un simple $rows = $db->fetchAll( $query ) serait largement plus pratique. Une surcouche peut ajouter ce type de fonctionnalités pratiques tout en offrant une abstraction utile pour le moteur derrière. Sans parler de la préparation des requêtes, niveau sécurité.

Maintenant, je pense que je vais partir sur mon propre fork également. Je vais laisser quelques mois aux concurrents pour évoluer et voir ce que cela donne, mais dans l'immédiat aucun des forks ne me convient. Luna s'est trop focalisé sur les fonctionnalités et le code interne reste dramatiquement vieillot ; FeatherBB prend une excellente directement au niveau du code mais repose trop sur des frameworks à mon goût − ce n'est pas une mauvaise ! Mais ce n'est pas ce que je voudrais utiliser sur mon forum − et Panther, je ne sais pas trop, je ne vois pas trop l'intérêt de ce fork. Le plus simple sera sans doute de faire ma propre tisane en voyant ce qui se fait de bien à côté smile

adaur · 24-07-2015 15:32:31

Je comprends ton choix, Askelon. J'utilise Doctrine pour mon travail (un peu) et franchement je trouve ça imbitable. La surcouche pour la surcouche a un résultat affreux, parfois plus de trois couches d’abstractions.

Le fait est qu'à partir du moment ou tu ne fais pas intervenir PDO: ou mysqli_ dans ton code, tu utilises déjà un ORM; FluxBB le fait de base. Par contre j'ai du mal à voir comment se passer de la boucle pour prendre en compte les résultats...

J'ai donc fait le choix de prendre la solution que je trouvais la plus simple pour effectuer des requêtes sans les écrire à la main. Panther a fait un choix intéressant, mais je trouve qu'il est encore complexe de modifier les requêtes dans l'optique de rajout de mods (ne serait-ce qu'une jointure par exemple). Je ne comprends pas bien l'optique de Luna. J'ai vu des commits pour les DB Layers mais ils ne me semblent être qu'un copier/coller des fichiers actuels de FluxBB ?

En ce qui concerne les traductions, mon choix n'est pas fixé... De ton expérience, gettext est-il disponible globalement, même sur de petites offres mutualisées?

Bonne chance pour ton fork aussi. J'aurais pensé pouvoir te fournir une solution intéressante, mais je comprends tout à fait que tu rechignes à utiliser un produit s'appuyant sur des solutions toutes faites. J'ai essayé de trouver un compromis entre temps passé à réinventer la roue et légèreté du script, mais si ce n'est toujours pas assez léger, j'en suis désolé wink .

https://aaronparecki.com/articles/2013/ … ment-stack

Dernière modification par adaur (24-07-2015 15:37:08)

Askelon · 24-07-2015 19:03:52

Oh, ce n'est pas fait hein ! Pour ce que j'en sais, dans 3 mois FeatherBB sera devenu exactement ce dont j'ai besoin wink Je me laisse quelques semaines/mois pour réfléchir − et de toute façon, dans l'immédiat, je n'ai absolument pas le temps

C'est une décision pragmatique, en fait : je commence à me dire que mes attentes sont très (trop) précises et m'empêchent de participer efficacement au développement d'un véritable fork public, que cela soit FeatherBB, Luna ou un autre. Mes contraintes biaisent le raisonnement et me poussent dans une direction qui n'est pas nécessairement la meilleure pour un logiciel de forum qui sera potentiellement utilisé par beaucoup de monde…

Par exemple j'ai entrepris hier de tester des classes utilisateurs, posts, topics et forums sur Luna, pour gérer les données sous forme d'objet. Le premier constat est que c'est très pratique : en chargeant une page de forum on obtient une liste d'objets, qui ne sont plus à charger à nouveau durant tout le processus de la page. Mais ça implique de lancer trois requêtes SQL au lieu d'une seule… Une requête pour récupérer tous les topics, une requête pour récupérer tous les posts liés, et une dernière requête pour récupérer les utilisateurs. L'avantage est que si un utilisateur a posté dans 10 topics de la page, on ne gère ses données qu'à un seul endroit ; l'inconvénient est qu'on multiplie les requêtes…

Dans mon cas précis, ça ne me pose aucun problème par rapport à l'aisance que ça apporte. Mais pour un forum qui se veut léger et rapide, ce n'est pas forcément indiqué… D'où l'évidence de plutôt devoir développer mon truc à ma sauce, selon mes besoins, plutôt que de polluer un autre projet ou de devoir ramer pour l'adapter à mes besoins smile Je ne compte pas rendre mon fork public, du moins pas officiellement. Il sera accessible, sous licence libre, mais ce ne sera a priori jamais un logiciel « officiel » comme Luna ou FeatherBB smile

adaur · 24-07-2015 21:28:16

OK, je vois! Si jamais tu voulais bien partager tes brouillons, je pense que ce serait très bénéfique pour Yannick, moi ou n'importe quel développeur enthousiaste smile

Il faudra que je retravaille le functions.php de toute façon, la liste de fonctions digne d'un inventaire à la Prévert n'est plus envisageable.

Au niveau des hooks, je pensais partir sur le système de WordPress (repo https://github.com/bainternet/PHP-Hooks ) mais j'ai vu que les 'hooks' n'étaient que le parent pauvre du pattern Observer... que je n'ai pas bien réussi à appréhender. Aurais-tu un avis sur la question, toi qui utilise fréquemment WP ?

A propos de la multiplication des requêtes, Idiorm propose un cache, ce qui peut être une piste intéressante je pense smile .

Askelon · 25-07-2015 00:11:50

Je suis loin d'être un expert, mais de ce que j'ai compris le pattern observer est un genre de système d'événements, comme on en trouve en JavaScript… Des objets qui envoient des notifications lors de changements et/ou réagissent aux changements d'autres objets. C'est un concept purement objet, qui est intéressant à utiliser dans le cadre de projets en POO pure ; j'imagine que c'est ce qu'utilise(ra) Flarum. C'est aussi ce qui explique que WordPress ne l'utilise pas smile

Je partagerai bien sûr les brouillons, pour le peu qu'ils vaudront !

Mpok · 05-08-2015 06:12:44

Ouah ! Ça bosse cet été ! smile

Askelon a écrit :

@Mpok : c'est intéressant, mais particulièrement complexe… Je doute qu'on puisse mettre en place un système de plugin aussi avancé. Et dans un cas comme dans l'autre on dépend des développeurs : si un dev ne renseigne pas correctement les parties que son plugin affecte, le test de compatibilité sera erroné…
On peut éviter une part des conflits de plugins en incluant une priorité aux hooks : un plugin qui veut être certain d'agir avant les autres fera en sorte d'utiliser les hooks nécessaire avant les autres plugins. Mais à partir du moment où on laisse des développeurs tiers interagir avec le fonctionnement interne du logiciel, on doit accepter le risque de conflits comme inévitable. Personnellement j'ai tendance à penser qu'on devrait se limiter à offrir la possibilité technique sans se préoccuper des possibles conflits. C'est le rôle de l'administrateur d'un forum que de vérifier que plusieurs plugins qu'il veut utiliser fonctionnent correctement ensemble, et d'informer les développeurs en cas de pépin ; c'est alors aux développeurs de chercher une solution. Tenter de régler ça a priori au niveau du core me paraît à la fois incroyablement complexe et peu fiable.

Il n'y a rien de complexe là-dedans… smile À partir du moment où tout le code est en POO, les plugins deviennent UNIQUEMENT des 'surcharges' de certaines fonctions. Et il est facile de tester les surcharges en "incompatilité potentielle"… (imo, il y a une table des fonctions et une table de leurs surcharges, cette dernière étant liée à celle des plugins).
=> Quand tu dis que c'est à l'admistrateur de décider, tu as raison, mais le meilleur moyen pour éviter ces incompatibilités est de mettre au moins un "warning" dès le développeur : "ce plugin entre en conflit avec xxx sur la fonction yyy". Il faut des tables pour cela.

adaur a écrit :

l faudra que je retravaille le functions.php de toute façon, la liste de fonctions digne d'un inventaire à la Prévert n'est plus envisageable.

LOL !! Ça , c'est clair : ce fichier est la "prrior target" pour toute 'rénovation'.

adaur a écrit :

Au niveau des hooks, je pensais partir sur le système de WordPress

En revanche, je suis moins d'accord avec toi là-dessus. C'est justement à cause de ce système trop "restrictif" que j'ai quitté WordPress. Mais "just my 5 cents", je n'ai pas testé très loin…

Askelon · 05-08-2015 09:57:52

Ok, en fait on ne parle pas vraiment de la même chose smile Je vois un système de plugin comme le moyen de charger mes propres codes sans devoir modifier le core, et interagir avec lui via les hooks ; ce n'est pas impérativement inscrit dans un contexte purement objet, donc pas de logique de classes/méthodes à surcharger. Donc pas besoin gestion de compatibilité. Mais c'est une façon d'appréhender le problème, ce n'est pas la seule et certainement pas la meilleure wink

Je ne suis pas un inconditionnel de l'objet, ça joue beaucoup. Le système de hooks de WordPress est efficace parce que WordPress n'est pas un logiciel basé sur une architecture objet ; personnellement j'apprécie ce côté, mais je comprends les critiques.

adaur · 12-08-2015 12:14:39

La Beta 2 est sortie!

http://featherbb.org/forums/topic/69/fe … 00-beta-2/

Au menu:

New DB Layer
Flash messages
BBCode editor
CSRF tokens
Cookie encryption improved
htaccess management improved

Pour la suite on verra, sans doute du gettext et des middlewares.

@Askelon: très sympa ce que tu es en train de faire sur Luna, c'est simplement dommage que chacun poursuive son travail dans son coin alors que les buts sont similaires.

Askelon · 13-08-2015 01:35:31

Oui hmm Comme le déplorait Franz, c'est dommage de voir le nombre de forks se multiplier d'un coup, l'énergie s'éparpille, alors que FluxBB 1.x aurait bien besoin d'un sérieux coup de balais…

Je code mon truc de mon côté parce que c'est inévitable, en fait. Luna et FeatherBB doivent faire des choix qui prennent en compte les demandes de beaucoup d'utilisateurs alors que je sais précisément quelles parties ne me serviront jamais à rien ; dans ce cas autant aller droit au but et coder directement ce dont j'ai besoin. J'ai pris Luna comme base de départ plutôt que FeatherBB parce que son développement est nettement moins avancé wink et donc plus simple à modeler selon mes besoins. Je veux faire et ajouter des trucs qui ne colleront pas dans Luna ou FeatherBB, ou qui demanderont beaucoup trop de boulot pour être réellement utilisables par tous ; dans l'immédiat j'ai un peu l'impression de réinventer la roue en reproduisant vaguement à ma sauce l'immense boulot que tu as abattu pour l'intégration de Slim, mais quand on va passer aux hooks et redécoupage complet de la base de données, ça sera tellement différent des autres projets que mieux vaut que je gère ça de mon côté en partageant avec vous les parties réutilisables sans polluer vos projets smile

Starcom · 04-09-2015 17:07:04

Bin moi je suis encore à 100 lieues d'avoir le niveau pour vous donner un coups de main et je venais râler parce que je n'avais pas l'impression que les forks annoncés se concrétisaient.

Et puis je suis tombé sur ce message qui m'a fait réaliser que je m'étais trompé.

Je souhaite longue vie à FeatherBB et bon courage à adaur et à tous ceux qui lui prêteront main forte.

J'aime toutes les idées que j'ai pu lire et je vous fait entièrement confiance sur les choix techniques que vous faîtes.

J'ai vraiment du mal à me faire à l'utilisation des forums comme Luna ou Vanilla que je trouve très pauvres visuellement (oui je suis contre toutes ces nouvelles interfaces épurées qu'on nous sort actuellement smile ), peut-être que ça me passera, mais disons que la perspective d'un vrai Fork de FluxBB me soulage.

Je réitère donc: longue vie à FeatherBB !! wink

adaur · 06-09-2015 01:03:00

Salut,

Merci beaucoup! Tout cela est possible grâce à capkokoon et beaver, qui contribuent beaucoup ces temps-ci. Si tu as regardé sur le GitHub, il y a eu énormément d'évolutions depuis la dernière bêta, avec presque autant de commits depuis cette dernière que depuis le début du projet.

Je reviens vous donner plus d'informations quand la Beta 3 sortira wink

Mpok · 11-09-2015 11:54:18

La base me semble bonne, même si je n'ai testé que le code en ligne. La partie "DB Layer" m'a agréablement surpris… smile
Go on guys !

adaur · 11-09-2015 15:46:48

Merci mpok! On a justement sorti la beta 3 avant-hier, qui commence doucement à se rapprocher de ce qu'on voudrait atteindre niveau POO. La beta 4 sera plus axée sur les hooks et les divers plugins, on espère tendre vers une espèce de marketplace à la WP.

FluxBB.fr

#26 11-07-2015 12:19:12

Re : FeatherBB, un fork de FluxBB au début de son développement

#27 13-07-2015 22:26:45

Re : FeatherBB, un fork de FluxBB au début de son développement

#28 18-07-2015 23:28:55

Re : FeatherBB, un fork de FluxBB au début de son développement

#29 19-07-2015 16:29:35

Re : FeatherBB, un fork de FluxBB au début de son développement

#30 19-07-2015 23:44:56

Re : FeatherBB, un fork de FluxBB au début de son développement

#31 20-07-2015 08:08:55

Re : FeatherBB, un fork de FluxBB au début de son développement

#32 21-07-2015 00:56:59

Re : FeatherBB, un fork de FluxBB au début de son développement

#33 21-07-2015 01:21:14

Re : FeatherBB, un fork de FluxBB au début de son développement

#34 23-07-2015 15:00:00

Re : FeatherBB, un fork de FluxBB au début de son développement

#35 23-07-2015 21:43:38

Re : FeatherBB, un fork de FluxBB au début de son développement

#36 24-07-2015 09:50:22

Re : FeatherBB, un fork de FluxBB au début de son développement

#37 24-07-2015 11:28:47

Re : FeatherBB, un fork de FluxBB au début de son développement

#38 24-07-2015 11:50:07

Re : FeatherBB, un fork de FluxBB au début de son développement

#39 24-07-2015 15:32:31

Re : FeatherBB, un fork de FluxBB au début de son développement

#40 24-07-2015 19:03:52

Re : FeatherBB, un fork de FluxBB au début de son développement

#41 24-07-2015 21:28:16

Re : FeatherBB, un fork de FluxBB au début de son développement

#42 25-07-2015 00:11:50

Re : FeatherBB, un fork de FluxBB au début de son développement

#43 05-08-2015 06:12:44

Re : FeatherBB, un fork de FluxBB au début de son développement

#44 05-08-2015 09:57:52

Re : FeatherBB, un fork de FluxBB au début de son développement

#45 12-08-2015 12:14:39

Re : FeatherBB, un fork de FluxBB au début de son développement

#46 13-08-2015 01:35:31

Re : FeatherBB, un fork de FluxBB au début de son développement

#47 04-09-2015 17:07:04

Re : FeatherBB, un fork de FluxBB au début de son développement

#48 06-09-2015 01:03:00

Re : FeatherBB, un fork de FluxBB au début de son développement

#49 11-09-2015 11:54:18

Re : FeatherBB, un fork de FluxBB au début de son développement

#50 11-09-2015 15:46:48

Re : FeatherBB, un fork de FluxBB au début de son développement

Pied de page des forums