Sékiltoyai > Effectivement, pour avoir regarder le svn, beaucoup de choses sont déjà faites.

BlackJowy > Du fait qu'il n'a pas de temps, c'est une raison de plus pour essayer de se bouger autour de lui, non ? Qu'il y ait, ou pas, d'équipe de programmeurs officiels, ça n'empêche personne à préparer des fichiers patch et à les envoyer à Génova (soit en rassemblant nos forces en s'organisant pour limiter le nombre d'envois, soit en travaillant chacun de son côté) pour lui faciliter la tâche. Ainsi, s'il arrive à trouver un peu de temps, tout sera nettement plus rapide à publier pour lui. Je ne vois pas en quoi cela nécessite un quelconque aval de sa part, tant que personne ne se met à publier des releases sans son autorisation... (Et encore, FSB est libre, non ? Sous GPL si je ne me trompe pas ? Ce qui signifie que le travail dérivé, publication comprise, est autorisé à condition de conserver la licence initiale.)

Enfin bref, je maintiens qu'il serait idéal d'essayer de l'aider.

Et y'a pas un seul développeur dans le coin qui a un peu de temps à revendre pour faire avancer le projet ? Personne qui veut bien se faufiler sur le svn ( http://trac2.assembla.com/fsb2 pour le trac, http://svn2.assembla.com/svn/fsb2/ pour le svn direct (si je me trompe pas ^^) ) et envoyer une série de patch à Génova ? Allez, aidons-le un peu ^^ Si il voit la foule lui envoyer des .patch tout prêt avec juste un clic pour appliquer, ça le remotivera peut-être

Pourquoi pas faire l'inverse ? Un petit test sur REQUEST_URI, on retrouve facilement si c'est appelé sans le index.php, et dans ce cas, on redirige l'utilisateur vers index.php. Non ?

Un genre de :


Comme ça, on résout le problème de dissolution du PR tout en permettant le changement de DirectoryIndex (que je pratique personnellement, m'enfin), et en plus, on a qu'une seule ligne de code à rajouter.

Oui ^^

Ah, tant mieux si c'est bientôt

Parce que pour le cache, c'est problématique j'ai du publier un fix en provenance de la version svn pour mes clients c'était devenu insoutenable sans APC.

M'enfin, fais au mieux, et encore merci pour ton travail, c'est vraiment un super programme, sur tous les plans, tant niveau code que niveau expérience utilisateur

Ou alors, il faudrait créer une whitelist des redirections autorisés. Un peu à la manière de crossdomain.xml en flash (il me semble que c'est ainsi que sont gérés les domaines différents).

M'enfin, le hash unique étant géré au cas par cas, ce n'est peut-être pas si important que ça

Bonne chance à Génova ^^

Salut,

Je ne sais pas si ça a déjà été proposé, mais il serait interessant de formater les nombres dans les statistiques en bas du forum (number_format). Dans ce cas, il faudrait également proposer une option pour configurer le formatage dans l'administration, afin que le forum soit prêt pour l'internationalisation (pour rappel, en france, on a un espace tous les 3 chiffres tandis qu'aux USA on a une virgule). Cela permettrait une lecture plus aisée des grands nombres.

C'est un détail certe, mais pour les gros forums, les nombres seront bien plus agréable à lire.

cya

Justement.

Serveur Cache : 0.0.0.1
Serveur Web 1 : 0.0.0.2
Serveur Web 2 : 0.0.0.3

Client 1 Serveur 0.0.0.2 :
/var/www/client1/ => Stocké sur 0.0.0.1
Client 1 Serveur 0.0.0.3 :
/var/www/client1/ => Stocké sur 0.0.0.1

On a donc un conflit

Ah, et, autre raison, dans le cas où une implémentation de Memcached serait faite (ça serait d'ailleurs une bonne idée, c'est tout aussi répandu que Turck MMCache), plusieurs serveurs peuvent pointer sur le même serveur de cache, et donc les path absolus peuvent se confondre.

Le MD5 de la config est préférable je pense. Dans certaines configurations, le path absolu est chrooté (c'est à dire que deux hébergés peuvent, en apparence, avoir le même path absolu).

Le truc en fait, c'est que pour le SDK ça va poser problème si c'est basé sur les variables de type SCRIPT_URI, SCRIPT_FILENAME, PHP_SELF, etc... Il faudrait plutôt se baser sur le DOCUMENT_ROOT de l'installation du forum, et non pas sur celui du fichier courant.

Edit: Oui, c'est une bonne idée. De plus, ça me semble simple à mettre en oeuvre.

Je n'ai pas testé, mais j'ai regardé le code, et ça ne sera toujours pas bon.

Tu généres ta clef unique avec le nom du répertoire courant. Or, si j'utilise FSB via mon site web, le répertoire change, et le cache devient inactif. De plus, je peux également avoir plusieurs domaines sur le même serveur. Donc si mes forums sont les suivant :
- http://site1.com/forum/
- http://site2.com/forum/
Leurs caches seront confondus, et le problème toujours présent.

Je propose donc de se baser sur la configuration plutôt que sur $_SERVER['PHP_SELF'].

Bon courage

Ok, me voilà rassuré. Je laisserai donc APC désactivé en attendant.
Merci d'avance, et en passant, bravo pour le forum (code comme expérience utilisateur), la version final est plus qu'à la hauteur de ce que j'esperai

Hum, et je suppose qu'est stocké dans APC le cache des templates également ?
Parce que je gére un serveur, et il s'avère que deux forums ont vu leurs templates complétement débloquer. L'un avait le header de l'autre, et ce pour plusieurs pièces du thème... Je vais donc regarder comment cela est géré dans FSB, et si c'est bien ce que je pense, je posterai un rapport de bug.

Merci d'avoir répondu si rapidement