Astuce

Ajouter des custom post types aux pages d’archives

Par défaut, WordPress n’affiche pas les custom post types, ces formats de publications différents des articles de base, sur les pages d’archive, notamment celles qui listent toutes les publications pour une année, un mois ou un jour. C’est un choix assumé des créateurs du logiciel, qui considèrent que si l’on a besoin d’un type d’article personnalisé, c’est pour le séparer complètement du contenu principal. Néanmoins, ce n’est pas toujours ce que l’on cherche, et ce n’est pas ce que je voulais pour les mises à jour d’articles que j’ai ajoutées à mon blog personnel il y a quelques mois. Vous retrouverez les explications complètes à ce sujet dans cet article précédent.

Je voulais avoir des archives temporelles complètes, avec les articles de base et le type personnalisé créé pour les mises à jour. La solution était finalement assez simple, même si elle implique d’ajouter quelques lignes de code au thème. Le plus simple est de le faire dans le fichier functions.php, mais vous pouvez aussi le faire dans un module dédié si vous le souhaitez. Rappelons que la première méthode rend la fonction dépendante du thème et vous la perdrez si vous changez de thème pour votre blog.

Voici ce que j’utilise pour mon blog. Le point important est la cinquième ligne, c’est ici que vous pourrez choisir tous les types d’article à prendre en compte. Dans mon cas, il n’y en a que deux, les articles de base (post) et les mises à jour (maj_post), vous devrez adapter en fonction de vos besoins.

add_action('pre_get_posts', 'query_post_type');
function query_post_type($query) {
  if($query->is_main_query()
    && ( is_archive() && !is_admin() )) {
        $query->set( 'post_type', array('post','post_maj') );
  }
}

J’ai trouvé ces quelques lignes de code à cette adresse. La seule modification apportée est à la ligne 4, puisque je voulais appliquer le code pour toutes les pages d’archive (condition is_archive) et ne pas l’appliquer sur les pages d’administration du blog (condition !is_admin). Sans cela, j’avais les mises à jour d’articles et les articles mélangés côté administration.

Vous pouvez voir le résultat sur cette page d’archive, il y a à la fois des articles standard et des custom post types, au même niveau. Et comme toujours, l’intégralité de mon thème est disponible sur GitHub, si vous voulez voir ce que cela donne dans son contexte.

Publicités

Remonter des articles sans modifier leur date de publication

J’ai enfin trouvé comment résoudre un problème que j’avais depuis plusieurs années sur mon blog personnel : je souhaite remonter de temps en temps un article que j’ai mis à jour, mais sans toucher à sa date de publication. Faute de mieux, je mettais l’article en question en avant, ce qui le plaçait effectivement sur la page d’accueil. C’était une solution toutefois temporaire et l’article disparaissait quand je retirais la mise en avant.

voiretmangerfr-full

Le résultat final : le premier article affiché sur la page d’accueil a été publié en 2015.

Sans compter que je voulais aller un petit peu plus loin. Mon idée était de remonter un article comme si je venais de le publier, et ainsi de le voir en tête sur la page d’accueil, puis descendre la liste au fil du temps. Mais tout cela, sans modifier la date originale de publication qui reste une information importante à mes yeux. Difficulté supplémentaire, l’article mis à jour doit apparaître dans le flux RSS du blog, à nouveau comme s’il s’agissait d’une publication supplémentaire.

Pourquoi vouloir ce comportement ? J’écris sur des séries et je mets à jour un article unique à chaque nouvelle saison. Je pourrais créer un nouvel article à chaque fois, mais je préfère garder un article unique, modifié au fil du temps.

serie-saison-exemple.png

Exemple de mise à jour de série sur le blog.

Lire la suite

Articles en avant et pagination

Je suis tombé sur un oubli étrange de WordPress : on peut aisément mettre en avant un article, qui sera alors affiché au-dessus des autres triés normalement par ordre chronologique, mais la pagination n’en tient pas compte. Si vous avez configuré votre blog pour afficher 10 articles par page et que vous en mettez un autre en avant, vous aurez 11 articles sur la page d’accueil et les autres pages seront aussi décalées.

