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.

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 « Remonter des articles sans modifier leur date de publication »

Guide : transférer un blog WordPress sur un VPS

Préambule

Pendant très longtemps, on n’avait que deux choix quand on voulait héberger un site : acheter ou louer son propre serveur, ou utiliser une offre d’hébergement mutualisé. La première solution est plus souple, mais aussi beaucoup plus coûteuse et complexe. La deuxième est moins chère, mais souvent plus contraignante et généralement moins performante.

168925884_d8cefb7e4f_o.jpg
Des serveurs dédiés (Photo Tim Dorr — CC BY-SA 2.0)

Depuis quelques années, une troisième voie s’est formée avec les VPS, les « Virtual Private Servers », des serveurs dédiés virtuels en français. C’est un serveur dédié, dans le sens où vous gardez un contrôle total sur l’installation, du système d’exploitation (Linux en général) au moteur qui alimentera le site. Mais il est virtuel, puisque chaque VPS ne correspond pas à une machine physique : c’est ce qui explique que le coût est bien plus faible. Alors qu’un serveur dédié coûte en général plusieurs dizaine d’euros par mois au minimum, un VPS est facturé moins de 5 € pour les premières offres.
Ces offres sont si bon marché, qu’elles concurrencent même les offres mutualisées, traditionnellement les moins chères de toutes. C’est pourquoi héberger son blog sur un VPS peut être si intéressant. Néanmoins, c’est aussi plus exigeant, puisqu’il faut gérer le serveur à l’aide d’un terminal : même si on peut installer une interface d’administration, comme cPanel, il faut en général payer un supplément, et on perd le plus gros intérêt des serveurs virtuels, à savoir leur performance.

Pour autant, héberger un blog WordPress sur un VPS n’est pas si compliqué que cela en a l’air. Surtout en s’aidant d’un outil comme ServerPilot, un assistant qui vient configurer le VPS et surtout à le maintenir en état de marche. Une fois configuré, le serveur est maintenu à jour et sécurisé, avec la bonne configuration pour éviter les hacks. Une fois le transfert du blog terminé, vous aurez normalement la même charge de travail qu’avec un hébergement.

Lire la suite « Guide : transférer un blog WordPress sur un VPS »

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.

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 !

Retirer les balises <p> autour des images

Petite astuce rapide pour un problème assez simple : pour simplifier la vie des rédacteurs, WordPress ajoute les balises <p> nécessaires pour créer des paragraphes autour de tous les blocs de texte que vous créez. Le problème, c’est qu’il en ajoute un peu trop, et il en place notamment autour des images, où elles ne sont pas nécessaires.

Une image n’est pas un paragraphe de texte et il n’y a pas besoin d’en mettre. Ce n’est pas non plus forcément gênant, puisque tous les navigateurs savent afficher normalement les images, même avec les balises de paragraphe superflues. Cela dit, si on souhaite afficher des images sur toute la largeur, comme c’est le cas sur mon blog, ces balises gênent la mise en page. Je veux que l’image soit bord à bord, sans la moindre bordure, mais en revanche le texte ne doit pas coller les bords de la fenêtre pour rester lisible. Ainsi, je veux définir les images à 100 %, mais je veux ajouter un peu de marge sur le texte.

images-balise-p

Pour régler ce problème, le plus simple est de retirer les balises <p>, mais uniquement autour des images — on veut les conserver autour du texte. Il se trouve que c’est possible, et c’est même assez simple : il suffit d’ajouter cette fonction au fichier functions.php de votre thème :

function filter_ptags_on_images($content){
   return preg_replace('/<p>s*(<a .*>)?s*(<img .* />)s*(</a>)?s*</p>/iU', '123', $content);
}

add_filter('the_content', 'filter_ptags_on_images');

Et voilà, les images ne seront plus transformées en paragraphes ! Je n’ai pas inventé le code, il vient de cet article.

Ajoutez l’image à la une au flux RSS

Depuis quelques versions déjà, WordPress permet de définir tres simplement une « image à la une ». Qu’il s’agisse de l’une des images insérées à l’article ou une autre photo, cette image devient en tout cas associée à l’article et elle est utilisée par les thèmes en général. Sur mon blog par exemple, c’est cette image qui est affichée sur la page d’accueil, au-dessus du texte dans un article ou encore dans les listes d’archive et résultats de recherche.

Autant dire que, pour ce blog très visuel, ces images sont essentielles. À mes yeux, l’image suffit à identifier l’article, avant même le titre qui reste essentiel, naturellement. L’image à la une est donc une fonction très utile, et pourtant, pour une raison qui reste mystérieuse, WordPress ne l’utilise pas dans le flux RSS. On peut toutefois facilement ajouter cette image à son flux et voici ma méthode.

Même s’il existe plusieurs extensions capables de le faire, j’ai choisi de le faire sans, puisque le code à ajouter est très réduit. Si vous ne voulez pas toucher au thème que vous utilisez ou si un peu de PHP vous effraie, mieux vaut toutefois passer par un plugin, naturellement… Sans plus attendre, voici le code à ajouter au fichier functions.php de votre thème :

function rss_post_thumbnail($content) {
    global $post;
    if(has_post_thumbnail($post->ID)) {
        $content = '<p>' . get_the_post_thumbnail($post->ID, 'full') .
        '</p>' . get_the_content();
    }   
    return $content;
}

add_filter('the_content_feed', 'rss_post_thumbnail');

Deux ou trois remarques au sujet de ce code :

  • Ligne 4 : vous devez choisir la taille de l’image à insérer dans le flux RSS. Dans mon cas, j’ai choisi la taille par défaut nommée full qui correspond en fait à l’image originale. Vous devez choisir soit une taille par défaut de WordPress que vous pouvez ensuite gérer dans les réglages de médias (« Réglages » dans la barre latérale, puis « Médias »), soit utiliser l’une des tailles personnalisées définies par votre thème.
  • Ligne 10 : sur mon blog, je ne propose qu’un flux RSS avec les articles complets. Si vous souhaitez limiter le flux aux extraits seulement, il faudra utiliser cette ligne à la place : add_filter('the_excerpt_rss', 'rss_post_thumbnail');
  • L’intégration est très simple dans mon cas : je place l’image au-dessus du contenu, dans une balise p, en pleine taille. Vous pouvez aussi n’afficher qu’une miniature placée en haut à droite ou à gauche du texte, mais il faudra alors changer le code pour placer l’image dans une div spécifique.

rss