web-dev-qa-db-fra.com

Mieux post meta efficacité?

Je travaille avec des sites Web nécessitant l'utilisation de Post Meta pour les objets de publication dans un type de publication particulier.

J'ajoute souvent une méta-boîte à un type de publication particulier, afin de fournir des paramètres supplémentaires pour le nouvel objet de publication en cours de création.

Comme vous pouvez l’imaginer, j’ai créé quelques classes qui facilitent la gestion de Post Meta pour tous mes besoins quotidiens.

Je suis arrivé à la pratique habituelle de toujours préfixer toutes mes clés de champ personnalisé. J'ai décidé de toujours utiliser mes initiales, puis une référence rapide pour en savoir plus sur les champs.

Ainsi, par exemple, si je devais ajouter des paramètres de visibilité à tous les objets de publication d'un type de publication particulier. Un préfixe de clé de champ personnalisé pourrait ressembler à: mbe_visibility_.

Donc, si j'avais un champ personnalisé 'Global' pour l'objet Post. Cela pourrait ressembler à: mbe_visibility_global.

J'ai actuellement une fonction qui récupère tous les champs personnalisés pour l'objet de publication, puis effectue une itération parmi les champs renvoyés, en filtrant uniquement les champs qui ont le préfixe de clé de champ (mbe_visibility_).

Donc, si j'avais trois champs personnalisés: Global, Post Types et Posts, j'aurais trois clés (chacune contenant une valeur, spécifiée lors de l'enregistrement de l'objet Post): mbe_visibility_global, mbe_visibility_post_types et mbe_visibility_posts.

Maintenant, voici où mes questions commencent à se formuler.

J'ai l'impression que c'est un peu abusif de chercher/filtrer TOUS les champs personnalisés attribués par le noyau WordPress et d'autres plugins divers sur le site Web.

Je pensais simplement changer la façon dont Post Meta est stocké/référencé pour mes champs personnalisés.

Au lieu d'enregistrer une nouvelle clé de publication pour chacun des champs personnalisés, enregistrez tous les champs personnalisés dans UNE clé de publication pour cet objet de publication.

Mon approche consistait simplement à coller toutes vos données $_POST dans un tableau. Ainsi, un champ de saisie dans une méta-boîte pourrait ressembler à ceci: <input type="checkbox" name="mbe_visibility[general][global_visibility]" value="'.$value.'" />

Alors maintenant, lorsque vous vous connectez à save_post, il vous suffit de vérifier si UNE clé est disponible.

if(isset($_POST['mbe_visibility'])) et enregistrez tout le tableau dans une clé Post Meta.

update_post_meta($post_id, 'mbe_visibility', $_POST['mbe_visibility']) devrait probablement nettoyer/valider les données avant de sauvegarder, mais ceci est juste pour exemple.

Maintenant, tout ce que j'ai à faire, pour référencer TOUS mes champs personnalisés à partir de la méta de publication de l'objet Post, tout ce que je dois faire est: get_post_meta($post_id, 'mbe_visibility', true) et j'aurai précisément ce que je veux pour cet objet de publication, sans avoir à chercher et filtrer toutes sortes d'autres Post Meta inutiles de WordPress core ou d'autres plugins divers.

Si vous avez réussi mon explication longue, la question est: Est-ce une mauvaise idée de stocker tous vos champs personnalisés dans une seule méta clé de publication, pour une gestion plus facile des données? CONTRE. Stocker chacun de vos champs personnalisés dans des clés méta postales individuelles pour chaque champ personnalisé.

Bien sûr, j'aimerais voir une explication valable accompagnée d'un raisonnement à l'appui de votre réponse.

2
Michael Ecklund

Si vous devez rechercher par votre meta_key/meta_value, ne les stockez pas dans une seule clé. Si vous stockez en tant que clé unique, vous devrez alors stocker vos données sous forme de chaîne serialized ou quelque chose de similaire. La seule façon de faire une recherche serait via une requête inefficace %LIKE% qui serait probablement également entachée d'erreur. Quelque chose de similaire est vrai si vous devez trier les requêtes sur l'une de vos valeurs. Vous ne pouvez obtenir aucun type raisonnable de tri alphabétique ou numérique, ressemblant à un humain, d'une chaîne sérialisée. Si vous vous attendez à devoir effectuer des manipulations au niveau de la base de données, enregistrez en tant que meta_keys individuel.

Si, toutefois, tout ce dont vous avez besoin est d'extraire les données de la méta_key de la base de données sous forme de bloc monolithique, tout devrait bien se passer.

3
s_ha_dum