Astuce : nettoyer son blog après Gutenberg

Pendant son développement, j’ai testé Gutenberg, le nouvel éditeur de texte par défaut de WordPress depuis la version 5.0. J’ai écrit plusieurs articles sur mon blog personnel en utilisant une bêta à l’été 2017, mais j’ai vite arrêté, parce qu’il restait pas mal de bugs à l’époque, et parce que je n’aimais pas ce mode de fonctionnement en blocs.

Je préfère écrire en Markdown, c’est une question de goût et j’aime mieux travailler dans un éditeur de texte en local, puis copier/coller l’article dans l’éditeur HTML de WordPress. Bref, j’ai désactivé Gutenberg après ces essais et installé l’extension Classic Editor pour conserver l’ancien éditeur et ne pas utiliser ce nouveau venu.

Le problème, c’est que j’avais encore une vingtaine d’articles rédigés avec Gutenberg. Pendant le développement du module, ils ont changé le fonctionnement des blocs, si bien que le style dépendait du thème et non plus du module. Comme j’avais abandonné cet éditeur, je n’avais pas fait le travail nécessaire pour adapter mon thème. Résultat, la mise en page était cassée à cause du marquage des blocs de Gutenberg, en particulier le contenu était affiché sur 100 % de la largeur.

Lire la suite « Astuce : nettoyer son blog après Gutenberg »

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 »

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 db 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 !