Reprise du message précédent :
C'est parfaitement possible de faire des modules pour le forum MD, j'en avais même fait un pour mes tests, c'est même plus facile que sur les autres forums où on vous jette un code source à la figure sans rien expliquer. MD a un SDK très simple à utiliser pour faire ce qu'on veut.

Vla la pub

Spa de la pub, c'est juste pour éviter la désinformation.

d'un autre coté, de la pub dans un topic de developpeur de forum, c'est pas le meilleur endroit pour trouver des clients
 

 
Ah? Revirement de politique de MD? Motivé par des demandes de clients ou évolution logique de l'offre?

évolution logique, le coeur est crypté, mais accessible via des fonctions documentées, le HTML et le PHP de base lui est accessible, donc tu peux faire ce que tu veux.

c'est pas nouveau  
maintenant c'est vrai que c'est un plus de pouvoir personnaliser un forum payant, je ne sais pas si y'a des concurrents à MD et s'ils proposent le même niveau de personnalisation

c'est l'effet "clubic"
 

En gros, tu penses à un systéme comme pour le forum aufeminin.com ou ubix.org (que je trouve bien mieux fait que l'autre)
C'est marrant, mais il y a un an ou deux, on m'avait déconseillé de partir sur cette voie et de rester plustôt avec un forum à la MD (les messages se suivent sans arborescence entre eux)
 
Concernant les plugin, vu que c'est le sujet actuel, personellement, mon site entié est basé sur le principe des modules/plugins. En fait, c'est surtout que pour ne pas réécrire 10 fois les même fonctionalité, j'ai fait mon site de maniére à ce qu'une partie d'un module puisse être utilisé par un autre comme s'il avait à faire à un plugin. Par contre je n'ai pas fait un vrai systéme de plugin dans le sens où un module ne peut pas inclure un plugin qui n'était pas prévus : je vérais peut être plus tard pour ça vu que je ne vois pas comment faire sans perdre beaucoup en temps d'exécution.
 
Au fait, pour le sondage d'il y a quelques temps, je n'ai pas laissé tombé mon forum ... mais je n'ai quasiment plus de temps à y consacré alors ca avance quasiment pas.

ben par rapport à mon post d'il y'a quelques temps, ça a un peu changé! Ma copine (enfin,  mon ex maintenant) m'a débloqué plein de temps libre (un peu à l'insu de mon plein gré faut bien avouer)... Du coup, je suis en pleine campagne de débuggage intensif pour la dernière version! Et des bugs, y'en a ce qu'il faut.

perso, je suis un peu trop perfectionniste, je n'arrive pas a faire une autre option tant que les bugs existant ne sont pas corrigé (les bug connu), et ca me prend grave du temps a cause de ca    
 
par contre, j'ai rarement de bug quand j'ai fini la version a mettre en prod, c'est un avantage.
 
Sinon, j'ai envie de faire comme avec les voitures, faire un "concept forum", c'est a dire de faire ce qui me passe par la tete sans faire gaffe a la securité, a l'optimisation, ni aux bug, juste une version pour tester des options sans se prendre la tete, mais je me demande si c'est vraiment efficace et si ca sert a quelque chose? j'ai aussi peur de prendre de mauvaise habitude en baclant le dev...
vous en pensez quoi ?

ca s'appelle phpbb, non ?

lol, j'y avais pensé, mais je n'ai pas osé le dire
 

y'avait longtemps!

Bon, je laisse tomber les plugins, je ferai des modules (plus ou moins) indépendants mais complètement intégrés, comme j'avais prévu de le faire au départ

T'as repris les devs de ton forum, drasche?

Non, je laisse tomber ce forum tel quel. J'ai entamé un nouveau projet sur des bases plus saines

ben et spacegeeks alors?
 
 
bon, sinon je passais pour faire un ptit sondage pour savoir, en gros, quelles étaient les techniques utilisées pour la mise en place des features style "drapeaux". A vos claviers merci

Ca rentre dans le même cadre. SG est en développement. Ceci concerne des projets annexes.

ok

au cas ou, hein

de quelle technique tu parle? pour les drapeaux suffit juste d'une table drapeau
Ensuite quand t'affiche la liste des sujet tu recupere les drapeaux du membre.
 
Pourquoi? tu fais un forum?
 

ben, de ça, seulement j'esperais une réponse un poil plus précise, et éventuellement voir s'il y avait d'autres idées, donc.
toi, en gros tu fais genre  
* un SELECT thread_id, status FROM user_threads WHERE user_id='Fabien', au moment d'afficher, donc cette grosse (mais rapide) requete a chaque affichage de liste de topic;
* ou une jointure plus serrée dans la requete qui te renvoie la liste de topics;
* ou encore une micro requete pour chaque topic affiché (...AND thread_id='le thread que je vais bientot lister')  
 
?
 

moi je cherche tout les drapeaux corespondant au topic et au membre, ensuite je met la valeur dans un tableau avec comme indice l'id du topic, et ensuite j'affiche si le drapeaux existe pour l'id du sujet.
Bien sur, je limite le nombre maximum pour un membre, sinon on pourrait se retrouver avec 1000 drapeaux a gerer par membre.
Enfin, ma methode est pas tres bonne, car j'ai un flag "on/off" dans la table drapeau, alors qu'il serait mieux de comparer les id pour savoir si le id_drapeau=dernier_id_topic
 

moi c'est simple, pour chaque page de sujet, je fais une jointure avec la tagle flag de l'utilisateur, sur l'id du topic. J'en récupère l'id du dernier message lu, et dans la boucle d'affichage, je compare avec le dernier id du sujet.

