Merci et (préchargement...)

philou87 · janvier 2013

Bonjours,

Merci à toute l'équipe pour cette nouvelle mouture de Pluxml 5.1.7 équipée d'un theme full html5 d'une page full-width, et le tout responsive, c'est vraiment un plus.

Pluxml est trés léger au départ mais le soucis est que assez rapidement, si on charge un peu avec un "slider "ou en faisant appel au "google api" ou a des fonctions Js qui s'accumullent rapidement,vite on a vraiment un gros temps mort au chargement.
Existe t'il une possibilité de préchargement ou d'affichage mini (du fond)

Avez-vous aussi envisagé de compiler quelques fonctions JS telles que (go to top) suivant/précédent...
on est vite en conflit également avec le plugin jquery et des choses simple comme un (slider) ou une (galerieBX) par exemple. Ce ne sont que des exemples.

Ce ne sont en aucun cas des critiques pluxml est un outil sympa vraiment trés flexible facile d'utilisation pour un résultat pro sans base de donnée .

Stéphane · janvier 2013

Bonjour
Soyons clair:
1) Google api: appel de ressources sur un autre site donc si cela dégrade les temps de réponse cela n'a rien à voir avec PluXml et on pourra rien y faire.
2) Javascript: appel d'un fichier js lu sur le server dont l'execution du code se fait coté client, c'est à dire par ton navigateur, donc rien à voir avec PluXml

Ce que je veux juste montrer là c'est que ce n'est pas PluXml qui est responsable de la dégradation des temps de réponse et que c'est "normal" dans ces 2 cas bien précis. C'est comme dire transférer une image de 100Ko ça prends 1 sec et transferer une image de 100Mo ça prend 1 minute: ben oui forcément le volume de données est plus gros, donc ça prend plus de temps.

Autre point: javascript est un langage interprété, donc pas de compilation. En revanche, on peut réduire la taille des fichiers avec du pseudo code en utilisant un compresseur de code (c'est peut etre ça que tu as voulu dire). Donc oui certains codes javascript peuvent etre réduits pour améliorer le temps de chargement.

Pour les conflits jquery, je suis d'accord. si chacun y va de son plugin avec une version de jquery différente parce qu'au moment du developpement d'un plugin, jquery était à la version 1 et un autre plugin à la version 1.5, on peut vite se retrouver avec des conflits. Mon avis est qu'à un certain moment, il faut un minimm de connaissance en programmation pour faire le ménage et optimiser le code de son site.

zakar! · janvier 2013

+1 avec Stéphane.

A noter que le plugin Jquery est surtout la a titre d'exemple dans la conception d'un plugin.

Par contre Pluxml pourrai gérer la minimisation de ces fichiers css et js des plugins + core à la volée ou par système de cache qui serai dans ce cas la solution plus optimisée mais pas obligatoire

Pour les feuilles de style j'imagine qu'on pourrai modifier la fonction $plxShow->templateCss() et pourquoi pas avoir la même chose en footer avec $plxShow->templateJs().

Stéphane · janvier 2013

@zakar!; je retiens l'idée de minimiser les fichiers .js et .css du core de PluXml. Bien vu

bankai · janvier 2013

attention, il ne faut pas mettre tout les JS dans le footer ^^
Cela dépend des différents chargement des plugin, pour jquery ,il est conseillé de le mettre en premier dans le header.

Jos · janvier 2013

bankai a écrit:

attention, il ne faut pas mettre tout les JS dans le footer ^^
Cela dépend des différents chargement des plugin, pour jquery ,il est conseillé de le mettre en premier dans le header.

+1. Certains script doivent se charger avant d'autres pour bien fonctionner.

philou87 · janvier 2013

je suis complétement d'accord avec vous Stephane, mais j'ai surtout voulu lancer un débat;
le javascript qui comme vous le dites si bien est une "appli" qui fonctionne coté client, est une (honte) pour les puristes de la programmation, mais voilà il est revenu et il revient toujours et on peut vraiment pas faire sans.
donc minimiser dans un premier temps certaines fonctions js et css (essentielles) me parait judicieux

fonctions/plugin ou modules ?

La gestion des plugins dans l'admin est vraiment bien faite, elle s'apparente a une gestion de modules comme sur d'autres cms mais certains plugins ne sont vraiment pas des modules; en meme temps je comprends le dilemme du créateur
Doit on faire le plus simple possible pour les utilisateurs ?
Est-ce que pluxml a vocation à devenir un cms a part entière ?

Pluxml est un super gestionnaire de blog à la portée de tous mais le soucis des (blogs) maintenant c'est qu'ils gèrent de moins en moins de texte et de plus en plus d'images de vidéos importées et patati et patata sans parler des "grid" et des "framework"! qui vont s'imposer.

Alors pourquoi pas une fusée PLUXML a plusieurs étages
Simple pour les utilisateurs et puissant pour les pros comme on dit sur CMSMS. chut...!!

Vous allez me dire que cela existe déjà et je ne vous donnerai pas entièrement tort puisque par exemple en ce qui me concerne (dans mes tests) je suis arrivé a un résultat satisfaisant en me débrouillant seul avec le wiki et les posts du forum; mais cela n'a pas été sans mal et J'ai pas mal tourné en rond.

Mon avis personnel qui n'engage que moi est que:
Si PLUXML veut garder une longueur d'avance il doit :

Rester full html5 et compatible avec un framework /grid; le nouveau theme est bien mais embarque 2 js
non compilés, donc pourquoi pas comme dit avant un fichier core/css et un js;
il serait aussi bien d'embarquer "jquery" et une autre lib.min puisque l'on ne peut plus faire sans.

Ensuite faire la différence entre modules et plugins, certains plugins utiles mais mineurs pourraient trés bien etre ajoutés via ftp et initialisés vis un tag ou une UDT

Pour ce qui est de la partie des "hacks" ils pourraient se faire directement via des UDT comme c'est le cas sur cmsms ( un textarea directement accessible dans l'admin (article /cat/static). je ne suis pas un spécialiste mais je rappelle qu'une UDT est un bout de code php qui sert a initialisé un plugin ou un apport de code pour une modif particuliere .(ce qu'on fait tout le temps).