Quand on utilise une seule boucle pour afficher les articles sur la page d’accueil, WordPress devrait prendre en compte ceux en avant, et afficher toujours le même nombre d’articles réglés dans les préférences. Ce n’est pas le cas par défaut, mais il existe une solution assez simple : utiliser l’action pre_gest_posts pour modifier les fonctions de base et calculer diffémment le nombre d’articles à afficher et la pagination.

Cela vous semble compliqué ? Il suffit pourtant de coller ce code dans le fichier functions.php  de votre thème et ce sera automatique !

// Prise en charge des sticky posts et pagination corrigée (source http://wordpress.stackexchange.com/questions/180005/include-sticky-post-in-page-posts-count/180021#180021)
add_action( 'pre_get_posts', function ( $q ) 
{

    if ( $q->is_home() ) {

        $count_stickies = count( get_option( 'sticky_posts' ) );
        $ppp = get_option( 'posts_per_page' );
        $offset = ( $count_stickies <= $ppp ) ? ( $ppp - ( $ppp - $count_stickies ) ) : $ppp;

        if (!$q->is_paged()) {
          $q->set('posts_per_page', ( $ppp - $offset ));
        } else {
          $offset = ( ($q->query_vars['paged']-1) * $ppp ) - $offset;
          $q->set('posts_per_page',$ppp);
          $q->set('offset',$offset);
        }

    }

});    

add_filter( 'found_posts', function ( $found_posts, $q ) 
{

    if( $q->is_home() ) {

        $count_stickies = count( get_option( 'sticky_posts' ) );
        $ppp = get_option( 'posts_per_page' );
        $offset = ( $count_stickies <= $ppp ) ? ( $ppp - ( $ppp - $count_stickies ) ) : $ppp;        

        $found_posts = $found_posts + $offset;
    }
    return $found_posts;

}, 10, 2 ); 

Par rapport au code original déniché sur StackExhange, j’ai retiré la condition is_main_query, puisque cela ne fonctionnait pas dans mon cas. Comme je n’ai qu’une seule requête sur la page d’accueil de mon blog, ce n’est pas très grave, mais vous devrez peut-être ajuster ce paramètre.

Ajoutons que cela ne fonctionne que pour la page d’accueil, si vous voulez la même chose sur toutes les pages d’archive, il faudra également retiré la condition is_home.

Changer l’URL d’un site avec WP-CLI

WP-CLI nécessite un accès SSH au serveur, c’est-à-dire un accès via un terminal. C’est le cas quand vous gérez votre propre serveur (dédié ou VPS), mais aussi chez certains hébergeurs mutualisés1. Si vous avez cela, n’hésitez pas et installez cette extension très pratique pour plein de petites choses qui sont pénibles à utiliser avec une interface, mais très simples au contraire en ligne de commande.

Je l’utilise essentiellement pour gérer la base de données. De temps en temps, je crée une sauvegarde en tapant uniquement wp dp export et j’obtiens dans la foulée un fichier SQL que je récupère ensuite sur mon ordinateur et que je stocke sur un autre serveur. Autre commande intéressante : wp db optimize qui, comme son nom l’indique, active les fonctions d’optimisation indispensables de temps à autre.

Mais le cas le plus utile pour moi jusque-là a été le changement de toutes les occurences de l’ancienne URL quand j’ai passé mon blog personnel en HTTPS. En utilisant une seule commande, WP-CLI a cherché dans la base de données toutes les fois où l’ancienne adresse était présente et l’a remplacé par la nouvelle. Le tout est fait proprement, sans risque  de casser quoi que ce soit, et surtout en évitant les pièges habituels en la matière (quand on le fait avec une requête SQL classique, on peut passer à côté de certaines occurrences, ou casser quelque chose).

wpcli-searchreplace.png
Si vous pouvez installer WP-CLI et que vous voulez changer un élément dans la base de données (ce n’est pas forcément une URL d’ailleurs, tout est possible), voici ce qu’il faut faire :

