Bonsoir,

Je souhaiterai savoir si FSB repose sur un système de cache en mémoire partagé (APC, Memcached et consorts). Si tel est le cas, comment est-ce géré ? Quel fichier ?

Merci d'avance à celui qui me répondra

Salut,
FSB utilise un système de cache qui s'appuie sur plusieurs méthodes en fonction de la configuration du serveur : il utilise APC ou Memcache ou Eaccelerator si une de ces trois librairies sont installées avec PHP, sinon il utilise un système de stockage dans des fichiers sur le serveur (dans le dossier cache/ à la racine du forum), le cas échéant s'il n'a pas les droits d'écriture sur ce dossier il stock ça dans la table fsb2_cache de la base de donnée.

Tu trouveras les fichiers utilisant ce cache dans le dossier main/class/cache/ du forum.

PS : actuellement il y a un petit bug pour les 3 premiers cache cités (une petite erreur à la con dans les classes), donc pour avoir la version corrigée regarde dans cette archive de FSB2 : http://www.fire-soft-board.com/dl/fsb2_convertors.zip

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

Oui, les templates sont cachés, ainsi que certaines requêtes SQL. Effectivement maintenant que tu le dis j'avais zappé le coup de la mémoire partagée, à coup sur plusieurs forums ont les même clefs en cache, il faudra que j'ajoute le chemin du forum sur le dommaine dans les hash des clefs de cache pour régler ce problème.

Je note le sujet pour corriger.

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

Voilà la version corrigée des fichiers, si jamais tu as besoin de tester en attendant que je mette à jour le forum.

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

Le problème c'est que la configuration est mise en cache ^^

Je vais essayer de me baser sur autre chose, il y a bien une variable de serveur que je pourrai utiliser dans le tas.

Tu as $_SERVER['SCRIPT_URI'] ou bien $_SERVER['SCRIPT_FILENAME'] sinon…

Non ca ne marcherai pas car comme l'a fait remarqué D-Sgam ca tombe à l'eau quand tu utilises le SDK dans un autre répertoire par exemple.

Que penses tu d'un MD5 du contenu du fichier config/config.php sinon D-Sgam ?

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.

Il reste __FILE__ sinon…

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).

Ca me semble bizarre ca… J'ai failli proposer un fileinode(__FILE__) après (qui aurait marché par contre).

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.