Chez CMSMS par exemple certaines UDT ou plugin sont intégrés de base et on les utilise via des tags; seulement ce dont on a besoin; ceci afin de ne pas surcharger la mule, ensuite d'autres peuvent etre utilisées au niveau supérieur directement dans les contenus pour faire tourner des fonctions ou des modules spécifiques comme par exemple le multilingue.

Le multilingue une fonction essentielle:

C'est pas facile a développer, je sais, peu de cms le propose et il est jamais aisé a mettre en place; certains disent que c'est mieux de faire plusieurs versions, c'est peut etre bien pour une plaquette mais cela s'avère vraiment pènible au fur et a mesure s'il on ne dispose pas d'une équipe de traducteurs.

En génèral losque l'on parle de multilingue les gens comprennent tout de suite bise-ness; pour ma part je vois cela complétement sous un autre angle.
Dans un monde qui va devenir de plus en plus transversal, ou ce que l'on transmettra ou cherchera ne tombera plus d'en haut mais viendra plutot d'à coté.
Michel Serres conseille en particulier, aux nouvelles générations, celles qui en Europe ont et auront la chance de parler plusieurs langues de contacter directement leur vis a vis dans les autres pays Européens et d'échanger directement avec eux sans passer par je ne sais qu'elle organisme et hierarchie.
Le blog multilingue a donc un avenir certain, l'enjeu est de taille.

J'espère que mon propos n'est pas trop prétentieux, je suis un passionné du "libre" pas professionnel plutot bricoleur;au fil des ans J'ai mis en place un guppy edu pour un college; un joomla/virtuemart pour un copain éditeur; mon CMS préféré est CmsMadeSimple . A un moment je suis rentré dans Drupal alors que Médiapart ou rue89 démarraient sur cette plateforme; je me suis aussi intéressé aux fondement de prestashop sans toutefois mettre d'application de site en place.
J'ai découvert pluxml il y a quelques années et j'y revient: C'est surement pas un hasard.

zakar! · janvier 2013

Entièrement d'accord avec toi pour embarqué au minimum Jquery minimalisé bien sur dans le thème ce qui évite bien des soucis de compatibilité et d'éxécution de script et au moins le charger en PREMIER en <head>.

