Un nouveau squelette est prêt à être lancé. Je cherche des testeurs. Hormis quelques boulettes w3c que l'on va rectifier, on ne lui trouve plus de bugs. C'est dispo sur la zone et en zip. Un site de démos et d'explications est en ligne à cette adresse: http://artlogic.ovh.org
J'attends vos premier feedback avant de poster sur spip-contrib.
"Multi-saisons" est un squelette spip qui change de couleurs au fil des saisons. Fonctionnel sur spip 1.9.2, il peut être écrit à plusieurs mains et contenir de nombreuses rubriques. Il intègre de très nombreuses fonctions :
- Multi-saisons pour que le site change de couleurs (logos + css) au fil des saisons (optionnel) ;
- option glossaire interne pour les mots complexes (optionnel) ;
- Un annuaire de membre avec pages de contact ;
- Un espace sécurisé, restreint à certains membres ;
- Une option annuaire de lien + formulaire de soumission + affichage de fil de syndication via un kiosque avec navigation par date ou site (optionnel) ;
- Un agenda (bientôt avec plugin GIS et Météo) ;
- Une page dédiée à la syndication rss ;
- Une thickbox pour afficher vos photos en diaporama ;
- Une Splickbox pour afficher votre dernier album photo ;
- Un lecteur multimédia pour vos vidéos et musiques (optionnel) ;
- Un compteur de téléchargement avec le plugin Dw2-koakidi ;
- Une Newsletter spip-liste avec affichage des formulaires ;
- Un forum multi-discussions avec avatars, modération à coup de crayon (optionnel) ;
- Des pages de recherches et de 404 pour les articles ou forums supprimés ou restreints.
- + une multitude de petits trucs : formulaire de pétition, de connexion, d’abonnement ... etc.
Le 13 mai 07, à 11:34, Stephan a écrit :
Un nouveau squelette est prêt à être lancé. Je cherche des
testeurs. ....J'attends vos premier feedback avant de poster sur
spip-contrib.
Si je peut me permettre mon avis est que c'est un peu du gaspillage d'énergie ... c'est justement un des interet de SPIP-Contrib que de permettre de motiver, recueiilir et rassembler ce type de retour (alors que sur cette type les débats vont s'enfouir) avec le forum associé à l'article. Tous les squelettes qui y on été publié on trouvé rapidement un écho et leurs auteurs du retour.
Puisque ton texte est pret, et la rubrique support aussi d'ailleurs ("http://www.spip-contrib.net/-Multi-saisons-"\) propose le rapidement sur Contrib .... après publication un texte n'est en aucun cas figé, bien au contraire, il est souhaitable qu'il évolue avec le code. Honnetement je ne vois pas de raison pratique d'attendre.
Comme la Zone pour le code, SPIP-Contrib est un espace de développement de la doc (une Zone de la doc), pas un magazine d'annonce figé.
Bonjour,
Ca m'intéresse hautement cette histoire de modification d'article par les rédacteurs. Comment est-ce possible si l'article est déjà publié ?
merci
dd
Fil a écrit :
--
Comme la Zone pour le code, SPIP-Contrib est un espace de développement
de la doc (une Zone de la doc), pas un magazine d'annonce figé.
Bonjour,
Ca m'intéresse hautement cette histoire de modification d'article par
les rédacteurs. Comment est-ce possible si l'article est déjà publié ?
merci
Un nouveau squelette est prêt à être lancé. Je cherche des
testeurs. Hormis quelques boulettes w3c que l’on va
rectifier, on ne lui trouve plus de bugs. C’est dispo sur la
zone et en zip. Un site de démos et d’explications est en
ligne à cette adresse: http://artlogic.ovh.org
J’attends vos premier feedback avant de poster sur
spip-contrib.
sympa, y’a pas de doute !
mais 337 ko pour l’affichage de la page d’accueil, ça commence à faire…
Le 13/05/07, *Stephan* <stephan@art-logic.info <mailto:stephan@art-logic.info>> a écrit :
Un nouveau squelette est prêt à être lancé. Je cherche des
testeurs. Hormis quelques boulettes w3c que l'on va
rectifier, on ne lui trouve plus de bugs. C'est dispo sur la
zone et en zip. Un site de démos et d'explications est en
ligne à cette adresse: http://artlogic.ovh.org
J'attends vos premier feedback avant de poster sur
spip-contrib.
sympa, y'a pas de doute !
mais 337 ko pour l'affichage de la page d'accueil, ça commence à faire...
--
Stéphane
Fil Nicolas > Ok pour spip contrib. J'ai demandé la publication.
Y a eu une bourde avec les icônes. On améliore ça bientôt.
Cela va réduire le poids de la page.
Le 13/05/07, *Stephan* <stephan@art-logic.info <mailto:stephan@art-logic.info>> a écrit :
Un nouveau squelette est prêt à être lancé. Je cherche des
testeurs. Hormis quelques boulettes w3c que l'on va
rectifier, on ne lui trouve plus de bugs. C'est dispo sur la
zone et en zip. Un site de démos et d'explications est en
ligne à cette adresse: http://artlogic.ovh.org
J'attends vos premier feedback avant de poster sur
spip-contrib.
sympa, y'a pas de doute !
mais 337 ko pour l'affichage de la page d'accueil, ça commence à faire...
--
Stéphane
Fil Nicolas > Ok pour spip contrib. J'ai demandé la publication.
Y a eu une bourde avec les icônes. On améliore ça bientôt.
Cela va réduire le poids de la page.
On a un souci avec les images calculées automatiquement par gd2. Chaques petites vignettes de 100px de coté passent les
20ko. scrmlmlml le poids de la page s'envole.
--
On a un souci avec les images calculées automatiquement par gd2. Chaques petites vignettes de 100px de coté passent les
20ko. scrmlmlml le poids de la page s'envole.
oui moi aussi j'aimerais beaucoup réduire ça
pour diminuer la bande passante.
La qualité par défaut des vignettes spip est trop haute,
et le poids trop élevé proportionnellement à la "surface"...
Il faudrait un filtre "image_legere" par exemple...
mais le code des filtres image_filtre est achtreu touffu,
avec la gestion du décodage des balises HTML,
des zones buffers de travail pixel,
des différentes librairies graphiques,
du cache des images intermédiaires,
des nommages de ces images,...
L'accueil de mon site en version précédente passe sous la barre des 40ko. En regardant de plus prêt, il n'y a pas que les images qui me chagrinent. J'ai aussi quelques javascript de plugins qui me jouent des tours. Certains JS de plugins restent actifs alors qu'il ne sont pas utilisé dans les pages. GIS qui utilise les gros script de Google m'offre pres de 56ko sur toutes les pages du site alors qu'il n'est exploité que très ponctuellement dans l'agenda.
Y a-t-il un remède pour appeler uniquement les javascripts dont on a besoin? C'est quand même dommage d'avoir une xhtml qui ne passe pas les 40ko et de se faire lester de 200ko comme ça.
JLuc a écrit :
Stephan wrote:
On a un souci avec les images calculées automatiquement par gd2. Chaques petites vignettes de 100px de coté passent les
20ko. scrmlmlml le poids de la page s'envole.
oui moi aussi j'aimerais beaucoup réduire ça
pour diminuer la bande passante.
La qualité par défaut des vignettes spip est trop haute,
et le poids trop élevé proportionnellement à la "surface"...
Il faudrait un filtre "image_legere" par exemple...
mais le code des filtres image_filtre est achtreu touffu,
avec la gestion du décodage des balises HTML,
des zones buffers de travail pixel,
des différentes librairies graphiques,
du cache des images intermédiaires,
des nommages de ces images,...
L'accueil de mon site en version précédente passe sous la barre des 40ko. En regardant de plus prêt, il n'y a pas que les images qui me chagrinent. J'ai aussi quelques javascript de plugins qui me jouent des tours. Certains JS de plugins restent actifs alors qu'il ne sont pas utilisé dans les pages. GIS qui utilise les gros script de Google m'offre pres de 56ko sur toutes les pages du site alors qu'il n'est exploité que très ponctuellement dans l'agenda.
Y a-t-il un remède pour appeler uniquement les javascripts dont on a besoin? C'est quand même dommage d'avoir une xhtml qui ne passe pas les 40ko et de se faire lester de 200ko comme ça.
Ya souvent un pb tu as raison,
comme jquery qui bouffe aussi 40ko non compressés,
et qui sur certains sites n'est jamais appelé
ou parfois seulement pour les admins.
Les scripts en général sont appelé dans inc-entete, non ?
Possible d'inclure inc-entete avec un paramétre {avec-jquery=vrai}
ou {avec-gis=vrai} si besoin réel
et à l'intérieur de n'inclure que si le parm est positionné.
(mais après, avec les plungin qui forcent les choses, faut voir ...)
Sinon, faut savoir que les javascript sont mis en cache navigateur,
et que la pénalité n'est pas si lourde que ça : une fois chargés,
si c'est une même personne qui navigue plusieurs pasges sur ton site,
le script ne se charge qu'une seule fois la 1ère fois.
Mais si la première page est lourde, ça fait mauvaise impression...
Quelque chose d'étonnant: mes images recolorisée via SEPIA sont plus lourdes.
JLuc a écrit :
Stephan wrote:
L'accueil de mon site en version précédente passe sous la barre des 40ko. En regardant de plus prêt, il n'y a pas que les images qui me chagrinent. J'ai aussi quelques javascript de plugins qui me jouent des tours. Certains JS de plugins restent actifs alors qu'il ne sont pas utilisé dans les pages. GIS qui utilise les gros script de Google m'offre pres de 56ko sur toutes les pages du site alors qu'il n'est exploité que très ponctuellement dans l'agenda.
Y a-t-il un remède pour appeler uniquement les javascripts dont on a besoin? C'est quand même dommage d'avoir une xhtml qui ne passe pas les 40ko et de se faire lester de 200ko comme ça.
Ya souvent un pb tu as raison,
comme jquery qui bouffe aussi 40ko non compressés,
et qui sur certains sites n'est jamais appelé
ou parfois seulement pour les admins.
Les scripts en général sont appelé dans inc-entete, non ?
Possible d'inclure inc-entete avec un paramétre {avec-jquery=vrai}
ou {avec-gis=vrai} si besoin réel
et à l'intérieur de n'inclure que si le parm est positionné.
(mais après, avec les plungin qui forcent les choses, faut voir ...)
Sinon, faut savoir que les javascript sont mis en cache navigateur,
et que la pénalité n'est pas si lourde que ça : une fois chargés,
si c'est une même personne qui navigue plusieurs pasges sur ton site,
le script ne se charge qu'une seule fois la 1ère fois.
Mais si la première page est lourde, ça fait mauvaise impression...
Y a-t-il un remède pour appeler uniquement les javascripts
dont on a besoin? C'est quand même dommage d'avoir une xhtml
Le plugin Crayons, et le plugin surligne_js ont tous les deux choisi
une stratégie différente : on ne met pas le script en cache, on
l'ajoute à la toute fin avant d'envoyer la page ; ça coûte un tout
petit peu plus de CPU à chaque hit, mais ça économise toute cette
bande passante et le travail js pour rien côté client.
Je pense que c'est la bonne méthode, mais à condition d'y aller
super-mollo sur les tests : éviter les preg_match, faire return dès
qu'on est sûr, faire des strpos(), etc.
Je vais vendre ça aux dames qui souhaitent retrouver la ligne avant l'été: c'est une nouvelle crème du nom d'|image_aplatir{gif,ffffff}
JLuc a écrit :
Stephan wrote:
On a un souci avec les images calculées automatiquement par gd2. Chaques petites vignettes de 100px de coté passent les
20ko. scrmlmlml le poids de la page s'envole.
oui moi aussi j'aimerais beaucoup réduire ça
pour diminuer la bande passante.
La qualité par défaut des vignettes spip est trop haute,
et le poids trop élevé proportionnellement à la "surface"...
Il faudrait un filtre "image_legere" par exemple...
mais le code des filtres image_filtre est achtreu touffu,
avec la gestion du décodage des balises HTML,
des zones buffers de travail pixel,
des différentes librairies graphiques,
du cache des images intermédiaires,
des nommages de ces images,...