wp dp export
wp search-replace 'texte original' 'texte final' --skip-columns=guid

La première ligne vous assure une solution de replis en cas d’erreur, la deuxième opère les changements. En retour, vous aurez la liste de tout ce qui a été modifié dans la base de données, une première vérification indispensable avant d’ouvrir le site pour s’assurer que tout est correct.

Pour en savoir plus sur cette commande et les différentes options proposées, la documentation officielle est un incontournable…

Rappel : il ne suffit pas de changer la base de données si on veut changer l’URL d’un blog WordPress. Il faut aussi mettre à jour l’adresse dans les options, comme c’est expliqué dans le Codex, la documentation officielle du CMS.


  1. En France, Web4All et MonArobase proposent cette fonction. 

Désactiver les pages dédiées aux médias de WordPress

Par défaut, WordPress permet d’afficher chaque média mis en ligne sur le blog sur une page dédiée. Ce qui est affiché varie en fonction du thème, mais on retrouve général le nom du média et le fichier lui-même est affiché juste en-dessous. Parfois, on a même des commentaires associés à la pièce-jointe.

attachment-template.png

Si, comme moi, vous ne voulez pas de cette fonction, la solution est très simple. Il suffit de modifier le template attachment présent dans tous les thèmes en remplaçant tout le contenu par cette ligne unique :

wp_redirect(get_permalink($post-&gt;post_parent));

Le code est extrêmement simple : il renvoie à l’article associé à la pièce-jointe. En théorie, si un visiteur tombe sur l’ancienne page dédiée à une image, il verra la photo dans son contexte, puisqu’il sera automatiquement redirigé vers l’article qui contient l’image. Simple, mais efficace !

Bonus : WordPress permet de changer de modèle en fonction de la pièce-jointe. On peut ainsi garder le template générique d’origine, mais créer un fichier image.php avec la ligne donnée plus haut pour transférer les visiteurs uniquement sur les photos, mais pas les fichiers PDF. Par exemple.

Comme d’habitude, vous pouvez voir l’astuce en action sur mon blog personnel à cette adresse.

Trier les articles par date de modification dans l’admin

S’il vous arrive de modifier régulièrement les articles sur votre blog, comme c’est mon cas, vous avez peut-être envie de lister les dernières modifications dans l’administration. Par défaut, WordPress ne propose pas cette option et si l’on a plusieurs choix de colonnes, on n’a que la date de publication comme choix de date. Avec un peu de code, vous pouvez néanmoins facilement y remédier et obtenir ceci :

admin-tri-modification.png

Cliquer sur l’image pour l’agrandir

Avant toute chose, sachez que j’ai utilisé ce plugin comme base. Il n’a pas été mis à jour depuis des années et il fonctionne très bien, mais je voulais le modifier et je préfère tout conserver dans le fichier functions.php de mon thème. Ce n’est pas un bon conseil de manière générale, puisque si je changeais de thème, je perdrais tout, mais ce thème est conçu par mes soins et si je le modifie, je sais ce que je dois faire.

Bref, mieux vaut utiliser le plugin, mais si vous êtes comme moi, voici le code complet :

// Tri dans la colonne des news par dernière modif (source : https://wordpress.org/plugins/sort-by-modified/)

// Register Modified Date Column for both posts & pages
function modified_column_register( $columns ) {
$columns['date modif'] = __( 'Modification', 'date modified' );

return $columns;
}
add_filter( 'manage_posts_columns', 'modified_column_register' );
add_filter( 'manage_pages_columns', 'modified_column_register' );

// Display the modified date of each post
function modified_column_display( $column_name, $post_id ) {
global $post;
$modified = the_modified_date();
echo $modified;
}
add_action( 'manage_posts_custom_column', 'modified_column_display', 10, 2 );
add_action( 'manage_pages_custom_column', 'modified_column_display', 10, 2 );

// Register the column as sortable
function modified_column_register_sortable( $columns ) {
$columns['date modif'] = 'modified';
return $columns;
}
add_filter( 'manage_edit-post_sortable_columns', 'modified_column_register_sortable' );
add_filter( 'manage_edit-page_sortable_columns', 'modified_column_register_sortable' );