Ceci dit il serait bien de l'intégrer dans le thème aussi pour gagner en temps de chargement.

Sinon pour les autres js par soucis de temps de chargement (encore) il est préférable de les mettre en footer et pour les lib prioritaire, un appel grace au hook head fera l'affaire.

Plugin, module peut importe, du moment qu'un fichier d'aide est fournis pour une installation spécifique

Ensuite je te suit entièrement sur ton avis sur la non évidences des plugins :
- recherche entre la page de téléchargement, le wiki et forum

et les thèmes dont l'utilisateur qui veux participer a du mal a envoyer au dépôt.

Si Stéphane passe par la je pourrait proposer un plugin de ressource...

bankai · janvier 2013

Bonjour, je viens de finir les romans ^^

Alors pour ce qui est du Html5 et CSS3, ce n'est pas PluXml le CMS qui doit l'être mais le Template, le Template d'origine est la contribution d'un bon membre, pour le Js (au nombre de deux) ils ne ralentissent pas grand chose, vu les connexion d'aujourd'hui et les serveurs de plus en plus puissants.

Le Js doit être "minifier" est surtout mit dans un ordre correct.
Les classes existe pour mettre les plugins soit dans le head soit avant le body, c'est aux créateurs des plugins a le mettre ou il doit être.

Les plugins :
Sur pluXml il n'y a pas de modules mais des plugins, plus simple comme ça de si retrouver.
Il existe un installateur de plugin officiel ou directement par url: http://forum.pluxml.org/viewtopic.php?id=3378 ce qui rend la tache plus simple, mais il faudra toujours mettre la ligne de code qui va bien

Je ne pense pas que PluXml est vocation à avoir une longueur d'avance mais plus d'être au niveau de se que l'on attend de lui, les développeurs s'en servent pour des sites de commence, des blogs, des sites et d'autre, sans lourdeur avec une facilité de mise à jour et une simplicité d’administration.

Pour ce qui est du multilingue, un plugin est en cours de création par un des développeur si je me rappelle bien, sinon avec google maintenant il est est facile de mettre le site dans une autre langue

Mais il est vrai que pour certain, si il était natif se serait mieux.

zakar! · janvier 2013

bankai a écrit:

Alors pour ce qui est du Html5 et CSS3, ce n'est pas PluXml le CMS qui doit l'être mais le Template, le Template d'origine est la contribution d'un bon membre, pour le Js (au nombre de deux) ils ne ralentissent pas grand chose, vu les connexion d'aujourd'hui et les serveurs de plus en plus puissants.

Hum ok mais quand tu télécharge Pluxml le theme est fournie non ?
Pour cette reflexion de grosse connexion je ne suis pas du tout en accord avec ce que tu dis, c'est pas comme ça qu'il faut voir la chose, quelques Ko de gagné c'est toujours ça de pris et le référencement se porteras que mieux car le chargement est pris en compte a ce sujet.
Sans compter le coté écologique de la chose mais la c'est tout autre

bankai a écrit:

Le Js doit être "minifier" est surtout mit dans un ordre correct.
Les classes existe pour mettre les plugins soit dans le head soit avant le body, c'est aux créateurs des plugins a le mettre ou il doit être.

La ok

bankai a écrit:

Pour ce qui est du multilingue, un plugin est en cours de création par un des développeur si je me rappelle bien, sinon avec google maintenant il est est facile de mettre le site dans une autre langue
Mais il est vrai que pour certain, si il était natif se serait mieux.

Nop pas de natif pour ça, un plugin pour ceux qu'il le veulent

danielsan · janvier 2013

m'enfin c'est aussi aux développeurs de plugins/templates nécessitant jQuery ou autre librairie de bien gérer le dév. ou leur présentation.
Installer jQuery pour faire un simple bouton "back to top", est-ce réellement nécessaire alors qu'il suffit de réécrire/extraire la seule fonction utile ? Idem pour les diapo, etc ...
Après le développeur peut dire "nécessite jQuery pour fonctionner" ...
A mon avis, on fait des économies sur les scripts et au CSS après qu'on ait bien formaté les images ...

Stéphane · janvier 2013

le css du theme par défaut de PluXml ne sera jamais minifié car il doit rester lisible en clair à titre pédagogique.

