Code

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

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

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

Trier les articles selon une taxonomie

Pour trier des listes d’articles, WordPress propose plusieurs paramètres de base. Par défaut, les articles affichés sur la page d’accueil, comme dans les pages d’archives sont triés par date de publication. On peut facilement les trier par nom, ou encore par un custom field, ces champs d’information que l’on peut associer à un article. Mais si, comme sur mon blog personnel, on veut trier selon une date enregistrée en taxonomie personnalisée, ce n’est pas possible par défaut.

C’est un choix assumé par les concepteurs de WordPress qui considèrent que les taxonomies ne sont pas conçues pour enregistrer une information numérique, mais uniquement du texte. Un choix respectable, mais qui ne convient pas à mon cas de figure. Si je veux associer un article à une date, en l’occurrence une date de sortie pour un film, ou de publication pour une œuvre publiée, et obtenir des pages d’archive comme celle-ci, je n’ai pas le choix, je dois utiliser une taxonomie. Cette information étant particulièrement utile pour trier des articles, par exemple pour trier les films d’un réalisateur par l’ordre de sortie, je devais une solution pour le faire en fonction de cette taxonomie.

J’ai cherché une solution pendant longtemps et ma solution de replis a été jusque-là de dupliquer la taxonomie dans un custom field. Outre que c’est une solution contraignante quand on a plus de 850 articles, ce n’est pas très logique de dupliquer ainsi une information. Lors de ma dernière recherche sur le sujet, j’ai toutefois trouvé le code qui permet de trier selon n’importe quelle taxonomie. La solution provient du blog JR Nielsen et elle est très simple à mettre en place.

Copiez/collez ce code et placez-le dans le fichier functions.php de votre thème. Il est prévu pour fonctionner dans tous les cas et il n’y a qu’une seule chose à changer, ligne 6 : remplacez ce qui se trouve entre parenthèses par les identifiants de vos propres taxonomies. Dans mon cas, cela donne : $taxonomies = array('annee');

//allows queries to be sorted by taxonomy term name
add_filter('posts_clauses', 'posts_clauses_with_tax', 10, 2);
function posts_clauses_with_tax( $clauses, $wp_query ) {
global $wpdb;
//array of sortable taxonomies
$taxonomies = array('example-taxonomy', 'other-taxonomy');
if (isset($wp_query->query['orderby']) && in_array($wp_query->query['orderby'], $taxonomies)) {
$clauses['join'] .= "
LEFT OUTER JOIN {$wpdb->term_relationships} AS rel2 ON {$wpdb->posts}.ID = rel2.object_id
LEFT OUTER JOIN {$wpdb->term_taxonomy} AS tax2 ON rel2.term_taxonomy_id = tax2.term_taxonomy_id
LEFT OUTER JOIN {$wpdb->terms} USING (term_id)
";
$clauses['where'] .= " AND (taxonomy = '{$wp_query->query['orderby']}' OR taxonomy IS NULL)";
$clauses['groupby'] = "rel2.object_id";
$clauses['orderby'] = "GROUP_CONCAT({$wpdb->terms}.name ORDER BY name ASC) ";
$clauses['orderby'] .= ( 'ASC' == strtoupper( $wp_query->get('order') ) ) ? 'ASC' : 'DESC';
}
return $clauses;
}

Vous pouvez ensuite directement utiliser la taxonomie comme critère de tri, n’importe où dans le thème. Par exemple pour lister tous les articles en les triant selon la taxonomie « Année », j’utilise :

query_posts($query_string . '&posts_per_page=-1&orderby=annee&order=ASC');

Il suffit d’ajouter une autre taxonomie, ligne 6 du code précédent pour pouvoir l’utiliser en guise de tri ailleurs. C’est simple et cela fonctionne, même s’il faut pour cela réaliser une jointure en SQL. En théorie, ce type de solution n’est pas très bonne pour les performances, mais je n’ai pas noté de différence avec la méthode par défaut de WordPress et le tri sur un custom field.

Une recherche instantanée sur WordPress

Dans ma quête d’optimisation de mon blog personnel qui tourne sur WordPress, quête qui alimente régulièrement ce blog technique, la recherche interne est un problème particulièrement complexe. Le blog compte actuellement environ 820 articles pour un total d’un million de mots. Ajoutons à cela les mots-clés et la taxonomie, les commentaires éventuellement et j’atteins vite les limites de mon hébergement mutualisé. D’autant que, pour diverses raisons qui feront peut-être l’objet d’un article séparé, j’ai choisi de remplacer la recherche par défaut par celle fournie par Relevanssi qui indexe plus, mais est plus lente.

recherche-wordpress Lire la suite

Préparer son blog pour les cartes Twitter

Twitter limite ses messages à 140 caractères, tout compris. Si vous voulez évoquer l’un de vos articles sur le réseau social, le lien vers l’article en question exploite déjà une vingtaine de caractères. Pour décrire le sujet ou vanter ses mérites, il ne vous reste dès lors qu’une vingtaine de caractères au mieux. C’est souvent trop peu et on est obligé de n’associer que le titre de l’article au lien original, ce qui n’est pas toujours très vendeur.

Il existe pourtant une meilleure solution. À condition de configurer correctement son blog, on peut donner à Twitter quelques informations supplémentaires pour chaque lien et les afficher en-dessous du tweet. Cette fonction, nommée « Twitter Cards » par le réseau social, est assez simple à mettre en place et elle vous permettra d’obtenir une meilleure visibilité. Sur le site et dans les logiciels officiels, on pourra obtenir quelque chose comme ça :

Une carte Twitter en action : tous les liens du blog À voir et à manger auront droit à cet aperçu avec une image et un résumé, ce qui offre plus de place dans le tweet pour présenter l'article.

Une carte Twitter en action : tous les liens du blog À voir et à manger auront droit à cet aperçu avec une image et un résumé, ce qui offre plus de place dans le tweet pour présenter l’article.

Lire la suite