Je n’ai pas modifié grand-chose, simplement traduit le nom de la colonne et ajouté date dans son nom. Cette opération m’a permis d’avoir une colonne de la même taille que celle de date ajoutée par WordPress sans effort supplémentaire, puisque l’on retrouve alors le même identifiant. J’ai aussi retiré une partie du code original qui concernait les articles pas standard (« post_type »), étant donné que je n’en ai pas sur mon blog.

Ajoutez le plugin ou le code quelque part, et vous aurez désormais une colonne avec la date de modification de chaque article. Et on peut trier la liste par cette colonne : voilà un moyen simple et efficace de trouver les derniers articles modifiés !

Passer à PHP 7 avec un mutualisé chez OVH

Si vous utilisez WordPress — et c’est certainement le cas si vous suivez ce blog — et que vous hébergez votre blog sur l’une des offres mutualisées d’OVH, vous pouvez désormais passer à PHP 7 ! Cette mise à jour majeure se concentre sur la vitesse d’exécution et le gain est très net. Sans rien changer à votre installation, sans aucun effort d’optimisation, le site sera plus rapide, tout particulièrement s’il est complexe.

J’ai repris le module qui m’avait servi à comparer plusieurs hébergeurs pour vérifier sur mon blog personnel s’il y avait une différence visible entre le PHP 5 qui était jusque-là la norme, et le PHP 7 qui va le devenir. Comme vous pourrez le constater, on gagne sur tous les tableaux : le site est plus rapide à exécuter le PHP et les tests spécifiques à WordPress montrent également que le blog va tourner plus vite. Dans certains cas, on divise par trois le temps d’exécution, ce qui permet alors de passer de plus d’une seconde à 300 ms, un temps quasiment imperceptible pour le visiteur.

php-7-chiffres

Avant de continuer, un mot au sujet de la compatibilité. PHP 7 est une mise à jour majeure qui casse plusieurs choses qui fonctionnaient auparavant. Concrètement, cela veut dire que la mise à jour peut bloquer certaines fonctions, voire le site tout entier dans les cas les plus graves. Si vous utilisez WordPress toutefois, vous devriez être tranquille : la dernière version du CMS fonctionne parfaitement avec PHP 7 et certains modules ou thèmes peuvent être incompatibles, mais ils sont a priori très rares.

En cas de problème, vous pourrez toujours revenir en arrière. Je vous conseille ainsi d’essayer, et d’annuler le changement si quelque chose ne fonctionne plus.

Comment activer PHP 7 sur votre hébergement mutualisé OVH ? C’est très facile : il suffit de se connecter en FTP à votre compte et de modifier le fichier .ovhconfig qui se trouve à la racine de votre site, ou bien de modifier celui à la racine de votre compte. Vous pouvez ainsi gérer chaque site différemment et n’activer PHP 7 que là où c’est possible, tout en gardant les autres sites hébergés avec une ancienne version.

ovhconfig

Voici ce que doit contenir le fichier pour activer PHP 7 :

app.engine=php
app.engine.version=7.0
http.firewall=none
environment=production

Si le fichier est déjà présent, modifiez la deuxième ligne et remplacer la valeur après le = par 7.0. S’il n’est pas présent, vous pouvez créer ce fichier en reprenant bien son nom (le point au début est essentiel). Enregistrez les modifications et vérifiez immédiatement que tout fonctionne. Si ce n’est pas le cas, vous pouvez supprimer le fichier et vous reviendrez à la version précédente de PHP.

Pour plus de détails ou si vous avez des questions ou des problèmes sur la transition, un sujet dédié a été ouvert dans les forums d’OVH.

Recompter le nombre de commentaires pour tous les articles

Pour des raisons de performance, WordPress ne compte pas chaque commentaire quand il doit afficher leur nombre sous un article. Cette valeur est « cachée », c’est-à-dire qu’elle est stockée dans la base de données et c’est ce nombre qui est affiché. Quand un commentaire est ajouté, le CMS met automatiquement à jour cette valeur, si bien que c’est toujours la bonne qui est affichée.