zakar! · janvier 2013

Héhé danielsan tu précise bien 'aux développeurs' et toi Stéphane tu précise 'à titre pédagogique'.
On vois bien une grose différence entre 2. Justement pour l'utilisateur lambda qui veux faire ne ce resse quelques modifications sur son thème, y mettre sa 'griffe' pour le différencié des autres.

Ne croyez-vous pas qu'il devrait s'appuyer sur un modèle d'exemple ? Le thème par défaut justement.

Pour la minification du css pas de soucis je vous lâche le snippet qui fais ça à la volée donc au final on charge plus vite coté client et de l'autre on peux Dev sur un fichier lisible en clair.

css.php:

<?php 
header('Content-type: text/css');
ob_start("minifie");
	function minifie($buffer) {
	/* supprime les commentaires */
    	$buffer = preg_replace('!/\*[^*]*\*+([^/][^*]*\*+)*/!', '', $buffer);    		
    	/* supprime les tabulations, espaces, sauts de lignes, etc. */
    	$buffer = str_replace(array("\r\n", "\r", "\n", "\t", '  ', '    ', '    '), '', $buffer);   		
    	return $buffer;
	}
  	/* Placer ici vos fichiers css pour la compression */
  	include('style.css');
ob_end_flush();
?>

Dans le template header.php remplacer l'appel de style.css par css.php.
Placer ce fichier à la racine du thème par défaut.
C'est fini.

Au final quand on voit beaucoup de demande comme quoi que tel script ne fonctionne pas à cause en partie de Jquery chargé plusieurs fois, autant dire qu'il y est fournie une bonne fois pour toute, et justement aux créateurs/développeurs de virer ce script aisément pour lui ce qui ne l'est pas pour un utilisateur Lambda

zakar! · février 2013

Bump !

Jerry Wham · février 2013

Je n'ai pas lu les romans (du moins en diagonale). Je dirais que pour jquery, et sa compatibilité, c'est un faux problème. Il suffit, lorsqu'on développe un plugin, de tester si la bibliothèque est déjà chargée, et de ne la chargée via le plugin que si elle est absente. Ça se fait en 2 lignes de codes et ça permet de résoudre tous les problèmes.

La mettre par défaut, je ne suis pas d'accord. Tous les projets n'en ont pas forcément besoin.

Pour la minification des css et des js, c'est pas con. Je retiens l'excellente idée.

Et je suis entièrement d'accord avec Bankaï. On s'en fout que Pluxml ait une longueur d'avance ou pas. On ne fait pas la course. On n'est pas pressés. On veut juste un outil performant, facile d'utilisation, adaptable et qui fait bien ce qu'on lui demande, qualités que Pluxml a sans aucun doute.

Jos · février 2013

Pour l'histoire des scripts, effectivement il y en a deux. Html5ie fait 1ko, l'autre fait 4ko, donc c'est plutôt léger. Le premier permet aux ancien IE de lire du HTML5, le second permet d'appliquer les média query aux ancien IE. Surement que dans un proche avenir, on se posera la question de savoir jusqu’où va la prise en charge de PluXML...

Pour la minification, certes on gagne quelques ko, mais un débutant ne va rien comprendre si il veut modifier son css. Pour le plugin jQuery par défaut, à la base pour le thème je l'avais mis en place, mais après discussion avec Stéphane, je pense que c'est mieux de ne pas le charger par défaut. Quelqu'un qui ne s'en sert pas n'en a pas besoin.

En gros, c'est pas pour 5 ko de script, et quelques ko de css non minifié que le site sera hyper lourd (heureusement que PluXML est léger de ce coté là). On peut gagner du poids dans d'autres domaines. Le poids d'un site est majeur pour moi, d'autant que ma connexion est plutôt lente là où je suis en ce moment.

zakar! · février 2013

Jos a écrit:

Pour l'histoire des scripts, effectivement il y en a deux. Html5ie fait 1ko, l'autre fait 4ko, donc c'est plutôt léger. Le premier permet aux ancien IE de lire du HTML5, le second permet d'appliquer les média query aux ancien IE. Surement que dans un proche avenir, on se posera la question de savoir jusqu’où va la prise en charge de PluXML...

