Afficher les éléments de la sidebar dans une page statique

zetraderzetrader Member
décembre 2015 modifié dans Discussions générales
Bonjour, quand je copie-colle le code de la sidebar (celui qui affiche les catégories du blog ou encore les derniers articles ou les derniers commentaires) dans une page statique, je me retrouve face à une erreur d'affichage.
Est-ce possible d'afficher dans une page statique les éléments de la sidebar tels que :
1) catégories du blog
2) derniers articles
3) derniers commentaires
4) archives du blog

Ces éléments étant par défaut dans la sidebar.
J'ai un blog avec plus de 1000 articles et plus de 1000 commentaires, l'idée serait de supprimer le chargement de la sidebar sur tous les articles (pour faire moins de requêtes sur l'ensemble du site et avoir plus de largeur d'écran pour chaque article, pour les images etc...) et mettre un lien type ancre dans le menu header qui renvoie vers une page statique (en page d'accueil par exemple) dans laquelle se trouve les éléments de "l'ex-sidebar" :
catégories, derniers articles, derniers coms, archives...

Merci pour vos réponses.

Pierre

Réponses

  • Pour faire ça, tu peux par exemple créer un nouveau modèle de page statique.
    Par exemple pour le thème inclus dans PluXML, j'ai fait un mélange de "static.php" et "static-full-width.php" pour créer le fichier "static-sidebar.php" que j'ai inclus à la fin de ce message
    Ensuite tu crées une nouvelle page statique et tu choisis le modèle "static-sidebar" dans la liste de modèle en bas de la page d'édition

    Voilà un exemple de contenu mais tu peux adapter en enlevant le "include" et en copiant directement les bouts du fichier sidebar.php qui t'intéressent
    <?php include(dirname(__FILE__) . '/header.php'); ?>
    
        <main class="main grid" role="main">
    
            <section class="col sml-12">
    
                <article class="article static" role="article" id="static-page-<?php echo $plxShow->staticId(); ?>">
    
                    <header>
                        <h1>
                            <?php $plxShow->staticTitle(); ?>
                        </h1>
                    </header>
    
                    <section class="contenuPageStatique">
                        <?php $plxShow->staticContent(); ?>
                    </section>
                    
                    <section class="contenuSidebar">
                        <?php include(dirname(__FILE__) . '/sidebar.php'); ?>
                    </section>
                    
                </article>
    
            </section>
    
        </main>
    
    <?php include(dirname(__FILE__).'/footer.php'); ?>
    
    
    
  • zetraderzetrader Member
    décembre 2015 modifié
    Merci mais c'est pas exactement ce que je veux faire (car j'ai d'autres pages statiques où je ne veux pas forcément que le code se recopie à chaque fois), et si je veux le mettre juste dans une seule page statique (en l'occurrence une page statique mise en page d'accueil de mon site) et pas les autres ?
    Bon si il n'y a pas moyen, peut-être que je laisserai l'affichage de la sidebar juste pour les pages statiques ou j'adapterai toutes les pages statiques selon ce modèle, mais si je pouvais juste appliquer le code de cette sidebar dans cette seule page statique mise en page d'accueil, j'aimerais bien.
  • zetrader a écrit:
    Merci mais c'est pas exactement ce que je veux faire (car j'ai d'autres pages statiques où je ne veux pas forcément que le code se recopie à chaque fois), et si je veux le mettre juste dans une seule page statique (en l'occurrence une page statique mise en page d'accueil de mon site) et pas les autres ?
    oui ce qu'il se passe avec ce que je t'ai proposé
    pour une page tu indiques le modèle "static-sidebar" et pour les autres tu laisses "static-full-width" pour ne pas afficher la "sidebar"
  • zetraderzetrader Member
    décembre 2015 modifié
    Ok je vois, un modèle personnalisé juste pour une seule page static, autant pour moi, je vais voir cela, merci.
    Sinon au niveau temps de chargement des articles cela a bien gagné en vitesse en supprimant le chargement de la sidebar pour les articles, autre chose que j'avais vu qui permet de gagner beaucoup de temps de chargement sur toutes les pages (à partir du moment où on a plus de 1000 pages sur le site, chaque ensemble de requêtes répétées sur chaque page peut compter, il faut penser que c'est répété plus de 1000 fois à chaque fois, sur un site qui a du trafic, cela peut consommer beaucoup de ressources, à voir si les requêtes en question sont vraiment utiles et valent le coup de ralentir tout le site) : supprimer le nuage de mots clés de la sidebar (pas très utile à mon goût en plus, je doute que beaucoup de visiteurs cherchent selon ce nuage de mots clés), mon site ramait à un moment, en supprimant le nuage de mots clés de la sidebar, le gain de vitesse a été considérable, visiblement consomme beaucoup de ressources quand il se retrouve sur pas mal de pages (dans ce que j'ai testé à supprimer c'est je crois l'une des choses qui m'a fait gagner le plus de vitesse dans le chargement, passé de vitesse lente à beaucoup plus correcte).
    Si vous avez un blog avec beaucoup d'articles/pages et que cela se met à ramer, testez la suppression de l'affichage du nuage de mots clés (tags) dans la sidebar pour les diverses catégories (articles, tags etc...), la différence de vitesse de chargement de vitesse pourrait vous bluffer :)
  • Une autre chose qui pourrait faire gagner du temps de chargement est un système de cache.
    Si tu as envie d'afficher la liste des dernières articles et des rubriques sur toute les pages, le système de cache peut par exemple créer un fichier HTML qui sera inclus sur toutes les pages sans passer par le calcul de cette partie à chaque chargement
  • bazooka07bazooka07 PluXml Lead Developer, Moderator
    Bonjour,

    C'est vrai qu'avec 1000 articles, il faudrait songer à optimiser Pluxml.
    Si on regarde le fichier data/configuration/tags.xml, on constate qu'on ne fait que recenser les tags par article.
    Lors de la mise à jour de ce fichier dans le back-office, on pourrait très bien recenser le nombre d'articles par tag. Cela éviterait de faire ce calcul pour chaque visiteur dans $plxShow->tagList(). De plus par défaut, on affiche tous les tags. On peut limiter leur nombre par
    $plxShow($format, $nbTagsAffiches);
  • en fait zetrader est ce que tu parles de ton site qui est dans ton profil ?
    chez moi les pages des articles, par exemple, s'affiche aux environ des 0,3 secondes, il n'y a pas trop besoin d'optimisation pour cela
  • bazooka07bazooka07 PluXml Lead Developer, Moderator
    Si je compte bien avec mon tableur, cela fait 1258 articles.
    Si tu enlèves les mot-clés, tu peux aussi essayer d'enlever les archives de la sidebar pour gagner un peu plus en vitesse.
  • zetraderzetrader Member
    décembre 2015 modifié
    mathieu a écrit:
    en fait zetrader est ce que tu parles de ton site qui est dans ton profil ?
    chez moi les pages des articles, par exemple, s'affiche aux environ des 0,3 secondes, il n'y a pas trop besoin d'optimisation pour cela

    Bonjour Mathieu, oui je parle de mon site dans mon profil, mais les 0,3 secondes que tu vois c'est après déjà plusieurs optimisations (dont la dernière le retrait de la sidebar pour les articles, avec cela sur les articles cela peut même parfois descendre vers 0,1 seconde de chargement par article, ce que cela ne faisait jamais avant ce changement, plutôt entre 0,2 au mini et 0,6 seconde), avant optimisations (par exemple avant le retrait du nuage de tags des diverses catégories de pages : articles/tags/catégories etc..) cela mettait plusieurs secondes (parfois entre 6 et 10 secondes par article) à charger par article ou page, donc oui maintenant après avoir optimisé déjà pas mal, cela change énormément (grosso modo entre 10 et 30 fois moins de temps à charger maintenant qu'avant les toutes premières optimisations en voyant que le site était devenu trop lent à charger de manière générale) et c'est devenu beaucoup plus correct.
    C'est vrai qu'avant de faire des optimisations diverses, quand en testant sur plusieurs jours, cela mettait parfois 10 secondes à m'afficher un article je commençais à me dire que j'arrivais aux limites de pluxml et que j'allais devoir changer de cms, déçu, puis finalement j'ai essayé plusieurs trucs, changement de version de php utilisée par l'hébergeur (en passant à php 5.6 cela a accéléré aussi), compression gzip, tests de suppressions de requêtes, pour certaines cela change quasi rien, pour d'autres gros changements de vitesse, et finalement j'ai pu voir que pas mal optimisé et bien que sans bdd, il n'est pas impossible que pluxml puisse avoir des milliers d'articles et commentaires tout en restant rapide si on ne charge pas trop la barque en requêtes inutiles.
    Cela ne m'étonnerait pas que pluxml (à condition de l'optimiser un peu, rester light au niveau requêtes globales) puisse rester assez rapide vers les 5000 articles et commentaires, parce que j'ai déjà vu un modèle de forum sans bdd (les topics sont juste dans des fichiers txt) qui pouvait héberger des milliers de topics et rester rapide (je connais un site qui tourne encore avec ce vieux modèle de forum sans bdd des milliers de topics, dizaines de milliers de posts et cela reste encore bien rapide).
    Donc si un vieux modèle de forum sans bdd peut rester rapide avec des dizaines de milliers de posts, pourquoi pas pluxml ?
  • bazooka07bazooka07 PluXml Lead Developer, Moderator
    Une autre piste serait de remplacer le format xml par du json.
    Les fichiers seraient plus légers, mais surtout la lecture de fichiers JSON se fait en une ligne de code contre une boucle et une dizaine de lignes en XML..
  • zetrader a écrit:
    le retrait de la sidebar pour les articles
    oui j'ai vu mais la sidebar est sur la page d'accueil qui s'affiche très bien c'est pour ça je demandais
    pour ma part mon critère est un temps de chargement de 1 s maximum. tant que toute les pages se chargent dans ce délai je ne cherche pas à optimiser, que se soit avec PluXML, WordPress ou autre.

    je vais déjà voir comment mettre en cache le nuage de mots, ça me donnera peut-être des pistes pour mettre en cache toute la sidebar

    bazooka07 a écrit:
    Une autre piste serait de remplacer le format xml par du json.
    Les fichiers seraient plus légers, mais surtout la lecture de fichiers JSON se fait en une ligne de code contre une boucle et une dizaine de lignes en XML..

    oui j'ai aussi suivi cette piste puisqu'en ce moment j'utilises JSON dans plein de projets.
    mais le gain n'est que de 20 % en espace disque et 20 % de gain en temps de lecture donc je pense que ce n'est pas une raison pour réécrire tout le cœur de PluXML (qui s'appèlerai alors PluJSON 8) :P )
  • J'ai commencé une extension qui mets les parties gourmandes de la sidebar en cache.

    Il y a un thème d'exemple qui est basé sur le thème par défaut donc tu peux l'essayer directement :
    http://forum.pluxml.org/viewtopic.php?id=5352
  • bazooka07 a écrit:
    Bonjour,

    C'est vrai qu'avec 1000 articles, il faudrait songer à optimiser Pluxml.
    Si on regarde le fichier data/configuration/tags.xml, on constate qu'on ne fait que recenser les tags par article.
    Lors de la mise à jour de ce fichier dans le back-office, on pourrait très bien recenser le nombre d'articles par tag. Cela éviterait de faire ce calcul pour chaque visiteur dans $plxShow->tagList(). De plus par défaut, on affiche tous les tags. On peut limiter leur nombre par
    $plxShow($format, $nbTagsAffiches);
    d'ailleurs, j'aimerais savoir s'il n'y aurait pas moyen d'avoir l'approche des tags mais SANS le compteur ?
    afficher pour chaque tag la liste des articles associés (comme si c'était des catégories) ..?
  • danielsan a écrit:
    d'ailleurs, j'aimerais savoir s'il n'y aurait pas moyen d'avoir l'approche des tags mais SANS le compteur ?
    afficher pour chaque tag la liste des articles associés (comme si c'était des catégories) ..?
    ce n'est pas la question ici, ça serait mieux que tu commences une nouvelle discussion.
Connectez-vous ou Inscrivez-vous pour répondre.