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.

Ajoutez un petit peu de couleurs à vos articles

Si le thème de votre site n’est pas marqué par une couleur dominante, comme c’est le cas pour mon blog, vous pouvez ajouter une petite touche de couleur à chaque article en suivant cette astuce. L’idée est de partir de l’image à la une pour déterminer une teinte dominante et utiliser cette teinte dans le thème. Pour ma part, je l’utilise sur les liens au survol et sur les boutons de partage et les métadonnées en bas de chaque article.

Voici ce que cela donne avec trois exemples différents :

haut.jpg

Lire la suite « Ajoutez un petit peu de couleurs à vos articles »

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.

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.

J’ai failli abandonner WordPress…

Depuis plusieurs années, j’ai envie d’abandonner WordPress. Non pas que le CMS le plus populaire sur internet soit vraiment un problème, mais je me suis lassé de ses lourdeurs, de ses multiples extensions et surtout de son code PHP souvent assez lourd. Lourd pour le serveur, mais aussi, il faut être honnête, pour moi qui ne suis pas développeur. Modifier le thème est toujours assez compliqué, on fait souvent des erreurs (il suffit d’oublier un point virgule), bref, c’est contraignant.

Ainsi, j’ai essayé à plusieurs reprises des moteurs de blogs statiques qui permettent de générer l’intégralité du site sur son ordinateur, et de ne publier que des fichiers HTML sur le serveur. Une approche qui a plusieurs avantages, à commencer par la légèreté du site final. Il n’y a plus de bases de données, plus de création à la volée des pages, tout est prévu à l’avance et le serveur ne sert que du contenu HTML. Par ailleurs, cette solution simplifie le développement, puisque l’on ne travaille qu’en local. On génère le site et si tout est cassé, il suffit de modifier, générer à nouveau l’ensemble et c’est terminé. Quand tout est prêt, on synchronise le serveur.

Lire la suite « J’ai failli abandonner WordPress… »