et pour la distinction "rouge/vert", t'as un champ genre status dans ta table de flags?

Yep, j'ai exactement :
topicId, userWrittenIn, lastPostRead
 
je récupère userWrittenIn, et lastPostRead, que je traite dans ma boucle d'affichage PHP.
userWritten est initialisé à 0 pour toute lecture d'un sujet, et passe à 1 dès qu'il participe.
Dès qu'il supprime un de ses messages, je reparcoure toute la table des messages du sujet pour voir s'il a d'autres message. Si non, je remet cette valeur à 0
(c'est un peu lourd, mais il y a beaucoup moins de suppression que d'ajout de messages / consultations du sujet).

bon ben reste a trouver la bonne idée pour faire rentrer ça dans un jcr

Moi je fais "idmembre,idtopic,status,lastrep,lastreadtime", comme ça, je ne limite pas les drapeaux mais si je veux, je peux virer les drapeaux qui ont 6 mois.
status chez moi, c'est 1=>Lu, 2=>Lu et nouvelle réponse, 3=> participé, 4=> participé et nouvelle réponse.
En théorie, parce qu'en pratique, je les ai jamais vidé sur mon forum perso, ça prend 12Ko pour 230000 enregistrements (Les indexs prennent + de place que les données), pas de quoi fouetter un chat.
 

quel est l'interet de tes status 2 et 4 si tu stockes l'id de la derniere reponse lue? (et quand ceux-ci sont ils mis a jour??)

Pouvoir récupérer le status sans être obligé de faire une comparaison avec les réponses du sujet en question, comme de toutes façons MySQL ne possède pas de stockage booléen, autant se servir de ce qu'on a.
Quand quelqu'un poste, je fais 2 update, status=2 WHERE idtopic=topiccourant AND status=1 et status=4 WHERE idtopic=topiccourant AND status=3.

J'peux aussi virer les drapeaux de plus de 6 mois, suffit de récuperer l'id du post datant de 6 mois, et de faire un delete des drapeaux avec un id inférieur.
Sinon, theShadow -> je vois pas trop l'intérêt, à part une condition en plus lors de l'ajout d'une réponse.
 
Et MySQL ne possède peut-être pas de type "booléen", mais a le type "enum" qui peut prendre 2 valeurs (ou plus selon tes envies) prédéfinies.

Parce que je préfère perdre un peu de bdd quand on poste un message et gagner en vitesse à l'affichage des topics, opération au combien plus fréquente.
Après, je dis pas que c'est ce qu'il y a de mieux, je dis juste comment je fais sur mon forum perso.
Les champs enum ne font rien gagné en stockage ou en vitesse face à un tinyint unsigned.
Cela dit, faudrais peut-être que je revois ça effectivement.

On a sensiblement la même chose :
Toi : 4 états différents, qui indiquent une chose, mais un test BDD pour savoir quoi mettre à jour.
Moi : 2 x 2 états différents, juste un test à l'affichage pour savoir quoi afficher (un = )

Le type BIT existe avec MySQL 5

bonjour tout le monde
 
Je voulais savoir, est ce que vous avez penser a securiser la connexion de membre? car le mot de passe est transféré en clair sur le reseau, faudrait un systeme pour qu'il passe en crypté.

Est-ce bien necessaire? Il s'agit d'un forum. Pas d'un acces à des données bancaires.

oué mais bon, si un admin ou modo se fait piquer le mdp, ca peut faire mal.
 
Et puis un forum avec des failles qui se fait hacker tous les jours c pas terrible, faut quand meme penser a la securité meme si c'est pas une banque.
 
 

Fabien > De toute maniére, même si tu criptes le mot de passe en javascript, celui qui intercepte l'envoie du mot de passe (sniffer) pourra se conecter sans aucun probléme (il lui suffira d'envoyer la version cripté)
Quand à celui qui obtient le mot de passe d'une autre maniére (par exemple une faille qui permet de voir le mot de passe en clair de n'importe quel inscrit) il lui suffira d'utiliser la page de conection habituelle.
 
En fait, la seule solution fiable c'est de passer par un serveur en https mais là, il ne s'agit plus de programmation mais d'administration serveur.

 
Il faut tout de même qu'un type vienne volontairement intercepter le mot de passe en clair saisi par le modo à un instant T. Sinon, https pour la saisie du mot de passe et voilà. Mais je ne considere pas ca comme une faille. Il faut adapter le besoin à la securité.

oué, ca j'y ai pensé que le cryptage ne servait pas a grand chose, et en fait faudrait un clé unique de cryptage du mdp qui change a chaque chargement de page (dans la page login), un peu le systeme des "codes images" qu'il faut saisir pour eviter qu'un bot post.
 
exemple:
clée de cryptage "XDCFV" id "123"
 
on créé le formulaire avec ces données en hidden par exemple, ensuite on envoye le login, mdp crypté et l'id du cryptage. Ensuite au moment de la verification sur le serveur, on cherche dans la bdd la clée de cryptage qui corespond a l'id 123 et ensuite on supprime la clé de la base.
 
le seul inconveniant c'est qu'il faut utiliser javascript et ce n'est pas tres fiable comme language car on n'a pas le controle sur la configuration des navigateurs, pour palier a cela, il faudrait a l'aide javascript mettre un champ hidden pour dire si le javascript est actif ou pas: si javascript arrive a ecrire ce champ, c'est qu'il est activé, sinon on verifie le mdp en clair.  
On pourait ajouter le champ hidden "id" grace javascript et si celui ci n'est pas envoyé avec le formulaire ca veut dire que js n'est pas activé.
 
Voila la theorie, faudrait essayer en pratique.