Une simple notification noscript pour avertir gentiment de mettre à jour sont navigateur, ca prend quelques secondes à l'utilisateur.

Jos a écrit:

Pour la minification, certes on gagne quelques ko, mais un débutant ne va rien comprendre si il veut modifier son css. Pour le plugin jQuery par défaut, à la base pour le thème je l'avais mis en place, mais après discussion avec Stéphane, je pense que c'est mieux de ne pas le charger par défaut. Quelqu'un qui ne s'en sert pas n'en a pas besoin.

Relis mon sujet, les fichier css resteront 'brut' dans le thème, c'est mon script qui s'occupe de mignifier à la volée.
Ensuite pour revenir a ce fameux Jquery, si x plugin l'utilise, je peux vous parier que certain script l'utilisant ne s'exécuterons pas.
Que dire aux développeurs de plugins ?
Que tout simplement jquery est livré avec le thème par défaut donc la question ne se posera pas sachant qu'en plus il seras positionner entre les balises <head> pour éviter toute confusions.

Jos a écrit:

En gros, c'est pas pour 5 ko de script, et quelques ko de css non minifié que le site sera hyper lourd (heureusement que PluXML est léger de ce coté là). On peut gagner du poids dans d'autres domaines. Le poids d'un site est majeur pour moi, d'autant que ma connexion est plutôt lente là où je suis en ce moment.

Faut pas tout mélanger, que PluXml soit léger c'est une chose (très bonne), mais au final si l'utilisateur installe 36 plugins, 36 images par posts.... On auras beau avoir un cms hyper léger, il deviendras tout autre avec ce que l'on en fait avec.

Jerry Wham · février 2013

Mettre jquery par défaut n'est pas une bonne chose. Comme le disait Stéphane, tous les plugins n'utilisent pas la même version. Il faudrait que la version chargée soit toujours la dernière.

Sauf à se connecter aux serveurs de google, ce qui est bien certes pour la bande passante, beaucoup moins pour la vie privée, il vaut mieux ne rien mettre et laisser le soin aux développeurs de plugins de tester si la librairie est chargée ou pas.

zakar! · février 2013

En règle général la dernière version de Jquery ne posera aucun problème avec les ancienne, pour ça le Dev d'un plugin avec une ancienne version de la lib devras clairement ajouter jQuery.noConflict(); pour éviter les conflit comme son nom l'indique.
Donc les souci entre version j'y crois pas trop.
Ceci dit le Dev serat au final plus aguérit qu'un membre débarquant sur pluxml.
Après ce n'est pas si compliquer que ça d'intégrer la dernière version dans le thème lors de nouvelle update de pluxml...
Il vas de soi de charger la lib physiquement dans le dossier du thème pour des raison de vie privé et chargement distant inutile.

Et pour les tests bon courage, s'il faut énumérer toutes les versions ...

Jerry Wham · février 2013

Tu n'as pas besoin de tester toutes les versions, juste que la librairie est présente, ce qui n'est pas pareil.
Pour ce faire, il suffit d'un :

