Le site des utilisateurs francophones de FluxBB.
Vous n'êtes pas identifié(e).
Bonjour,
Ayant (enfin) un peu plus de temps libre, je peux me consacrer au développement d'un fork de FluxBB: FeatherBB. Pourquoi ce nom? C'est très simple: en anglais, Feather est une plume... FeatherBB sera aussi léger qu'une plume sur un serveur, tout comme FluxBB l'est déjà.
Alors, pourquoi forker? Simplement pour faire ce que FluxBB 2.0 aurait du être: pas un amas de frameworks les uns sur les autres avec du JS à gogo, mais un code simple, efficace et léger adoptant les conventions de développement actuelles. C'est à dire une séparation claire du code HTML et du traitement PHP (modèle MVC), de la PDO pour les requêtes SQL et de la POO pour le reste, permettant de rajouter un système d'extension simple et fonctionnel.
Je viens juste de démarrer, je vais commencer par basculer FluxBB en MVC procédural pour commencer, puis mettre de la PDO et enfin basculer en POO. Toutes ces technologies sont nouvelles pour moi, aussi le développement de FeatherBB sera l'occasion d'apprendre ces méthodes.
Vous pouvez suivre le développement sur featherbb.org, vous êtes bien sûr plus que bienvenus si vous désirez participer au développement de FeatherBB.
Pour l'instant, j'ai séparé le code dans index.php, je fais les autres fichiers en suivant.
A bientôt!
https://github.com/featherbb/featherbb
Dernière modification par adaur (02-06-2015 12:05:32)
Hors ligne
Bonjour,
Bonne initiative. Bon courage et longue vie à FeatherBB.
Autant j'étais opposé à FluxBB 2.0 Laravel et encore plus Flarum, autant à partir du moment où on reste dans la même optique de simplicité et de légèreté, je suis preneur et suiveur.
Bien sûr, je suis prêt à continuer mes mod et plugin pour les adapter à FeatherBB ; je suis un vieux programmeur élevé à la sauce séquentielle avec un soupçon d'événementiel. J'ai quelques difficultés à me faire à la POO bien que j'en reconnaisse les bienfaits, par exemple avec ma class mysqli, d'ailleurs inspirée de celle de FluxBB.
Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi
Sont différents : ça et sa - est et ait - à et a - ce et se - mes et mais ou met - été et était - c'est et ces - ce-si et ceci
La vie sans musique est tout simplement une erreur, une fatigue, un exil. Friedrich Nietzsche
Hors ligne
Super initiative ! Je suivrais ça en parallèle de Luna qui avance bien également. Il y aura peut-être des idées à partager entre les deux projets.
Hors ligne
Merci à vous deux !
Askelon si tu veux contribuer surtout n'hésite pas...
Luna est vraiment prometteur mais trop lourd à mon goût, assez éloigné de l'esprit fluxbb. Étant novice en mvc, j'apprécierais d'avoir ton avis sur ce que je fais, s'il y a des écueils à éviter
Hors ligne
Houla, je suis tout sauf un expert en POO, et encore moins en MVC, je n'ai que des bases apprises sur le tas... Mais je participerai si je vois quelque chose à ajouter :-)
Hors ligne
Salut,
Belle initiative. Bon courage.
Je suis pas expert non plus en MVC/POO, mais j'essaie
J'y jetterai un œil de temps en temps...
Bouh !
StarShip Renaissance
Hors ligne
Bonjour,
Je pourrais le faire, mais je préfère demander à Mpok si la création d'une catégorie FeatherBB avec, au moins, une rubrique développement pourrait être envisagée sur ce forum - à moins que cela soit prématuré.
Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi
Sont différents : ça et sa - est et ait - à et a - ce et se - mes et mais ou met - été et était - c'est et ces - ce-si et ceci
La vie sans musique est tout simplement une erreur, une fatigue, un exil. Friedrich Nietzsche
Hors ligne
Salut,
Je te conseil un framework très léger http://www.slimframework.com
Très utile pour faire une MVC propre.
Tu peux utiliser des moteurs de template avec (genre smarty, twig etc)
Hors ligne
Il me semble que l'idée est justement de ne pas utiliser de framework.
Hors ligne
Il me semble que l'idée est justement de ne pas utiliser de framework.
C'est une suggestion, pour faire une MVC vraiment clean sans superflus slimframework est parfait.
Il serait vraiment appréciable aussi de respecter les standards psr-1 et 2 pour le "coding style"
Par exemple les tabulations tab, les remplacer par 4 espaces etc
Toutes les normes psr ici : http://www.php-fig.org/
Dernière modification par Magicalex (05-06-2015 00:47:54)
Hors ligne
Je confirme, j'utilise Slim pour certains de mes projets. Je précisais simplement parce que l'une des causes de désaccord autour de FluxBB 2.0/Flarum est justement l'utilisation d'un framework (certes plus lourd).
Pour ce qui est de FeatherBB je pense que la priorité, avant même de redécouper le code ou d'introduire de l'objet, va déjà être de définir clairement un modèle de développement pour permettre facilement la création de plugins. 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 ; pour qu'il soit utilisable par quiconque en dehors d'une poignée de développeur il va falloir un système de plugins simples à coder et utiliser. C'est quelque chose qu'il vaut mieux fixer précisément avant de commencer le gros du développement si on veut éviter une usine à gaz par la suite
Hors ligne
+1 à vous tous.
En effet, je ne souhaite pas utiliser de framework car j'en avais l'image d'outils très lourds (Symfony) et inadaptés à l'esprit léger de FluxBB. Je ne voulais pas non plus être dépendant d'un tiers.
Cependant, je ne suis pas totalement borné non plus: si je me rends compte qu'il est impossible de faire quelque chose de propre à la main, je ne m'interdis pas de passer par Slim (qui paraît très léger pour le coup) ou un autre fw qui soit en accord avec la philosophie du projet.
Je termine la séparation du code pour l'instant (étape de toute façon indispensable, qu'on veuille passer par un fw ou pas), mais tu as raison de souligner l'importance des mods dans un CMS léger. Je pensais implémenter un système de plugins/hooks comme sur WordPress, qui a l'air de bien fonctionner depuis des années; la séparation code/affichage devrait aider à l'implémentation de fonctions à des endroits stratégiques, le but étant d'installer une mod avec un copier/coller dans un dossier.
En ce qui concerne l'utilisation par une poignée de développeurs, c'est un grand souci pour moi: je ne veux absolument pas faire un système incompréhensible quand on regarde son code pour la première fois, en se demandant où est l'affichage, le code, où se situe telle fonction... il me semble que c'est l'esprit FluxBB aussi: un code super simple à comprendre (et modifier mais normalement ce ne sera plus la peine).
Hors ligne
Cependant, je ne suis pas totalement borné non plus: si je me rends compte qu'il est impossible de faire quelque chose de propre à la main, je ne m'interdis pas de passer par Slim (qui paraît très léger pour le coup) ou un autre fw qui soit en accord avec la philosophie du projet.
C'est pas impossible de faire quelque chose de propre à la main, mais ça te prendra pas mal de temps.
Un exemple avec le router de slim.
<?php
require 'vendor/autoload.php'
$app = new \Slim\Slim([
'templates.path' => './view'
]);
$app->get('/viewtopic/:id', function ($id) use ($app) {
$app->render('viewtopic.php', ['id' => $id, 'title' => $title]);
});
En micro-framework y a slim, lumen (laravel) et silex (symfony) qui se distinguent.
Slim a comme principal différence d'avoir moins de dépendance. (ps: la v3 de slim est en développement)
Dernière modification par Magicalex (05-06-2015 12:20:05)
Hors ligne
Hors ligne
Je me suis un peu renseigné sur Slim, de ce que j'en ai compris il permettrait de faire de l'URL rewriting nativement. Cela paraît effectivement un bon compromis entre légèreté et propreté du code. Je peux encore changer d'avis d'ici là, mais il est possible que je l'utilise.
Hors ligne
Bonjour,
Si je comprend bien il va falloir faire un choix entre fluxbb revisité par FeatherBB, ou flarum ?
Cordialement,
Hors ligne
FeatherBB, Flarum, FluxBB 1.x si le développement continue, et tous les autres forks qui vont se lancer durant les prochains mois/années. Ça promet de bonnes soirées benchmark
Par contre adaur, je crois que la priorité absolues va être de porter un mod d'antispam, ça a l'air d'être déjà la folie...
Hors ligne
Pas mal d'avancées!
Les fichiers sont séparés (reste header/footer, éventuellement functions?), j'ai porté la mod d'Otomatic pour l'antispam ainsi qu'un système qui permet de générer à la volée le champ du nom d'utilisateur et échec de l'inscription si un champ "username" ou "password" est rempli automatiquement.
FeatherBB est également compatible SQlite3.
L'inscription a été simplifiée: plus besoin de remplir de champ horaire ou de préférence de vie privée, qui restent accessible via le profil.
Des { } ont été rajoutés partout pour faciliter la modification du code en cas de condition sur une seule ligne.
Hors ligne
... j'ai porté la mod d'Otomatic pour l'antispam...
Chouette du boulot en moins !
Lorsque tu penseras que l'on peut commencer à tester, mets un lien sur le « paquetage » ; je suis partant.
NB : J'aimerais bien que Mpok ouvre une catégorie FeatherBB (Développement)
Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi
Sont différents : ça et sa - est et ait - à et a - ce et se - mes et mais ou met - été et était - c'est et ces - ce-si et ceci
La vie sans musique est tout simplement une erreur, une fatigue, un exil. Friedrich Nietzsche
Hors ligne
Ravi que cela te plaise!
Je n'ai aucune visibilité de date pour l'instant, le plus gros du travail (POO) restant devant moi, je ne sais pas si je prendrai 3 mois (plus?) ou deux semaines...
En attendant, tu as une version très récente ici http://featherbb.org/forums/index.php et le GitHub est actualisé dès que mon forum local tourne sans être cassé .
Hors ligne
Bonjour,
Pour PHP 7, mysql n'existe plus ; il faut utiliser mysqli ou PDO_mysql.
De plus la fonction constructor ne peut plus avoir le même nom la class, donc, dans include\dblayer\mysqli.php, remplacer
function DBLayer($db_host, $db_username, $db_password, $db_name, $db_prefix, $p_connect)
par
function __construct($db_host, $db_username, $db_password, $db_name, $db_prefix, $p_connect)
Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi
Sont différents : ça et sa - est et ait - à et a - ce et se - mes et mais ou met - été et était - c'est et ces - ce-si et ceci
La vie sans musique est tout simplement une erreur, une fatigue, un exil. Friedrich Nietzsche
Hors ligne
Cela a été implémenté, merci Otomatic!
Sinon, j'avance à mon rythme. J'ai pris la décision d'utiliser SlimFramework. J'ai bien conscience que c'est un revirement de situation par rapport à mes premiers posts, mais en creusant la question, il m'est apparu que c'était la solution évidente: il est très léger comme Flux (performances excellentes), n'a rien d'"inutile" comparé à des monstres comme Symfony ou Laravel, ne nécessite pas une réécriture monstre du programme pour fonctionner. Surtout, il permet de faire de la MVC de façon très propre et très simple.
Je vous invite à voir la façon dont il fonctionne ici: https://github.com/featherbb/featherbb/tree/development
Il s'agit d'un premier jet: les erreurs ne sont pas encore gérées, l'URL rewriting fonctionne partiellement (URLs accessibles directement mais pas générées proprement par le forum directement).
En revanche, il produit déjà des URLs très propres du genre:
Et surtout, j'utilise maintenant un système de routes; index.php:
<?php
/**
* Copyright (C) 2015 FeatherBB
* based on code by (C) 2008-2012 FluxBB
* and Rickard Andersson (C) 2002-2008 PunBB
* License: http://www.gnu.org/licenses/gpl.html GPL version 2 or higher
*/
// Load Slim Framework
require 'Slim/Slim.php';
\Slim\Slim::registerAutoloader();
// Load FeatherBB
define('PUN_ROOT', dirname(__FILE__).'/');
require PUN_ROOT.'include/common.php';
// Instantiate Slim and specify where to load the views
$feather = new \Slim\Slim([
'templates.path' => get_path_view(),
'debug' => true, // As long as we're developing FeatherBB
]);
// Load the routes
require PUN_ROOT.'route/users.php';
// Run it, baby!
$feather->run();
Les routes ressemblent à
// Index
$feather->get('/', '\controller\Index:display');
// Viewforum
$feather->get('/forum/:id/:name/page/:page(/)', '\controller\Viewforum:display')->conditions(array('id' => '[0-9]+', 'page' => '[0-9]+'));
$feather->get('/forum/:id/:name(/)', '\controller\Viewforum:display')->conditions(array('id' => '[0-9]+'));
$feather->get('/forum/:id(/)', '\controller\Viewforum:display')->conditions(array('id' => '[0-9]+'));
// Viewtopic
$feather->get('/topic/:id/:name/page/:page(/)', '\controller\Viewtopic:display')->conditions(array('id' => '[0-9]+', 'page' => '[0-9]+'));
$feather->get('/topic/:id/:name(/)', '\controller\Viewtopic:display')->conditions(array('id' => '[0-9]+'));
$feather->get('/topic/:id(/)', '\controller\Viewtopic:display')->conditions(array('id' => '[0-9]+'));
Il est sûrement possible de les compacter, je verrai ça par la suite. Les classes en elles-mêmes sont pour l'instant perfectibles.
Ces routes appellent des classes+fonctions (syntaxe Classe:fonction, passant en paramètre :id => $id par exemple) dans le dossier controller, qui font elles-même appel au modèle et à la vue => MVC
J'espère que vous me pardonnerez l'utilisation de Slim :ange:
Dernière modification par adaur (16-06-2015 23:05:08)
Hors ligne
Bonjour,
Juste une petite remarque qui n'est pas directement liée à Featherbb.
En local, il faudrait utiliser les VirtualHost de manière à ne pas ajouter le niveau 'localhost' dans les url.
Extrait de mes explications sur le forum Wampserver
Lancer ses sites locaux par (http://localhost/projet1/) ou (http://localhost/projet2/) n'est ABSOLUMENT PAS une bonne solution, c'est même quelque chose à bannir totalement et définitivement.
En effet, vous introduisez un niveau supplémentaire "localhost/" dans les url d'accès à vos sites locaux ce qui fait que beaucoup de variables prédéfinies par le serveur HTTP, par exemple des éléments du tableau $_SERVER['xxx'] n'auront pas les bonnes valeurs.
Par exemple, pour un projet wamp/www/mon-projet/
Avec l'appel tel qu'il devrait être : (http://mon-projet/) voici les valeurs de quelques éléments prédéfinis
$_SERVER['HTTP_HOST'] = mon-projet
$_SERVER['SERVER_NAME'] = mon-projet
$_SERVER['DOCUMENT_ROOT'] =C:/wamp/www/mon-projet
Et voilà quels sont les mêmes éléments prédéfinis avec (http://localhost/mon-projet/)
$_SERVER['HTTP_HOST'] = localhost
$_SERVER['SERVER_NAME'] = localhost
$_SERVER['DOCUMENT_ROOT'] =C:/wamp/www
Vous pouvez voir, entre autres, que le chemin d'accès au dossier racine du projet ($_SERVER['DOCUMENT_ROOT']) n'est pas le bon chemin. et, en plus, ce sera TOUJOURS C:/wamp/www quel que soit le projet lancé de cette manière.
Ces valeurs erronées vont - à coup sûr - induire des erreurs incompréhensibles avec des Frameworks, des CMS ou des applications web que vous ajouterez à vos projets, par exemple Wordpress ou Joomla ; mais ce ne sont pas les seules.
Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi
Sont différents : ça et sa - est et ait - à et a - ce et se - mes et mais ou met - été et était - c'est et ces - ce-si et ceci
La vie sans musique est tout simplement une erreur, une fatigue, un exil. Friedrich Nietzsche
Hors ligne
@Otomatic je suis absolument pas d'accord avec toi. C'est juste que t'as pas configuré les uri correctement.
Apache renvoie des valeurs par défaut lorsque ce n'est pas configuré. C'est pas la faute du programme autant que tel.
Si tu mets dans ton .htaccess DocumentRoot /le/chemin/du/projet tu n'auras pas ce genre de comportement par exemple.
Le mieux bien entendu est de laisser tomber apache pour nginx bien sûr
Dernière modification par Magicalex (07-07-2015 01:24:23)
Hors ligne
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.
Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi
Sont différents : ça et sa - est et ait - à et a - ce et se - mes et mais ou met - été et était - c'est et ces - ce-si et ceci
La vie sans musique est tout simplement une erreur, une fatigue, un exil. Friedrich Nietzsche
Hors ligne