Champs personnalisés dans WordPress : attention à la performance

Marie-Aude

J'ai fait de la compta, de la finance, du juridique, j'ai été chef de projet SAP, j'ai fait de la photo, des voyages. Depuis 2007, je fais avec amour des sites webs pour les utilisateurs, qui se référencent bien et je vous aide à acquérir du trafic pertinent.

Vous aimerez aussi...

43 réponses

  1. Stéphane dit :

    yop !!
    Oui, c’est tout bon, mais là, y’a la moitié des blogueurs qui s’est pendue, et l’autre qui fait la queue à la pharmacie pour l’aspirine. Mais c’est logique…

    Fondamentalement, c’est comme demander à chaque automobiliste de connaitre le moteur de son véhicule, tu vois le truc.

    Alors, oui, sur le fond, tu as raison. Mais le succès de WordPress, c’est aussi cette possibilité donnée à tout le monde de pouvoir réinventer sa roue et d’avancer. C’est ça la démocratie ((:

    • Marie-Aude dit :

      J’avais pourtant essayé de faire simple :)

      Dans ce cas précis, la solution WordPress est nettement plus simple et efficace que l’autre. Parce que paramétrer un query_post pour faire de la recherche sur des metas, c’est pas “biblique”

  2. Greg dit :

    “Oui, c’est tout bon, mais là, y’a la moitié des blogueurs qui s’est pendue, et l’autre qui fait la queue à la pharmacie pour l’aspirine.”
    Ou alors tu te plantes de cible. Je sais que les blogueurs c’est ton monde, mais il n’y a pas que ça, il y a des devs aussi.

    “Fondamentalement, c’est comme demander à chaque automobiliste de connaitre le moteur de son véhicule, tu vois le truc.”
    Encore, mauvaise cible, car c’est pas le “blogueur” qui va aller mettre les doigts dans le code ou la base de données.
    “Fondamentalement, c’est comme demander à chaque mécano de connaitre le moteur de son véhicule, tu vois le truc.”
    Ha oui, de suite ça colle beaucoup mieux là :)

    Merci Marie-Aude pour l’article :)

  3. Stéphane dit :

    @M.A : Na, c’est simple (:
    Enfin, si tu es habitué à trifouiller.
    Après, faut aussi que celui qui débute s’y mette, donc, c’est le type de billet qui peut (doit ?) être lu pour avancer et comprendre la mécanique.

    Au passage, je vais allez voir ce plugin, je ne connaissais pas, et comme je suis en en phase over dose de code, très bien !

    @ Greg : Oui, donc ? Y’a aussi des devs. Bien. Merci pour l’info ((:

  4. Très bonne réflexion, tout le monde cherche la perf, mais personne ne veut faire l’effort de la trouver.
    Il est clair qu’utiliser les meta pour trier/filtrer/rechercher c’est pas le top, les custom taxo remplissent bien ce travail et les APIs d’appels ne manquent pas, pour les queries il y a la tax_query qui est la (oui il y a meta_query mais comme expliqué dans le post … erf)

    @ Stef : Ce n’est pas un article pour un blogueur final, on parle d’utiliser des champs perso pour faire des requêtes donc ça touche forcément les devs. La, un simple luser NE PEUT PAS faire ça, ça implique la création d’un plugin/astuce/thème (ou retouche) donc forcément PAS un blogueur (oui on peut aussi faire du WordPress PAS pour les blogueurs finaux) Comme dit Greg, tu te trompes de cible, mais comme a chaque post où on dit “touchez le code” tu interviens pour dire ça.

    Merci lumière de nous l’avoir éclairée ;)

  5. Stéphane dit :

    @Julio, si j’étais de mauvais de poil, je dirais que vous êtes sectaires les gars. Ça vous vient pas à l’esprit de penser qu’un blogueur peut aussi mettre les mains dedans.

    Je suis blogueur, mais il m’arrive de faire du code, de me pencher dessus. Pourtant, je ne suis pas un dev’. Faut arrêter le sectarisme de la sorte.

    Donc, je suis ne pas d’accord, ce type de billet peut s’adresser à tout le monde, du moins, tout ceux qui veulent mettre le nez dedans.

    J’ai sans doute été maladroit sur mon premier com’, mais il est vrai que quand on rentre dans le code, bah on perd du monde. Mais c’est aussi comme cela que l’on apprend.

    Vous avez bien débuter un jour, et parfois, vous êtes tombé sur des trucs qui vous sont apparus tordus, compliqués… Je ne vois pas où se trouve le problème dans mon intervention ?? oO

    Bon, bah je ne dis rien de plus. Et pour finir julio, non, je n’interviens pas sur tout les articles de code… Ça va hein (:

  6. Un blogueur qui met les mains dedans devient un dev, débutant, mais dev !
    Tu fais donc aussi tu dev, cet article est fait pour toi :)
    Donc si tu mets les mains dedans et que tu crées des meta pour ensuite filtrer/trier/rechercher, c’est mal ^^ Utiliser les taxo n’est juste pas plus compliqué, faut juste savoir que les meta c’est forcément moins bon à cause des index ;)
    Ok, pas tous les posts, mais “la pensée WP” tu es la, “plugin or not plugin” tu as le même discours, chacun prêche pour sa paroisse surement.
    Allez bisou ^^

  7. Keryan dit :

    Je trouve que c’est un très bon article pour montrer les yeux aux débutants et leur montrer la voie à suivre, même si elle est un peu obscure lors la première lecture :D J’aurais une question, s’il vous plaît: pourriez-vous me donner un exemple de “critère de recherche et de tri” qu’un utilisateur stockerait dans un champ personnalisé ? Merci d’avance pour la réponse … et pour ces informations détaillées.

  8. Merci beaucoup Marie-Aude pour cet article.

    Tu parles de critères de recherche. Mais considères tu que sur des boucles multiples la fonction new WP_Query meta_query sont aussi beaucoup moins performantes qu’avec tax_query?

  9. Patrick dit :

    OUlalala dès le matin la prise de tête, franchement c’est trop avancé pour moi, vous avez gagné la palme d’or de l’article le plus geekesque de l’année je crois :)
    A mon avis celui qui utilise les champs personnalisés sait déjà comment ils fonctionnent non ? parceque pour le commun des mortels, on ne sait même pas a quoi ils servent :( .

  10. @gregoire : C’est de ça qu’on parle. Que ce soi fait à la main (bouh !) avec $wpdb->query/->get_col/->get_row/->get_results ou avec une vrai meta_query, ça tape de toute façon dans cette table de meta qui ne contient pas d’indexes.

  11. Moi la seule fois où j’ai utilisé les champs personnalisés, c’est pour insérer des thumbs à mes articles en sidebar. Mais maintenant, il existe plein de plugins qui le font :) du coup je lui trouve plus beaucoup d’utilité à ce champs…

  12. @Julio
    Merci Julio. Merci pour la précision. Par contre dans le cadre d’une requête du thème c’est mis en cache contrairement à une requête avec des champs (côté front, champ de recherche ou autre). Du coup, c’est moins grave.
    J’espère car je suis un grand utilisateur d’ACF (comme tu sais :-) et ça tape que dans les metas

  13. @grégoire : taper dans les métas c’est pas grave du tout, mais faire des filtres de recherches dans des metas selon une meta value, là c’est moins bien. Mais tu peux en lire 1000 par page, ça va, pas de soucis ;)
    Tu les utilises comment toi ?

  14. @Julio
    Ouf, c’était d’ailleurs le sens de mon premier commentaire. Le distingo entre les requêtes de recherche et la construction de boucle multiples dans un template.

    De mon côté, je m’en sers surtout comme des métas pour donner au client la possibilité de monter des page d’accueil modulable par exemple (avec ACF), comme ce qu’on a tous vu (pour ceux qui écoutaient :-) durant mon dernier lightning talk

  15. @gregoire : Je m’en doutais bien, mais j’ai encore vérifié la emaine passée et tu peux faire 1000 get_post_meta() dans une page, ça reste la même perf, c’est en cache direct. Le soucis vient bien d’un get_posts (ou query_posts ou WP_Suery) qui fait une meta_query sur une meta_value, là c’est bad perf.

  16. @Julio. Super. Je ferai gaffe en tout cas.

  17. Nat dit :

    Moi qui pensait connaître WP et bien… j’ai sauté sur mon tube d’aspirine ^^ Je vais relire à tête reposée. Très bon article cela dit merci.

  18. Aleks dit :

    Ok et pour un custom field dans une custom taxonomie ? :D
    Par exemple si j’ai une custom taxo Communes:
    Region>Département>Commune et qu’en CF je mets le code postal par exemple sur Commune, c’est stocké sérialisé en base (me semble)…

    C’est pas super de requêter dessus non ? (c’est une question, si vous avez mieux…)

    On touche un peu les limites du modèle BDD de WP sur ce point je crois… (mais ceci dit coté intellectuel mis à part ça marche très bien)

    Merci pour l’article. Perso j’aimerais en voir plus de post techniques en français de ce type et pas juste de copier-coller du Codex !

  19. Marie-Aude dit :

    Bah c’est “simple” :D

    le truc à ne surtout pas faire“, c’est de dissocier le nom et le code postal, l’un en taxo, l’autre en custom field de l’article, parce que erreur de saisie, blabla

    Option 1 : vous voulez pouvoir chercher / chercher sur les deux éléments (CP et nom), là la seule solution qui soit correcte pour la perf, c’est le code postal en nicename, éventuellement avec un préfixe, et la commune en valeur. Plus, dans l’admin, une meta-box faite maison pour un affichage des valeurs de taxonomies possibles avec un select

    Option 2 : vous ne voulez chercher / sélectionner que sur l’un des deux éléments, vous le mettez en valeur, et vous passez l’autre en meta (custom field) puisqu’on peut effectivement utiliser le système des metas pour les taxonomies.

    Cela dit, comme ce n’est pas du core wordpress, pour l’instant, mais une table à rajouter, vous pouvez la définir comme vous voulez, et rien ne nous empêche de définir tous les index nécesssaires.

    C’est le principe d’un plugin comme taxonomy metadata
    https://wordpress.org/plugins/taxonomy-metadata/
    C’est aussi ce que font d’autres plugins, comme celui que j’utilise pour les séries d’articles, ou généralement les plugins qui permettent de lier des images à des termes.

    Il faut simplement être prudent en nommant ses champs : car même si la table n’existe pas ( encore ) dans le core, elle a des chances d’arriver un jour ou l’autre, il vaut donc mieux que vos champs soient définis exactement selon la logique de WordPress (usermeta et postmeta)

    En fait, il est très bien le modèle BDD ^^

    (Et merci pour le commentaire ça encourage à continuer)

  20. Remi dit :

    Très bonne réflexion, c’est vraiment bien de voir des articles qui vont dans le détails. Dans la logique globale je suis assez d’accord, par contre dans les faits on ne peut pas passer TOUT en taxo… il faut parfois utiliser des meta fields pour les recherches. J’ai fait il y a peu un plugin pour la gestion de biens immobiliers (je ne met pas le lien, mais ce qui connaissent mon travail le trouveront facilement). Et ce plugin possède exactement les contraintes évoquées dans cet article. Le moteur de recherche permet de filtrer par taxonomies: ville, CP, etat, statut, type de bien etc etc… mais comme chaque bien a plus de 40 meta fields, je suis bien obligé à un moment ou un autre d’inclure ces champs dans le système de recherche. Alors pour être précis, il faut là différencier: trier et filtrer, et le cumul des actions.

    Bref tout ça pour dire que oui il faut privilégier les taxo dans les tris, mais aussi penser à utiliser à bon escient WP_Query qui depuis peu propose une API bien plus performante au niveau des requetes sur les meta fields: https://codex.wordpress.org/Class_Reference/WP_Query#Custom_Field_Parameters. De plus, l(utilisation de l’attribut, méconnu, “no_found_rows” => 1, permet d’alléger grandement les requetes ne nécessitant pas de pagination.

  21. mira dit :

    Je fais partie de la moitié des blogueurs en chemin vers la pharmacie… Je suis tombée sur cet article en suivant un lien dans mon Dashboard actualités WP, ce qui m’indique que c’est bon à lire et à comprendre Mais… c’est du chinois pour moi. Ce que je vais faire c’est imprimer cet article en pdf et essayer de le déchiffrer plus tard. Merci en tout cas

  22. Aleks dit :

    Alors pour info j’ai tenté un peut toutes les options…
    Code postal en nicename ce n’est pas vraiment pertinent pour moi car en France une commune peut avoir plusieurs CP (et puis on peut perdre l’intérêt d’utiliser une URL sémantique à moins de la réécrire etc…) Ceci dit c’était une bonne piste pour les performances de filtre mais comme j’ai d’autres valeurs liées (le code insee etc.)…

    Bref pour info j’ai créé un taxonomy hiérarchique : Region>Departement>Communes (uniquement les libellés). Ce qui représente à peu prés 37000 entrées.
    Sans ajouter des custom fields (je l’ai fait ensuite mais c’est une autre histoire) je dois dire que je suis assez déçu des performances de WordPress vis-à-vis des temps de réponses pour afficher ne serait-ce que la liste en Back Office… (en local sur une grosse machine).

    Bref, je conseillerais de faire une table dédiée et des requêtes SQL directe (et de l’AjAX) sans passer par des fonctions du Codex (sinon WP Query) pour traiter un tel volume de données (et 36000 je trouve que ce n’est pas énorme pour une BDD mais bon les taxonomies à la base étaient des catégories d’articles…)

    Peut-être que quelqu’un a eu une meilleure expérience ?

  23. Marie-Aude dit :

    Non, il n’y a pas théoriquement de “limite” au nombre d’élément dans une taxo, mais 36.000 (quelque soit la base) ça commence à être gros. Surtout à partir du moment où on est en hiérarchique.

  24. WordPress.com fait tourner des millions de sites en multisite, je ne pense pas que 37000 soit une limite de WordPress mais plutôt du serveur et/ou de la BDD.
    Faire des requêtes maisons ne ferait qu’empirer les choses car aucun cache ne serait géré, aucun hook ne passeait par là, bref les API sont meilleures.

  25. Marie-Aude dit :

    Oui mais chaque site a ses propres tables de termes ^^

    En reformulant :
    “sur un serveur mutualisé normal ou un dédié de base, et sans un cache dans l’admin, le chargement de 37.000 valeurs de taxo hiérarchisées est un chouïa lourd” :) :)

    Le problème – et je l’ai vu sur un site – c’est surtout dans tout ce qui est création de post, où normalement ta metabox te fait charger la totalité de la table en hiérarchique, et “en standard” ce n’est pas caché.

    D’ailleurs je suis en train de bosser sur un site où j’ai remplacé la metabox standard par une maison qui charge par niveaux, et c’est nettement plus rapide (et lisible…)

  26. Aleks dit :

    “sans un cache dans l’admin, le chargement de 37.000 valeurs de taxo hiérarchisées est un chouïa lourd”
    voilà… et c’est dommage (et j’ai fait tourner sur une “grosse” bécane dédiée pas un mutualisé…)

    “Faire des requêtes maisons ne ferait qu’empirer les choses car aucun cache ne serait géré, aucun hook ne passait par là, bref les API sont meilleures.”
    Est-ce que ça inclus WP_query, dans laquelle on peut faire du custom SQL ? :)

    Les Apis sont les meilleures oui et non. Je suis d’accord sur la démarche qu’il faut utiliser au maximum les APi, pour pas dire tout le temps. Maintenant les API ramène *parfois* trop de choses ou pas assez donc c’est pas non plus super optimisé, surtout quand on a de très grand volume de données.

    Je vais essayer pour le front du custom SQL avec WP_Query. (En Back c’est quand même acceptable et puis les communes ça ne changent pas tous les jours :))

    Pour info j’ai testé des frameworks aussi du genre http://pods.io/ mais malheureusement ils sont souvent truffés de bugs (et puis on s’éloigne de l’esprit WP). Il vaut mieux coller à l’esprit WP avec les API en effet et jouer avec le cache/APC etc….

    Mais j’espère qu’on aura quand même mieux avec les Taxo ou les liens entre post dans les prochaines versions (je parle du modèle de données).

    @+ ! :)

  27. Marie-Aude dit :

    Aleks, le problème n’est pas wp_query, et n’est pas wordpress, le problème est de construire une liste ordonnée indentée “récursive” avec 37.000 valeurs.

    Quel que soit l’outil, ça sera lourd.

    Regarde comment tous les systèmes travaillent : avec une recherche par paquets, par exemple tous les cp d’un département, puis tous les cp département + 1 chiffre, en chargeant à chaque fois des sous requêtes.

    Ou alors, trouve moi sur le web un site qui affiche ça, sur une seule page, avec une seule requête ^^ (perso, je n’en connais pas)

  28. Et oui, j’en ai fait l’amère expérience sur un site en particulier… Pour la prochaine fois, je repartirai sur de meilleures bases.

  29. @4h18 : Je me permet de ce citer “La technique, c’est comme lire, écrire, ça s’apprend ! Pour maîtriser votre outil, vous allez devoir mettre le nez dans la technique.” ;)

  30. PHPascal dit :

    Je suis pas très chaud a l’idée d’utilisé des taxonomies custom sur WP, je trouve qu’il y a asser déjà sur WordPress différente façon de classer les articles (par date, par catégorie, par tag, par auteur, …). Ça rajoute un autre niveau de structure qui ne remplace pas les custom field.

    Je copmprend bien que les performance sont mieux et que c’est mieux géré a l’interne de WP par contre pour ce qui est d’optimisé la performance de WP j’opterais plutôt pour l’instalation du plugin WP Super Cache.

    Dans un cas concrèt: j’ai ajouter une date de classement dans un champ personnalisé et j’ai eu quelque problème a en faire le tri. Pour l’ajout d’une date je n’ai pas trouver très utile de créé une taxonomie de date, j’ai plutôt personnalisé mes requêtes SQL pour mon classement perso.

  31. Marie-Aude dit :

    Bonjour,
    j’avoue que je ne comprends pas trop votre argumentaire ?

    1. le “niveau de structure”… techniquement c’est quoi ? Il y a dans WordPress des terms, qui peuvent être des catégories, des tags, des media-tags (livrés par défaut), ou ce que vous voulez, ça ne change strictement rien à la définition des tables, aux fonctions, ou à quoi que ce soit du core de WordPress. Et comme il y a déjà deux termes standard (catégorie et tags) on ne peut même pas dire que ça rajoute une requête supplémentaire.

    2. Les customs taxonomies ne sont pas faites pour remplacer les customs fields et vice-versa. En gros :

    • valeurs se répétant pour de nombreux posts -> custom taxo
    • valeurs uniques par post, et pas de recherche ou de tri -> custom fields
    • valeurs uniques, et recherches ou tri, plutôt custom taxo, mais pas hiérarchiques, et tout dépend du nombre de “valeurs”, bref ça se discute

    Donc votre besoin spécifique est effectivement à la marge entre 2 et 3. J’avoue que, quitte à hacker, j’aurais plutôt utilisé un des champs date de la table wp_posts, qui, eux, au moins ont le bon type, et sont indexables. Mais tout dépend du nombre de posts à trier.

    SuperCache n’optimise pas la performance des recherches et de MySQl, il optimise la charge serveur en mettant en mémoire les recherches, c’est totalement différent.

    Sinon, comme vous avez donné le lien vers votre méthode, je me permets de préciser, pour les autres, que la façon de personnaliser vos requêtes est une “horreur” d’un point de vue WordPress.

    Au lieu de réécrire le SQL de base, vous devriez utiliser l’API , en incluant avec meta_query https://codex.wordpress.org/Class_Reference/WP_Query#Custom_Field_Parameters [l’exemple pour un order by avec un custom field est un peu plus haut dans la page) comme l’a indiqué Julio , c’est nettement plus solide sur le long terme.

  32. @PHPascal : Ouch ouch et re ouch. Faire une custom requête via get_col() + plugin de cache en pensant gagner en perf contre une custom taxo est malheureusement le signe que WordPress n’est pas encore maitrisé. Je t’invite à faire des tests de performances entre le vrai fonctionnement de WordPress et ton hack qui saccage ce CMS.
    Bons tests !
    Et je plussoie Marie-Aude bien sûr.

  33. Je viens de lire et ça ne fais que confirmer ce que je dis, WordPress n’est pas compris. Ton argument ici ne pèse pas lourd :/

  34. Herve dit :

    Bonjour,

    Bon j’avai noté cet article il y a un an
    Je l’ai relu de manière plus approfondi car je souhaite faire des sites utilisant les taxonomies.

    En ayant parcouru plusieurs sites, il y a pas mal de termes qui reviennent dès fois en anglais ou en français.
    Si je comprends bien custom taxonomy est le terme générique qui regroupe la structuration des données de manière hiérarchique (catégorie) ou non (tags).
    Les custom Post Type (équivalent des articles) devraient être dans des tables séparés pour favoriser l’indexage ?

    J’utilises Pods (http://pods.io/features/) mais je ne retrouve ces tables justement.
    Donc sans coder à la main, je voudrai avoir l’avis de ceux qui connaissent Pods !!

    Autre question subsidiaire:
    Est-ce que les plugins de type http://www.relevanssi.com/features/ n’améliorent t-ils pas de manière importante la recherche sur tous ces types de champs ?

    Encore merci pour cet article de fond.

    • Marie-Aude dit :

      Bonjour

      les custom post types sont dans la table wp_posts avec l’indication de leur post_type. Cela n’a rien à voir avec l’indexage. Au contraire, avoir une table par type de post alourdirait considérablement la structure, la performance, et poserait de gros problèmes de compatibilité. Pareil pour les customs taxonomies (qui sont bien des modes de classement des données), elles sont intégrées dans les trois tables standard de WordPress.

      Je n’utilise pas Pods, qui avait amha du mérite au tout début, mais qui est une couche supplémentaire et inutile.

      Des plugins comme relevanssi ne modifient pas la structure de la base de données, ne rajoutent pas des index aux tables, donc ils n’ont pas d’impact direct sur la performance de la recherche.

  35. Herve dit :

    Re,

    Effectivement j’ai bien retrouvé mes petits dans cette table ;-). Je pense avoir compris!

    Pour les choix, nous n’avons pas le même profil. Je comprends que tu préfères coder pour mieux maîtriser.

    Je pense qu’il y a des plugins comme Pods (qui m’a l’air le meilleur dans ce domaine) qui certes alourdisse la strcuture mais en facilite le développement.

    Après si ce site doit avoir des milliers de termes et vus par des centaines de personnes par jour, il faut se poser la question de l’outil

    Merci encore pour cette réponse rapide et complète

    • Marie-Aude dit :

      Disons que, de toute façons, Pods n’est pas mon préféré. Quitte à utiliser un plugin, je trouve que la suite GD est meilleure.

      Bonne continuation, en tout cas !

  36. Bonjour Marie-Aude,

    Je me permets de revenir sur ta réponse du 1er avril 2013 (c’est pas une blague ^^) à PHPascal, au point 2 :
    2. Les customs taxonomies ne sont pas faites pour remplacer les customs fields et vice-​​versa. En gros :
    – valeurs se répétant pour de nombreux posts -> custom taxo
    – valeurs uniques par post, et pas de recherche ou de tri -> custom fields
    – valeurs uniques, et recherches ou tri, plutôt custom taxo, mais pas hiérarchiques, et tout dépend du nombre de “valeurs”, bref ça se discute

    J’aide un ami à construire son site. Il y a plus de 100 articles à rentrer, avec à chaque fois des infos répétitives comme la situation géographique / l’année de construction / le type de logement, etc … J’ai donc mis des “custom fields”, en plus, c’est natif avec WP, il les affiche à la suite du contenu, c’est nickel.

    MAIS (… il y a un mais) on voudrait aussi trier les articles par exemple selon la localisation ou selon l’année. J’ai donc pensé au Custom taxonomies.
    Question : est-ce possible d’avoir les mêmes “dénominations” pour des Custom Fields et des Custom taxo ??
    Et comment afficher ça en front-end, si les Custom Fields ne doivent pas être utilisés pour trier ?

  37. Ady dit :

    Bonjour,

    Déjà, un grand merci à toi Marie-Aude ! Je n’ai jamais eu l’occasion de te le dire car je commente très peu, mais voila des années que je lis tes articles (très pertinents!), ou que je te croise sur la toile avec des commentaires sur lesquels je suis très synchro avec toi ! Bref tu fais partie de mes gourous WordPress :)

    Merci également pour cet article fort intéressant (ainsi que les commentaires qui ont suivi).

    Je me permets de “réveiller” ce post, pour poser quelques questions sur le sujet, car je suis en train de devenir dingue. Et je pèse mes mots !! Je me permets donc de “résumer” mon petit projet ici, avec l’espoir d’être lu, et pourquoi pas d’être aidé ou conseillé. Je me permets également de faire un petit appel “caché” ici dans les commentaires de ce post, car j’ai conscience que M.A. et ses fans sont majoritairement des personnes calées en dev’ et plus particulièrement avec WordPress. Je suis prêt à essayer de débloquer une finance pour avoir un accompagnement et conseils de quelqu’un, ce qui me permettrait de développer mon projet sur de bonnes bases. Car j’en peux plus de fonctionner par tatillon, d’avancer, de faire marche arrière, de recommencer perpétuellement. Voila 8 ans que j’ai ce projet en tête sans jamais m’être véritablement lancé. C’est long ! J’ai démarré concrètement il y a 3 mois, et voila 4 fois que je recommence tout de zéro. J’avoue être trop perfectionniste, et cela me joue des tours. Notamment parce que j’ai l’intime conviction que certaines personnes commencent à prendre les devants et que mon propre projet va me passer sous le nez

    Voici pour les plus courageux un résumé de mon fameux nouveau projet, que je trouve à mes yeux, de grande envergure. Ce projet est basé sur le WordPress pour le côté dynamique, mais surtout parce que que mes compétences en dév’ sont limités à ce CMS depuis quelques années, et dont je tombe de plus en plus amoureux !

    J’ai une passion personnelle parmi un grand nombre de confrères : le sport. Un sport bien précis. Le hic c’est que voila bien 15 ans qu’en France, la communauté (de ce sport) se plaint d’un grand vide concernant ce sport sur la toile. Bref c’est la galère !

    En effet, il est difficile de trouver : des événements auxquels participer (tournois/compétitions), des partenaires avec qui jouer, des entraîneurs qui proposent leurs services, et j’en passe. On peut retrouver ce type d’info, mais sur des blogs personnels par ici, une page ou un groupe Facebook par là, etc. L’idée de mon projet est donc de centraliser tout cela, de manière dynamique (avec des fiches, des profils/rôles différents, géolocalisation Google Maps, etc.), le tout en version web 2.0 si j’puis dire ! Je vois peut-être grand, mais le but est devenir LE site de référence francophone en la matière.

    Le premier problème mais bon finalement ça me regarde, c’est que je suis à mon compte, que je m’en sors assez difficilement, et que ce projet va me prendre un temps fou. De plus, ce site a pour vocation de promouvoir ce sport dans l’hexagone, et sera donc complètement gratuit pour la communauté. Mais bon… je suis un passionné, autant de WordPress que de mon sport fétiche ! Et je me dis que peut-être, si le site plait, qu’il attire la communauté, comme je le souhaiterais, avec un bon travail de communication de ma part, peut-être que d’ici je sais pas.. 6, 12, 24 mois, je pourrais mettre en place certaines choses supplémentaires qui pourrait rentabiliser autant les frais serveur, que le temps de travail que j’aurais consacré. Mais évidemment en gardant toutes les idées de base gratuites et accessibles à tout le monde.

    Heureusement pour moi, le côté positif de tous mes retours en arrière, et différents scénarios de dév’, est que je sais sur quelle base je souhaite partir. WordPress + plugins bien spécifiques dont surtout Calendarize It! un plugin événementiel qui m’a séduit. (Ce n’est pas très pro, mais à noter que c’est le 3ème que j’achète, modules compris, et que rien que cela m’a couté un bras – rire jaune – mais nécessaire afin de pouvoir valider LE plugin avec lequel travailler.)

    J’arrête de tirer ce commentaire en longueur, et en vient au fait, et au sujet de cet article : voila une semaine que j’étudie le sujet des Custom Post Type. J’ai potassé le sujet, et appris certaines choses vitales dont le sujet ici (encore merci M.A.). Jusqu’à présent je ne connaissais que ACF, mais voila que je découvre des solutions telles que Types, Pods, ou encore la suite GD que Marie Aude plébiscite et que je ne connaissais pas il y a encore 15 minutes.

    Le truc c’est que j’ai beau voir les tableaux comparatifs, les reviews ou tutoriels de chacun, au final.. je suis PERDU !
    Pourquoi ? Car j’ai l’impression que la conclusion finale est : il n’y en a pas un mieux que d’autres, tout dépend du projet en question !

    Mais je suis bord de l’overdose, je ne supporterais pas de tout recommencer une 5ème fois. Je pense pouvoir être autonome ensuite, mais j’ai besoin de savoir sur quelle base propre/optimisée travailler, par rapport aux Custom Post Types et les Taxonomies associées. C’est la raison pour laquelle je me permets de faire un appel à quelqu’un, le rêve étant d’avoir un retour de toi Marie-Aude (si tu as eu le courage de me lire jusqu’ici), afin de me dire si cela ne te dérangerait pas de me donner des conseils de base de travail, en fonction de certains critères liés à mon projet.

    Evidemment je suis conscient que tu es une professionnelle, et que donc ton temps peut coûter. En quel cas je t’invite à me contacter si tu veux bien et de ne pas approuver ce commentaire en public. Sinon, si ce n’est pas le cas je suis vraiment preneur, si tu veux bien de laisser ce commentaire ici afin que peut-être des lecteurs spécialisés de ton blog me fassent un éventuel retour, si intéressés, soit par me proposer gentillement quelques conseils, soit pour me proposer une petite prestations “conseils pour démarrer ce projet sur de bonnes bases”.

    Désolé d’avoir été aussi long et merci d’avance quoi qu’il arrive.
    Ady

  38. peter dit :

    J’aide un ami à construire son site. Il y a plus de 100 articles à rentrer, avec à chaque fois des infos répétitives comme la situation géographique / l’année de construction / le type de logement, etc … J’ai donc mis des « custom fields », en plus, c’est natif avec WP, il les affiche à la suite du contenu, c’est nickel.

    • Marie-Aude dit :

      Bonjour Peter,
      pour ce genre d’informations, il faut absolument se poser la question “custom field” ou “custom taxonomie” ? Quand elle est répétitive (type de logement, sans doute situation géographique), il faut absolument préférer une custom taxonomie.

      J’ai l’impression que vous n’avez pas lu l’article, mais que vous vouliez juste lâcher un commentaire avec un lien vers un site vendant des produits pour les hommes qui ont des difficultés intimes ?

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *