Mises à jour de yAronet - Page 17

N'oublions pas les nouvelles icônes des forums

Niveau évolution ça reste assez limité quand même

Sur la page d'acceuil, un lien mène vers le dernier topic de cette partie du forum pour annoncer les news. Une date est indiquée.

Là je vois que c'est celle du dernier post du topic, est ce que ça n'était pas la date de création du topic de news avant ?

nop je pense pas, cette partie du code n'a pas encore été touchée

Tu met bientot a jour les avatars ?

hein ?

Godzil (./485) :
Tu met bientot a jour les avatars ?

C'est pas sa faute si ton avatar n'est pas compatible web v3.0

c'était une blague sur les icones de la page de garde qui on été mise en web 5.3 !

Il va surtout falloir trouver une autre logique pour déterminer quelles sont les catégories qui devraient apparaître sur cette page de garde, parce qu'actuellement ça n'a plus tellement de sens. Si on fait par nombre de posts sur 30 jours, les catégories qui devraient apparaître sont celles-ci :



(comme y'en a pas la moitié qui ont une icône et qu'elles ont des titres à coucher dehors, ça rend particulièrement bien )

j'adore l'icone de vince/nymphodusse/piwi

made in me, y'a des années ^^

"in" ?

*by

Je suis pas trop pour mettre des forums qui contiennent majoritairement des raccourcis vers d'autres catégories, sinon je vais mettre mon forum aussi

Mais sinon, je me faisais la même réflexion que Bob : il y a des catégories qui n'ont plus leur place en page d'accueil.

Oué, c'est un forum essentiellement TI 68K quand même, faudrait pas l'oublier

./494 : les posts des raccourcis ne sont pas comptabilisés dans le nombre de posts par catégorie dans le screen que j'ai posté en ./489, seulement les posts des forums appartenant réellement à chaque catégorie

Ça vient d'apparaître dans les blogs :

Warning: ob_start() [ref.outcontrol]: output handler 'ob_gzhandler' conflicts with 'zlib output compression' in /home/www/01a30734539941ed4f89ef8e94cc4658/web/blogs/index.php on line 3

Corrigé, merci

Tiens, c'est suite à une modif récente ? Sinon, comment ça peut apparaitre comme ça ce genre de bug ?

C'est suite à une modif de ce matin, j'ai changé la façon de compresser les pages de yN quand elles sont envoyées au navigateur, mais je suis passé à côté d'un bout de code qui tentait de faire sensiblement la même chose (donc incompatible) dans les blogs.

Ecoute, si ça te fait pas chier de prendre le temps, j'aimerais savoir ce qu'on peut s'amuser à bidouiller sur la compression des pages envoyées
Et je suis étonné, il y a moins de travail à faire côté serveur pour compression + envoi que pour envoi non compressé ? Ou alors c'est juste pour la bande passante ?

ça améliore la bp donc la charge réseau mais ça nécessite un peu de travail cpu...

pour plus d'infos : http://httpd.apache.org/docs/2.2/mod/mod_deflate.html

./501 (pointpenpen) : comme dit vince, le fait de compresser les pages avant de les envoyer permet de réduire (beaucoup, facilement 50%) la bande passante au prix d'un peu de CPU (on ne cherche pas à compresser au maximum dont ça reste des algos assez light). Comme en général on paie surtout à la bande passante plutôt qu'au CPU, c'est une solution assez courante, et les navigateurs actuels annoncent spontanément aux serveurs auxquels ils se connectent les différentes compressions qu'ils supportent pour que le serveur puisse choisir la plus adaptée. C'est ce genre de réglages que j'ai modifié, avant c'était en dur dans le code de yN avec une fonction qui dit en gros "enclenche le mode compressé", alors que je trouve que c'est un réglage global qui n'a de sens qu'au niveau du serveur, donc je l'ai simplement sorti du code pour le mettre dans un fichier de configuration Apache. Sauf pour les blogs où j'ai loupé mon coup, d'où le warning ^^

Ok, merci bien.

à noter que l'on peu aussi ne compresser qu'une seule fois pour les pages fixes, au maximum, 9 en gz, sauvegarder le résultat et le distribuer directement par la suite, mais ça nécessite un peu plus de boulot

edit > aussi, d'autre serveur web, notamment nginx, peuvent disposer de deux versions des fichier "fixe" (txt, html, css, js, ...) si le navigateur supporte le gzip, nginx cherchera avant tout toto.js.gz avant toto.js pour le distribuer

Ca marche aussi pour des pages dynamiques comme celles d'un forum ?

oui : c'est du HTML (qu'il soit généré dynamiquement depuis du PHP comme ici, ou du Python, du Ruby, ou n'importe quoi) ; en l'occurence, de manière générale (ça doit être la modif qu'a fait Bob), tu configures Apache pour qu'il compresse le HTML avant de l'envoyer au navigateur ; peu importe d'où le HTML en question sort (statique / dynamiquement généré).
HTML c'est du texte ; et le texte, de manière générale, ça se compresse plutôt bien.

Même chose pour les CSS et JS, d'ailleurs, qui sont aussi du texte, et peuvent représenter un volume parfois conséquent.

les pages d'un forum peuvent paraître dynamique mais en réalité ne le sont pas, par exemple ici, mis à part l'heure, la liste des users online et l'image de boo qui change la nuit tout le reste est statique

ce contenu vraiment dynamique pourrais être inséré par du javascript (et ce ne serais que mieux car google s'en tape complet, et au passage c'est d’ailleurs con de voir la liste des users online dans le descriptif des résultats google)

ici c'est le serveur web qui va compresser pour chaque demande la page avant de l'envoyer, pour celle ci par exemple je vois ~15ms de génération par php, plus le temps de compression gz au minimum par apache, sachant que tout est statique, au lieu de régénérer la page à chaque demande (avec tout les appels de base de données que cela inclus), sauver la page complète et déjà compressé en fichier (ou en ram avec par exemple redis, mais ici yn est un peu gros pour rentrer en ram ) serais très pertinent et permettrais de desservir genre 100 fois plus de pages qu'actuellement

dès qu'un user poste ou édite, le cache serais simplement détruit et la prochaine demande de la page la générerais et la sauverais en cache

bien évidement cela demande beaucoup de réorganisation et de changement dans le code, car la gestion de tout ca devrais être assuré par le php (ou une partie, genre la vérification de présence en cache, directement nginx qui lui est scriptable contrairement à apache)

robinHood (./508) :
mis à part l'heure, la liste des users online et l'image de boo qui change la nuit tout le reste est statique

moué, à part aussi des trucs comme les features accessibles et infos affichées uniquement aux admins (donc, ça dépend des droits de chaque type d'utilisateur ; ça ferait plus de versions de cache ; ou pas de cache pour les admins, ce qui serait une autre solution).
ou des trucs comme "je suis l'utilisateur X ; j'ai choisi d'ignorer tous les posts de l'utilisateur Y" ; et là, même problème que pour les features accessibles seulement aux admins ; sauf que le problème se pose pour tout le monde.
ou encore à part les trucs comme "nombre de posts de l'utilisateur" sur chaque post de l'utilisateur ; si tu accepte que ça ne soit pas systématiquement à jour, ça va ; mais sinon, rien que ce petit compteur là, ça détruit l'idée du cache ; même chose pour, typiquement et plus visiblement, les signatures des utilisateurs.

je déteste pour ma part les sites qui nécessitent js pour fonctionner alors qu'on pourrait très bien faire sans.