Il y a un cas de figure toutefois qui fait que l’on doit forcer un nouveau comptage des commentaires. Si vous acceptiez les pingbacks sur votre blog — c’est le réglage par défaut — et si vous décidez ensuite de ne plus les afficher, le nombre de commentaires mémorisé dans la base de données sera faux pour tous les articles qui ont eu des pingbacks. C’est le cas par exemple sur cet article : quatre commentaires annoncés, alors qu’il n’y en a que trois d’affichés.

Quatre commentaires annoncés, alors qu'il n'y en a que trois d'affichés.

Quatre commentaires annoncés, alors qu’il n’y en a que trois d’affichés.

Naturellement, si vous recevez beaucoup de commentaires, le chiffre finira par être mis à jour sitôt qu’un lecteur commentera un article. Mais si vous avez beaucoup d’articles, les compteurs faux resteront probablement un bon moment. Et si vous n’aimez pas avoir de faux compteurs, voici la méthode à suivre pour recompter le nombre de commentaires pour tous les articles. Lire la suite

Articles similaires Jetpack : augmenter la taille des images

Si vous utilisez la fonction « Articles similaires » du module Jetpack sur votre blog WordPress et que vous souhaitez modifier la présentation par défaut (j’ai déjà expliqué ma méthode dans un précédent article), vous allez peut-être tomber sur mon problème. En choisissant d’afficher trois articles similaires sur toute la largeur de la page, j’ai vite noté que les images étaient de mauvaise qualité. La raison est simple : par défaut, le module utilise des images de 350 pixels de large et quand on agrandit le site, elles sont agrandies à tel point qu’elles deviennent floues.

Cliquer pour voir la différence

Cliquer pour voir la différence

Fort heureusement, la solution est tout aussi simple. Il suffit d’ajouter ces quelques lignes de code dans le fichier functions.php de votre thème. Remplacez les tailles aux lignes 2 et 3 par les valeurs qui vous intéressent, pour ma part j’ai choisi 1000 pixels de large pour avoir de la marge (il faudrait environ 850 pixels pour que les images soient nettes en pleine largeur sur un écran 27 pouces). Le CSS se charge de limiter la taille des images affichées sur le blog pour qu’elles restent au tiers de la largeur, quelle que soit la largeur de la page.

function jetpackchange_image_size ( $thumbnail_size ) {
    $thumbnail_size['width'] = 1000;
    $thumbnail_size['height'] = 572;
    return $thumbnail_size;
}
add_filter( 'jetpack_relatedposts_filter_thumbnail_size', 'jetpackchange_image_size' );

Naturellement, le temps de chargement sera légèrement plus long, mais ces images ne sont pas piochées sur votre serveur. En effet, les images des articles similaires proviennent des serveurs de WordPress, qui sont probablement beaucoup plus rapides que celui qui héberge votre blog. Au passage, précisons que le module gère parfaitement les écrans Retina. Si vous affichez le site sur un tel écran, l’image sera automatiquement remplacée par une version optimisée, deux fois plus grande en largeur et en hauteur, donc.

Mise à jour 26 janvier : un point important qui m’avait échappé, si vous changez la taille des images comme je l’ai fait, le module cherchera nécessairement des images plus grandes. Si celle qui a été mise en avant avec un article est trop petite, il ira chercher une plus grande dans l’article.

Un point à ne pas oublier au moment de définir la taille des images : j’ai abaissé à 900 pixels de large dans mon cas, pour avoir la bonne image sur les anciens articles.

Afficher le nombre de commentaires avec des mots

Petite astuce rapide si vous voulez, comme moi, afficher le nombre de commentaires avec des mots, plutôt qu’avec un chiffre. Par défaut, WordPress n’affiche qu’un chiffre et, étonnamment, il n’y a aucune fonction standard pour convertir un chiffre en mot, ou réciproquement, en PHP. Voici la méthode très simple que j’ai suivie pour cette conversion.

commentaire-mot
Lire la suite