WordPress Custom Post Type est l’outil qui transforme un simple blog en véritable base de données sur mesure. Au lieu d’empiler des articles et des pages pour tout gérer, tu peux créer des contenus spécifiques pour tes produits, projets, avis clients, biens immobiliers, évènements, recettes, peu importe.
Chaque type de contenu possède son propre formulaire, ses propres champs, sa propre URL, et sa propre logique d’organisation. Résultat : un back-office clair, un front plus cohérent, et un SEO bien mieux structuré que si tout était mélangé dans “Articles”.
Derrière ce mécanisme, la base reste simple : tous les contenus sont stockés dans la table posts, mais le champ post_type permet de distinguer un article d’une page, d’une pièce jointe… ou d’un Custom Post Type. À cela s’ajoutent les taxonomies pour trier, les templates de thème pour gérer l’affichage, et éventuellement des champs personnalisés pour la vraie personnalisation.
Ce trio donne une architecture solide, bien plus robuste que des catégories bricolées. Sur un projet un peu sérieux, ignorer ces outils finit souvent en usines à gaz difficiles à maintenir.
Ce mode d’emploi pose les bases, mais va aussi dans le dur : choix entre plugin (comme Custom Post Type UI) et code PHP, paramètres à ne surtout pas rater, liens avec la template hierarchy, inclusion dans la recherche, réglage des permaliens pour éviter les 404, et retouches du back-office pour que tes clients ne se perdent pas.
Pour te guider, un fil rouge : un site fictif d’agence immobilière qui doit gérer ses “Propriétés” comme un type de contenu dédié, bien rangé, bien affiché. Si tu as déjà maudit ton WordPress bourré de catégories fourre-tout, ce guide va te parler.
- Les Custom Post Types étendent WordPress bien au-delà des simples articles et pages en définissant des structures de données spécialisées.
- La création peut se faire via un plugin comme Custom Post Type UI ou directement par le code avec register_post_type et register_taxonomy.
- L’affichage repose sur la template hierarchy (archive-CPT.php, single-CPT.php, taxonomy-XXX.php) et des requêtes ciblées WP_Query.
- L’organisation passe par des taxonomies dédiées, des colonnes d’admin, des messages de validation adaptés et des permaliens propres.
- Le SEO et l’expérience éditeur profitent énormément d’une architecture bien pensée plutôt que de tout entasser en “Articles”.
WordPress Custom Post Type : comprendre enfin à quoi ça sert vraiment
Un Custom Post Type, ce n’est pas une option gadget planquée dans un menu obscur de WordPress. C’est la brique qui permet de dire : “Ce contenu n’est ni un article de blog, ni une page statique, c’est autre chose.” Depuis la version 3, le cœur de WordPress autorise nativement cette création de types personnalisés, stockés dans la même table que le reste, mais identifiés par un post_type spécifique. Concrètement, ton site ne se limite plus à “post” et “page” : il peut avoir “film”, “propriete”, “cours-en-ligne”, “recette”, etc.
Pourquoi ça change la vie ? Parce que tu arrêtes de détourner les catégories et les étiquettes pour simuler des structures qui n’existent pas. Un site d’agence immobilière n’a pas besoin de classer ses annonces dans “Catégorie : Vente” et “Catégorie : Location” en mode bricolage. Il a besoin d’un type “Propriété” avec des champs dédiés (surface, prix, ville, type de bien) et éventuellement une taxonomie “Type de bien” pour distinguer appartement, maison, loft. Les contenus spécifiques permettent exactement ça : modéliser le métier plutôt que forcer le métier à rentrer dans le moule “article”.
Dans la base de données, tout se passe dans la table posts. Tu y retrouves les types natifs : post, page, attachment (les médias), revision. Quand tu déclares un nouveau type, WordPress ajoute des lignes avec ton nouveau slug dans le champ post_type. Chaque enregistrement possède un ID unique, ce qui évite les jongleries côté requêtes. Les plugins et les thèmes en profitent déjà énormément : WooCommerce enregistre par exemple ses produits dans un type product, les builders créent parfois leurs propres types pour gérer des modèles, etc.
Autour des Custom Post Types gravitent les taxonomies. Là, on parle d’organisation pure. Les catégories et étiquettes que tu connais sont des taxonomies natives, respectivement hiérarchique (avec parent/enfant) et non hiérarchique. La bonne nouvelle, c’est que tu peux aussi les personnaliser : une taxonomie “Genre” pour des films, “Technologie” pour des études de cas, “Catégorie de service” pour une page de prestations. L’important, c’est que ces taxonomies soient attachées au bon type de contenu : pas besoin que “Type de bien” apparaisse sur les articles de blog.
Beaucoup de sites qui vieillissent mal ont loupé ce virage. On voit des blogs où tout est un article, et où les catégories servent à tout : projets, témoignages, réalisations, communiqués de presse. Ça fonctionne tant que le volume reste faible, puis la navigation devient illisible, les filtres explosent et le SEO se dilue. Une personnalisation propre via des Custom Post Types évite ce scénario. À partir du moment où ton site commence à ressembler à un catalogue, une base de connaissances ou un portfolio sérieux, rester sur le duo “articles/pages” devient un pari risqué.
D’ailleurs, ce n’est pas qu’un sujet technique : c’est un choix d’architecture. Sur des projets où l’hébergement est déjà optimisé (par exemple via une stack Docker, Nginx et MariaDB comme détaillé dans cet article sur un WordPress sous Docker), ne pas structurer les contenus avec les bons types et taxonomies, c’est comme poser un moteur de course sur un châssis bancal. Le site peut être rapide mais reste pénible à utiliser, autant côté éditeur que côté visiteur.
Pour poser le décor une bonne fois pour toutes : un Custom Post Type sert à représenter une “famille” de contenu bien identifiée, avec sa logique métier, ses URL, son modèle d’affichage et ses options d’organisation. Si tu te surprends régulièrement à dire “ce ne sont pas vraiment des articles”, tu tiens déjà un excellent candidat à transformer en type personnalisé.
Créer un Custom Post Type : plugin ou code, comment faire le bon choix
Deux écoles cohabitent pour la création de Custom Post Types sous WordPress. La première mise sur un plugin dédié comme Custom Post Type UI, qui expose tous les paramètres dans une interface graphique. La seconde passe directement par le fichier functions.php (ou un fichier séparé dans le thème) en utilisant la fonction register_post_type. Les deux approches s’appuient sur le même moteur WordPress, seule la façon de déclarer les choses change.
Le plugin brille pour un objectif très clair : permettre à quelqu’un qui n’est pas à l’aise avec le code d’ajouter un type de contenu en quelques minutes. Une fois l’extension installée, un menu apparaît dans le back-office avec la possibilité d’ajouter un nouveau type, de définir son slug, ses libellés, ses réglages d’archives, son icône de menu, les supports disponibles (titre, éditeur, image mise en avant, extrait, attributs de page, etc.). C’est aussi là que tu peux rattacher des taxonomies existantes ou en créer de nouvelles, le tout sans toucher une ligne de PHP.
Dans le cas de notre agence immobilière fictive, un type “Propriétés” peut être créé en renseignant un slug “property”, un pluriel “Properties” et un singulier “Property”. On coche les supports nécessaires (titre, éditeur, image, champs personnalisés) et on active Has Archive pour obtenir une page de listing automatique. On place le type dans le menu d’admin derrière les Articles (position 6 par exemple) et on choisit une icône comme dashicons-admin-home pour être explicite. Trois minutes plus tard, un nouvel item “Properties” apparaît dans le back-office avec son bouton “Ajouter”.
Le code, lui, donne un contrôle plus fin et s’intègre mieux à un thème proprement organisé. L’idée de base consiste à créer une fonction qui appelle register_post_type avec un tableau de labels et un tableau d’arguments, puis à la brancher sur le hook init. Les options sont nombreuses : public ou non, inclusion dans les menus, gestion des archives, URL personnalisées via rewrite, capacités, support de l’éditeur classique ou de Gutenberg, intégration dans l’API REST, etc. Une fois qu’on a compris la logique, on peut aller beaucoup plus loin que ce que propose un simple formulaire d’extension.
Pour ne pas repartir de zéro, des générateurs en ligne comme GenerateWP produisent une base de code à partir de quelques champs. Ce n’est pas magique, mais ça évite les fautes de frappe dans les arguments les plus verbeux. Ensuite, on adapte : on ajuste la priorité du hook, on nettoie les labels inutiles, on adapte le slug pour le SEO et, surtout, on branche la taxonomie personnalisée voulue via l’argument taxonomies. Le type “property” peut ainsi être directement relié à “property_type” au moment de sa création.
La question qui revient sans arrêt : vaut-il mieux placer ce code dans le thème ou dans un plugin maison ? Certains défendent la séparation stricte entre les données et la présentation, et donc un plugin. D’autres préfèrent tout regrouper dans le thème, au motif qu’on ne change pas de thème tous les quatre matins et que l’affichage et la structure sont intiment liés. À mes yeux, pour un site qui ne prévoit pas de rotation régulière de thème, placer les Custom Post Types dans le thème reste cohérent : les données restent en base même si le code saute, mais l’affichage est garanti tant que le thème est là.
Pour décider vite : si tu construis un écosystème réutilisable sur plusieurs sites (par exemple une suite d’outils immobiliers ou un plugin de portfolio générique), oriente-toi vers un plugin maison. Si tu réalises un site sur mesure pour un client avec un design très spécifique, intégrer la création des types de contenu dans le thème ou un sous-fichier du thème simplifie l’ensemble. Dans tous les cas, évite à tout prix de bricoler ce code via l’éditeur de fichiers en ligne de WordPress : un oubli de virgule et tout le site est hors ligne.
Paramètres clés à ne pas rater lors de la déclaration du type
Le vrai piège avec les Custom Post Types, ce ne sont pas les concepts, ce sont les dizaines de petites cases à cocher qui ont un impact direct sur l’affichage et l’organisation. Quelques points méritent de s’arrêter deux minutes dessus. D’abord, has_archive : quand il est à true, WordPress génère automatiquement une page d’archive pour ton type, accessible via /slug/. Sans ça, tu devras gérer toi-même le listing via une page statique et une requête personnalisée. Ensuite, hierarchical : à true, ton type se comporte comme les pages (avec parent/enfant), à false comme les articles.
Viennent ensuite la position dans le menu (menu_position) et l’icône (menu_icon). Ce sont des détails, mais pour un client ou un rédacteur, un menu d’admin rangé change beaucoup de choses. Un type “Film” placé juste après les Articles, avec une icône claire, sera trouvé en quelques secondes. À l’inverse, un type “Projet” perdu sous un sous-menu obscur va rester inutilisé. Côté supports, coche uniquement ce qui a du sens : pas besoin de commentaires sur un type “Slide de homepage”, par exemple.
Enfin, pense à la compatibilité avec ce que tu utilises déjà. Certains frameworks ou thèmes (Genesis, par exemple) ajoutent des supports spécifiques comme genesis-layouts ou genesis-cpt-archives-settings pour affiner encore le comportement des archives. Dans ce cas, une simple case à cocher peut t’éviter des surcharges de template inutiles. Une fois ces options maîtrisées, créer un type de contenu devient un geste simple, presque routinier, plutôt qu’un moment de panique devant une page remplie de champs incompréhensibles.
Taxonomies personnalisées et organisation avancée des contenus spécifiques
Créer un Custom Post Type sans penser à ses taxonomies, c’est un peu comme lancer une boutique e-commerce où tout serait rangé dans un seul rayon. Tu peux techniquement tout ajouter, mais retrouver quelque chose devient vite pénible. Les taxonomies servent à structurer, filtrer, et renforcer le sens de tes contenus spécifiques. Elles sont au cœur de l’organisation d’un gros site WordPress dès que tu dépasses quelques dizaines d’entrées.
La première décision à prendre concerne le caractère hiérarchique ou non. Une taxonomie hiérarchique se comporte comme une catégorie : tu peux créer des termes parents et enfants, naviguer dans un arbre, proposer des filtres plus fins. Une taxonomie non hiérarchique ressemble davantage à des étiquettes : liste plate, sans parenté. Pour l’agence immobilière, “Type de bien” en hiérarchique (Maison > Maison de ville > Maison de campagne) a du sens. Une taxonomie “Options” (terrasse, balcon, parking) en non hiérarchique peut venir en complément.
Les mêmes questions se posent que pour les types : utiliser un plugin comme Custom Post Type UI, ou passer par la fonction register_taxonomy. Le plugin permet de tout faire via une interface familiarisée : nom, slug, type de comportement, affichage dans les colonnes d’admin, présence dans l’édition rapide, réécriture d’URL. Le code, lui, t’offre la possibilité de régler chaque argument, de contrôler la visibilité publique, l’inclusion dans l’API REST, et de gérer des cas plus avancés comme des taxonomies partagées entre plusieurs types de contenu.
Pour clarifier tout ça, un petit comparatif rapide entre les deux grands axes d’organisation sous WordPress peut aider.
| Élément | Rôle principal | Exemples concrets | Impact sur l’interface |
|---|---|---|---|
| Custom Post Type | Définir une famille de contenus avec un formulaire, des URL et des templates dédiés | Propriétés, Films, Témoignages, Recettes, Cours | Nouveau menu d’admin, nouveaux écrans d’édition, archives spécifiques |
| Taxonomie personnalisée | Organiser et filtrer les contenus d’un ou plusieurs types | Type de bien, Genre de film, Catégorie de service | Boîte de sélection sur l’écran d’édition, colonnes de tri en liste |
Sur l’interface d’administration, plusieurs options font une vraie différence au quotidien. “Show Admin Column” ajoute une colonne dédiée à la taxonomie dans la liste des contenus : un simple clic permet de filtrer toutes les “Villas” ou tous les “Films d’animation”. “Show in quick/bulk edit panel” permet de modifier la taxonomie depuis l’édition rapide, très utile pour reclassement massif. Sur un site qui tourne depuis des années, ces deux cases sauvent un temps fou quand tu décides de revoir l’arborescence.
À noter aussi : une taxonomie peut être rattachée à plusieurs types de contenu. Tu peux très bien avoir une taxonomie “Technologie” utilisée à la fois sur un type “Étude de cas” et un type “Article de blog”. Ce genre de partage se décide tôt, idéalement au moment du cadrage. Quand ce n’est pas anticipé, on se retrouve souvent à dupliquer des taxonomies presque identiques avec des termes divergents, ce qui complique les filtres côté front et brouille les signaux pour le SEO.
Côté URL, la réécriture (rewrite) permet de choisir le segment utilisé dans les permaliens. Une taxonomie “type_de_bien” peut générer des URL comme /type/maison/ ou /bien/maison/ selon ce que tu choisis. L’important, c’est d’aligner ces décisions avec ta stratégie de référencement. Sur un site où le SEO pèse vraiment (par exemple pour un e‑commerce sérieux, sujet qu’on retrouve aussi dans cet article sur le coût d’un site e‑commerce), bien nommer les slugs de taxonomies et de types devient un vrai levier.
Une fois tes taxonomies en place, la navigation front peut devenir très agréable : archives par type de bien, filtres combinés, pages dédiées à une “collection” précise… L’erreur fréquente consiste à faire l’inverse : commencer par bricoler des pages de listing à la main, puis essayer de raccrocher des taxonomies dessus. Dans la pratique, tu t’épargnes bien des headaches en partant de ton modèle de données (types + taxonomies), puis seulement ensuite de ton design de pages.
Affichage des Custom Post Types : templates, WP_Query et page d’accueil
Une fois les types et taxonomies déclarés, la question qui arrive vite est simple : comment gérer l’affichage côté thème ? WordPress propose une “template hierarchy” très précise qui détermine quel fichier PHP est utilisé pour telle URL. Les Custom Post Types s’insèrent dedans comme n’importe quel autre contenu, avec quelques fichiers clés à connaître pour éviter de tout entasser dans single.php ou archive.php.
Pour un type “property”, WordPress va rechercher en priorité un fichier single-property.php pour l’affichage d’une fiche unique, puis retomber sur single.php si ce fichier n’existe pas. Pour la liste des propriétés, il va chercher archive-property.php, puis archive.php. Côté taxonomie, une archive “type_de_bien” se sert dans taxonomy-type_de_bien.php en priorité, puis dans taxonomy.php. Savoir cela te permet de créer des expériences très différentes pour chaque ensemble de contenu, sans casser les autres pages.
Sur l’agence immobilière, ça donne quelque chose de très concret. La page d’une propriété peut afficher un carrousel de photos, un bloc de caractéristiques (surface, pièces, localisation), une carte, un formulaire de contact dédié. L’archive listant toutes les propriétés peut se contenter d’un grid avec photo, titre, prix, ville, et un bouton “Voir le détail”. Le tout sans toucher à l’affichage des articles de blog, qui suivent leur propre logique. Ce découplage complet est difficile à reproduire proprement sans passer par les Custom Post Types.
Au-delà de ces templates standards, les requêtes personnalisées via WP_Query permettent de récupérer exactement ce dont tu as besoin, où tu en as besoin. Tu veux afficher sur ta page d’accueil les trois dernières propriétés en vitrine ? Une boucle avec un argument post_type => ‘property’ et posts_per_page => 3 résout le problème. Tu veux une page “Dernières villas” ? Même combat, en ajoutant un filtre sur la taxonomie type_de_bien. WP_Query est la brique qui relie ton modèle de données à ton design.
Par défaut, la page d’accueil WordPress ne liste que les articles. Pour y intégrer un Custom Post Type, il faut intervenir sur la requête principale via le hook pre_get_posts. L’idée est simple : si la requête est celle de la home et qu’on n’est pas en admin, on remplace le paramètre post_type par un tableau mélangeant ‘post’ et ‘property’. La même astuce fonctionne pour inclure les propriétés dans les résultats de recherche : sur une requête is_search, on ajuste là aussi la liste des post_type à inclure.
Un détail technique mais récurrent : l’erreur 404 après la création d’un type ou d’une taxonomie. Beaucoup de développeurs débutants se font surprendre. Ils déclarent un type, vont directement sur /property/, et tombent sur une page introuvable. La raison est triviale : la configuration des permaliens n’a pas été régénérée. La solution tient en une action : aller dans Réglages > Permaliens, et cliquer sur Enregistrer sans rien changer. WordPress vide alors ses règles de réécriture en mémoire et prend en compte les nouveaux types.
Une fois qu’on a pris le pli, ces mécaniques deviennent presque naturelles. On crée un type, une taxonomie, on adapte ou crée les bons fichiers de template, on branche éventuellement une requête WP_Query sur une page statique, et on pense à rafraîchir les permaliens. Ce schéma se répète pour un portfolio de photographe, une liste d’évènements, une base documentaire, etc. C’est comme ça qu’un site WordPress reste lisible même quand il grossit, là où un simple empilement de pages finit par s’effondrer sous son propre poids.
Inclure intelligemment les contenus spécifiques dans la navigation globale
L’étape suivante consiste à réfléchir à la façon dont tes contenus spécifiques s’intègrent à la navigation et aux menus WordPress. Un type “Propriétés” mérite presque toujours son propre lien dans le menu principal, généralement vers son archive. C’est là que la case has_archive prend tout son sens : elle transforme ton type en “section” complète du site, que tu peux lier proprement dans Apparence > Menus.
Pour des types plus discrets, comme des “Témoignages” ou des “Logos de partenaires”, tu ne souhaites pas forcément d’archive publique. Dans ce cas, il est possible de garder has_archive à false et de ne créer que des blocs d’affichage ciblés via WP_Query dans quelques templates ou dans le builder de ton choix. Le type reste alors un outil d’organisation back-office, sans exposer une section dédiée sur le front.
Sur des sites plus complexes, la combinaison des Custom Post Types, des taxonomies et des menus conditionnels permet de construire de véritables “sous-sites” dans WordPress. Un univers “Blog”, un univers “Produits”, un univers “Ressources”, chacun avec sa propre logique. Pour un photographe qui hésite entre plusieurs CMS, ces possibilités d’architecture fine sont d’ailleurs un argument fort en faveur de WordPress, comme développé dans le guide sur la création d’un site photographe sous WordPress. Les Custom Post Types sont souvent le point de bascule entre un blog évolué et une application de contenu aboutie.
Personnaliser l’expérience éditeur : labels, messages et back-office sur mesure
Un site WordPress agréable à utiliser ne dépend pas uniquement de son front : le back-office compte autant. Quand un client tombe sur un menu “Propriétés”, que le bouton “Ajouter une propriété” est clair, que les colonnes d’admin affichent les bonnes informations, la prise en main devient fluide. Les Custom Post Type laissent justement la porte ouverte à une vraie personnalisation de ce côté-là, souvent négligée alors qu’elle évite beaucoup de malentendus.
Premier levier : les libellés. Au moment de déclarer un type, WordPress t’invite à remplir une série de labels : plural, singular, add_new_item, edit_item, view_item, search_items, etc. Ces textes alimentent l’interface : “Tous les films”, “Ajouter un film”, “Rechercher des films”. Les plugins comme Custom Post Type UI offrent une interface complète pour les adapter à ta langue et à ton vocabulaire métier. Ne laisse pas les valeurs génériques en anglais si ton client ne lit pas cette langue : la compréhension en pâtit.
Deuxième levier, moins connu : les messages de mise à jour. À chaque enregistrement ou publication, WordPress affiche une notice de type “Article mis à jour” ou “Page publiée”. Via le filtre post_updated_messages, tu peux surcharger ces messages pour un type de contenu donné. Par exemple, pour un type “testimonial”, il devient possible d’afficher “Témoignage mis à jour” ou “Témoignage publié, voir la page” avec un lien direct. Le code est un peu verbeux mais la logique est simple : on vérifie le post_type, on récupère l’URL du contenu, et on remplace les entrées du tableau $messages[‘testimonial’].
Ce genre de détail donne un sentiment de cohérence. Un rédacteur qui travaille sur des “Fiches produit” ne devrait jamais voir un message “Article mis à jour” : ça donne l’impression d’un bricolage, même si techniquement ça fonctionne. Les interfaces bien pensées parlent toujours le langage du métier, pas celui de la base de données.
Ensuite viennent les colonnes de liste. Selon le type, certaines informations méritent d’apparaître immédiatement : prix pour un produit, ville pour une propriété, année pour un film. En mixant une colonne de taxonomie (via Show Admin Column) et éventuellement une colonne personnalisée via les hooks manage_edit-{$post_type}_columns et manage_{$post_type}_posts_custom_column, tu construis un tableau de bord lisible. On repère d’un coup d’œil les contenus incomplets, les statuts, les termes manquants.
Pour l’agence immobilière, la liste des Propriétés pourrait afficher : Titre, Ville (taxonomie), Type de bien (taxonomie), Prix (champ personnalisé), Statut (Publié/Brouillon), Date. Un tri rapide par prix ou par ville devient alors un outil de travail quotidien, pas seulement une vue technique. Là encore, un plugin comme Admin Columns peut simplifier énormément ce travail si tu n’as pas envie de plonger dans les hooks.
Enfin, il y a la question plus globale du design du back-office : simplifier les metabox inutiles, masquer certains blocs côté éditeur, adapter l’ordre des éléments. Même si ce n’est pas strictement lié aux Custom Post Types, c’est souvent à ce moment-là qu’on s’y intéresse. Une fois que ton site manipule plusieurs familles de contenus, tu n’as plus envie de laisser les menus d’extensions inutilisées ou des metabox vides détourner l’attention. La cohérence de ce “musée privé” de tes données repose sur des petites touches de UX dans l’admin autant que sur l’architecture en base.
Exporter, partager ou transformer ton architecture de contenus
Dernier point très pratique : la portabilité. Quand tu as passé du temps à peaufiner plusieurs Custom Post Type et leurs taxonomies, tu n’as pas envie de tout refaire sur le site suivant. Les bons plugins prévoient un onglet Import/Export qui génère non seulement une configuration réutilisable, mais parfois aussi le code PHP correspondant. Custom Post Type UI, par exemple, permet de récupérer le code complet de declaration du type et de la taxonomie pour l’intégrer ensuite dans ton propre plugin ou ton thème maison.
C’est d’ailleurs une très bonne façon de faire la transition entre une phase “je teste des choses rapidement via une interface” et une phase “je stabilise mon architecture dans le code”. Tu peux commencer par jouer avec l’extension, valider avec ton client que la structure lui convient, puis récupérer le code généré, le nettoyer, l’optimiser, et le poser dans un fichier inc/theme-content.php. L’extension peut alors être désactivée sans casser la base de données : les contenus restent, le code prend le relais.
Vue de plus haut, cette démarche rappelle ce qui se passe souvent quand on passe d’un constructeur de pages à des templates plus légers, ou d’un site clé en main à une architecture Docker plus maîtrisée. On commence par du rapide, puis on consolide. L’important est de garder en tête l’objectif : une architecture de contenus spécifiques lisible, maintenable, qui ne rend pas fou le prochain développeur qui mettra les mains dedans.
Faut-il toujours utiliser un Custom Post Type plutôt qu’une simple catégorie ?
Non. Si ton contenu reste proche d’un article de blog classique et que tu n’as besoin ni de formulaire d’édition spécifique, ni d’URL dédiées, ni de templates différents, rester sur le type natif post avec des catégories suffit. Un Custom Post Type devient pertinent dès que tu manipules une famille de contenus qui a sa propre logique métier (produits, propriétés, cours, recettes, etc.).
Plugin ou code pour créer un Custom Post Type sur WordPress ?
Un plugin comme Custom Post Type UI convient bien pour démarrer vite, surtout si tu n’es pas à l’aise avec PHP ou si ton client doit pouvoir ajuster l’architecture lui-même. Le code (via register_post_type et register_taxonomy) prend le dessus dès que tu veux versionner tes réglages, les partager entre plusieurs environnements et garder un contrôle fin sur tous les arguments. Sur un projet long terme, le code reste généralement plus fiable.
Comment afficher un Custom Post Type sur la page d’accueil WordPress ?
Il faut modifier la requête principale de la page d’accueil via le hook pre_get_posts. Concrètement, on ajoute une fonction qui vérifie si la requête est celle de la home, qu’on n’est pas en admin, puis on remplace le paramètre post_type par un tableau incluant à la fois post et le slug de ton Custom Post Type. Cette approche garde le comportement standard de WordPress tout en élargissant la liste des contenus affichés.
Pourquoi mes URL de Custom Post Type renvoient une erreur 404 ?
Dans la majorité des cas, les règles de permaliens n’ont pas été régénérées après la création du type ou de la taxonomie. Il suffit d’aller dans Réglages > Permaliens et de cliquer sur Enregistrer sans modifier quoi que ce soit. WordPress vide alors ses règles en cache et prend en compte la nouvelle architecture, ce qui règle la plupart des 404 liées aux Custom Post Types.
Un changement de thème supprime-t-il mes contenus personnalisés ?
Les contenus restent en base de données même si le code qui déclare le Custom Post Type disparaît. En revanche, tant que le type n’est plus déclaré, WordPress ne saura plus comment les afficher ni les lister dans l’admin. C’est pour cette raison que certains préfèrent déclarer les types de contenu dans un plugin maison plutôt que dans le thème, surtout s’ils prévoient de changer de thème à moyen terme.
