r13007 - spip/ecrire/action

Author: kent1@arscenic.info
Date: 2008-10-20 20:45:04 +0200 (lun, 20 oct 2008)
New Revision: 13007

Log:
get_spip_doc ne joue plus son rôle (en version de dev) qui consistait principalement à récupérer le bon nom de fichier, puisque dorénavant get_spip_doc ajoute une date au nom de fichier ... du coup ca cassait cette action car le fichier n'était pas trouvé...

Je remplace get_spip_doc par _NOM_PERMANENT_ACCESSIBLE qui doit correspondre à IMG/ par défaut...

Peut être est ce fait un peu vite?

Modified:
   spip/ecrire/action/acceder_document.php

Details: http://trac.rezo.net/trac/spip/changeset/13007

oui c'est pas bon du tout ça !
Il *faut* passer par get_spip_doc qui a été mise en place pour que les chemins vers les documents soient calculés en un unique point.
Revenir sur ça n'est donc pas un progrès.

Je préfère encore que tu commentes l'ajout de la date dans get_spip_doc (ce n'est peut être pas le meilleur endroit pour le mettre) plutôt que casser cela.

Sinon la raison pour laquelle j'ai commencé à introduire un timestamp sur toutes les url de documents et de logo correspond à un besoin pour optimiser les charges serveurs :
il est important de pouvoir placer dans le htaccess une directive Expire du type
<IfModule mod_expires.c>
ExpiresActive on
ExpiresByType image/gif "access plus 1 months"
ExpiresByType image/jpeg "access plus 1 months"
ExpiresByType image/png "access plus 1 months"
ExpiresByType text/css "access plus 1 months"
ExpiresByType application/x-javascript "access plus 1 months"
</IfModule>

qui permet de diminuer significativement la charge des serveurs.
Toutefois, cela implique que l'url doit changer lorsque le fichier change.
Une url du type

avec le timestamp derrière le ? permet cela à moindre coût
Je vais donc revenir sur ce point dans la version de dev pour que ce soit pleinement opérationnel.
Dans le cas de acceder_document, il est evident que le timestamp ne doit pas être fourni à cet endroit, mais dans l'url de l'action pour acceder au document...

Cédric

Le 20 oct. 08 à 20:45, kent1@arscenic.info a écrit :

Author: kent1@arscenic.info
Date: 2008-10-20 20:45:04 +0200 (lun, 20 oct 2008)
New Revision: 13007

Log:
get_spip_doc ne joue plus son rôle (en version de dev) qui consistait principalement à récupérer le bon nom de fichier, puisque dorénavant get_spip_doc ajoute une date au nom de fichier ... du coup ca cassait cette action car le fichier n'était pas trouvé...

Je remplace get_spip_doc par _NOM_PERMANENT_ACCESSIBLE qui doit correspondre à IMG/ par défaut...

Peut être est ce fait un peu vite?

Modified:
   spip/ecrire/action/acceder_document.php

Details: http://trac.rezo.net/trac/spip/changeset/13007

_______________________________________________
spip-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-commit
dev: http://trac.rezo.net/trac/spip/

Le 21 octobre 2008 10:20, cedric.morin@yterium.com <cedric.morin@yterium.com

a écrit :

...
qui permet de diminuer significativement la charge des serveurs.
Toutefois, cela implique que l'url doit changer lorsque le fichier change.
Une url du type
http://mondomaine.org/IMG/arton23.png?123456789

avec le timestamp derrière le ? permet cela à moindre coût

Bonne idée c'est en effet une très bonne piste d'optimisation de charge et
ça évite pas mal de problèmes de gestion de cache le long du réseau.
Qu'est qui sert de base au timestamp ? est-ce compatble avec la fonction de
modif de document apportée par les crayons.
Merci.

------------------------------
Arnaud

http://mondomaine.org/IMG/arton23.png?123456789

ça ne complique pas l'application de filtres image_xxx dessus ?

-- Fil

Le 21 oct. 08 à 11:57, Arnaud Ventre a écrit :

Le 21 octobre 2008 10:20, cedric.morin@yterium.com <cedric.morin@yterium.com

a écrit :

...
qui permet de diminuer significativement la charge des serveurs.
Toutefois, cela implique que l'url doit changer lorsque le fichier change.
Une url du type
http://mondomaine.org/IMG/arton23.png?123456789

avec le timestamp derrière le ? permet cela à moindre coût

Bonne idée c'est en effet une très bonne piste d'optimisation de charge et
ça évite pas mal de problèmes de gestion de cache le long du réseau.

oui.
J'ai pu faire des essais sur un site à fort traffic :
Alors que les pages necessitent en moyenne une cinquantaine de hit tout compris pour le chargement complet de la page, Expire permet de ramener le ratio hit/pages vues à une valeur voisine de 6.

Sur ce sujet, cf les slides de la présentation d'Eric Dapset, Mathieu Pillard et Anthony Ricaud au w3café de septembre :
http://performance.survol.fr/page/3/

Il parait que l'écriture ?timestamp n'est pas parfaite car certains proxy ne la cachent pas (mais les navigateurs derrière, oui) mais cela permet d'atteindre 99% du bénéfice.
La solution idéale est de versionner les noms de fichiers mais :
- cela toucherait beaucoup de chose dans le noyau
- cela ne résoudrait pas le probleme pour les images de décoration.
avec le ?... on peut aussi envisager de traiter automatiquement les urls des images de style au moment de la compression des css

Qu'est qui sert de base au timestamp ?

C'est le filemtime du fichier lui même.
Donc si il change, l'url change, même si le nom du fichier n'a pas changé.

est-ce compatble avec la fonction de
modif de document apportée par les crayons.

il me semble, oui

Cédric

C'est aux filtres images de gérer cela proprement.
C'est déjà le cas (c'etait facile car il y a un point d'entrée centralisé), les petits problemes techniques sont plutôt sur tous les cas particuliers d'appel de la fonction.
Je n'ai pas eu le temps de finir cela pour la 2.0, c'est donc uniquement dans la branche dev, j'y reviendrais.
Cédric

Le 21 oct. 08 à 12:06, Fil a écrit :

http://mondomaine.org/IMG/arton23.png?123456789

ça ne complique pas l'application de filtres image_xxx dessus ?

-- Fil
_______________________________________________
spip-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-commit
dev: http://trac.rezo.net/trac/spip/