Devrais-je utiliser des types de publication personnalisés ou des tables de base de données personnalisées pour le développement de plug-in?
Je suis assez nouveau dans l'écriture de plugins wordpress, mais j'ai déjà sauté dans le vif du sujet et je veux m'assurer que je le fais "correctement" dans mon prochain grand projet.
Je vais fortement étendre wordpress dans une application Web assez grosse et je veux garder mes structures de données aussi natives que possible pour pouvoir utiliser le framework wordpress, mais je ne sais pas s'il est préférable de créer mes propres tables de base de données personnalisées. ou essayez d'utiliser des types de publication personnalisés.
Je ne connais pas encore toutes mes données, mais il y aura un certain nombre de tables (ou cpts) liées de manière relationnelle. Mes recherches me donnent l’impression que je devrais éviter les tables de base de données personnalisées, mais je ne sais pas comment déterminer la meilleure solution.
Plus précisément, je suis préoccupé par trois domaines:
- le nombre de post-champs dont j'aurai besoin pour mes champs supplémentaires par cpt si j'emprunte cette route, et si cela rendra les choses "difficiles"
- comment bien je peux récupérer des requêtes en utilisant des filtres relationnels semi complexes pour les rapports
- comment gérer au mieux les relations, surtout si j'ai plusieurs relations
Y a-t-il un "bon" chemin? Merci pour votre contribution.
Vous devriez vous méfier de quiconque affirmant qu'il existe un seul "bon" moyen. La bonne façon dépend de la situation. L'utilisation de l'infrastructure CPT présente un certain nombre d'avantages notables:
- Vous obtenez gratuitement l'interface utilisateur du tableau de bord
- Vous tirez automatiquement parti de la mise en cache de WP, y compris de tous les plug-ins de cache persistant que l'installation peut utiliser.
- Vous obtenez automatiquement des goodies comme des révisions post
- Vous avez accès à la classe
WP_Query, ce qui signifie qu'en théorie, vous n'avez pas à écrire de code SQL (ou du moins pas beaucoup) susceptible d'être bogué, vulnérable et inefficace. - Si vous envisagez de distribuer le plug-in ou de l'ouvrir pour un développement à source ouverte, vous constaterez peut-être que les développeurs sont plus à l'aise avec les types de publication personnalisés et les fonctions d'API associées que vos propres éléments personnalisés.
Les problèmes liés à l'API CPT proviennent principalement du fait qu'il est très lié à la métaphore "posts" et à tous les aspects de ce type de données qui accompagnent la métaphore. À partir de la ligne de commande MySQL, exécutez DESCRIBE wp_posts. WP suppose que votre contenu a un titre, qu'il a un auteur (unique), qu'il vous suffit de garder trace de la date créée et de la date de la dernière modification, qu'il vous faut de l'espace pour un unindexed post_content, etc. Cela fonctionne bien pour certains types de contenu, mais pas nécessairement pour d'autres. Vous avez déjà indiqué des problèmes potentiels:
le nombre de post-champs dont j'aurai besoin pour mes champs supplémentaires par cpt si j'emprunte cette route, et si cela rendra les choses "difficiles"
Il existe deux manières d'augmenter le schéma wp_posts via l'API CPT: postmeta et les taxonomies. Postmeta est constitué de paires clé-valeur non indexées, ce qui est idéal pour stocker un tas de données diverses, mais pas du tout optimisé pour effectuer des recherches complexes. Les taxonomies sont un peu plus flexibles à cet égard, mais vous devrez faire face à de nombreuses sous-requêtes potentiellement coûteuses si vous avez des recherches très complexes. (Les arguments meta_query et tax_query et leurs classes de constructeur de requêtes sont très pratiques et pratiques, cependant.)
Si, comme vous le suggérez, vous only avez besoin de faire ce type de "filtres relationnels semi-complexes" dans le cas de rapports occasionnels, alors cette architecture est probablement OK pour vous. C'est lorsque vous commencez à exposer les filtres aux utilisateurs, de sorte que vous devez exécuter de nombreux JOINname__s et des sous-requêtes complexes à tout moment, que les choses deviennent incontrôlables.
comment gérer au mieux les relations, surtout si j'ai plusieurs relations
Les relations plusieurs à plusieurs sont un point de blocage de longue date dans la WP communauté de développeurs (voir https://core.trac.wordpress.org/ticket/14513 ). Vous pouvez faire semblant sans utiliser de tables personnalisées en mappant des éléments de taxonomie sur post_ids (vous pouvez par exemple dire que 'P3 a la relation Y à P5' en disant que P3 a la balise 'Y-P3') (et inefficace) très rapidement. Vous pouvez également envisager de créer votre propre table de relations qui relie les CPT - vous bénéficierez toujours des CPT et ne créez qu'une seule table de base de données. Pour une version bien exécutée de cette méthode, voir le plugin Posts 2 Posts: https://wordpress.org/extend/plugins/posts-to-posts/
Donc, à la fin, vous devriez décider en fonction de:
- Le type de données que vous allez stocker - comment "post" y sont-ils
- Les types de requêtes qui seront nécessaires - quelle sera leur complexité?
- Échelle - quelle est la complexité de votre schéma souhaité, combien d'objets totaux aurez-vous et combien d'utilisateurs envisagez-vous?
Si les réponses sont: très posty, pas trop complexe, et ne devez pas vous mesurer à une taille énorme, optez pour les CPT. Sinon, considérez vos propres tables.