<script type="text/javascript">
/* <![CDATA[ */
   !window.jQuery && document.write(\'<script  type="text/javascript" src="<?php echo PLX_PLUGINS;?>monPlugin/jquery-la-version-necessaire-a-mon-plugin.min.js"><\/script>\');
/* !]]> */
</script>

Francis · février 2013

@zakar! : J'ai eu une mauvaise expérience avec la dernière version 1.9 de jQuery, avec deux animations qui ne marchaient plus.
Dans mon code, je récupérais la dernière version 1.x en tenant le même raisonnement que toi, c'est-à-dire la rétrocompatibilité qui va de soit, eh bien je suis vite revenu en arrière !

@Jerry : Moi aussi, j'utilise !window.jQuery pour vérifier que jQuery n'est pas présent, avant de le charger. Mais en fait, on ne sait pas quelle version est chargée, si elle est suffisamment récente (ou pas trop récente, avec le pb que j'ai eu !), alors je me pose des questions...

zakar! · février 2013

Alors si même pour un Dev c'est compliquer, comment voulez vous qu'un débutant si retrouve ?
@Francis il faut y aller a tâtons, charger la dernière version puis d'ajouter jQuery.noConflict(); avant le chargement des anciennes versions (1.1.x, 1.2.x, 1.3.x, 1.4.x)

Edit:
If you include jQuery before other libraries, you may use "jQuery" when you do some work with jQuery, and the "$" is also the shortcut for the other library. There is no need for overriding the $-function by calling "jQuery.noConflict()".

Jos · février 2013

Les dernières versions de jQuery changent pas mal des choses :

http://www.developpez.com/actu/50982/Avalanche-de-nouveautes-pour-jQuery-sortie-de-la-version-1-9-0-du-plugin-jQuery-Migrate-1-0-0-et-de-jQuery-2-0-0-beta/

danielsan · février 2013

si pas rester le débutant souhaite, sur le forum il viendra ...

zakar! · février 2013

Bon bref arrêter de confirmer que les Dev doivent mettre à jour leur plugins, car sinon on vas croire que le membre dois ce démerder a faire une recherche sur tout le forum, sachant que celle intégré a Fluxbb fait des miracles ^^

Jos · février 2013

En gros, un Dev de plugin utilisant jQuery devrait préciser (si ce n'est déjà fait) la version jQuery qui fonctionne bien avec son plugin.

zakar! · février 2013

Nop, je le répète pourquoi chercher compliquer ?
Tu vas checker plugins par plugins pour sortir le Grand Jquery des cartons ?
Au jours d'aujourd'huis le javascript est présent partout, avec les smartphones et le html5, les traitements Json/Jquery.
Bref pourquoi ne pas vouloir intégré Jquery au thème placé dans les balises <head> pour éviter ce genre de propos ?

Est ce une honte d'utiliser cette Lib ?

danielsan · février 2013

J'aime bien l'autonomie de PluXml tel quel.
Le mec qui bidouille des trucs et qui a besoin de jQuery, à mon avis il touche un peu sa bille.
Alors après il met la charrue avant les boeufs, mélange tout, bidouille trop, et il vient râler parce que ça marche plus ...
Combien de plugin utilise jQuery ??? je me l'demande hein ...

zakar! · février 2013

Touche sa bille ? mais non.
Je me met dans la place d'un simple utilisateur, qui télécharge et installe pluXml, puis télécharge et installe un plugin 'ScrollToTop', 'CoinSlider', 'Social', 'Share', 'lastTweet' ... (désolé si les Nom des plugins ne sont pas tout a fait de se Nom).
En bref il y en a une dizaine qui comprend les 'officiels' et quelque uns de ce forum.
Essaye de les installer tous et dis moi si tout fonctionne correctement...

Jos · février 2013

+1 @danielsan.

Tout le monde n'utilise pas jQuery. De toute façon, il me semble que Stéphane n'en veut pas par défaut dans le thème : il me semble qu'on en avait parlé par mail avant la sortie de la 5.1.7, donc il y a plus grand chose à dire sur sujet.

Chacun à sa philosophie, et les deux approches sont bonnes. Ça ne veut pas dire que je n'aime pas jQuery (je m'en sert fréquemment). C'est pour cela que je proposais : plugin utilisant du jQuery = insertion d'une bonne version jQuery. Idem au cas ou un plugin futur utiliserai MooTools, Prototype, ou du fait maison... Enfin bref voila

Jerry Wham · février 2013

Jos a écrit:

+1 @danielsan.

Tout le monde n'utilise pas jQuery. De toute façon, il me semble que Stéphane n'en veut pas par défaut dans le thème : il me semble qu'on en avait parlé par mail avant la sortie de la 5.1.7, donc il y a plus grand chose à dire sur sujet.

Chacun à sa philosophie, et les deux approches sont bonnes. Ça ne veut pas dire que je n'aime pas jQuery (je m'en sert fréquemment). C'est pour cela que je proposais : plugin utilisant du jQuery = insertion d'une bonne version jQuery. Idem au cas ou un plugin futur utiliserai MooTools, Prototype, ou du fait maison... Enfin bref voila

Plus un test permettant de savoir si jQuery est déjà chargée pour éviter de la charger 10 fois. Si elle n'est pas chargée, on charge la version nécessaire au fonctionnement du plugin.

Merci et (préchargement...)

Réponses