Importer des données pour le plugin avancé de champs personnalisés?

8

J'ai une section membre construite en utilisant le plugin http://www.advancedcustomfields.com . Il y a 300 membres qui ont chacun les données suivantes:

  • Nom de la compagnie
  • Spécialité (cases à cocher)
  • Adresse web
  • Numéro de téléphone
  • Région
  • Adresse
  • Email

Quelle est la meilleure façon d'importer dans la base de données? Comment dois-je configurer un fichier csv? Je n'ai pas ajouté les 300 pages membres, je viens de configurer ces champs personnalisés en utilisant le plugin.

custom-field import bulk-import Rob
la source
Voté de près comme hors sujet . C'est soit une question PHP / SQL plutôt qu'une question WordPress , ou bien c'est une question spécifique au plugin , et donc trop localisée .
Chip Bennett
4
@ChipBennett ??? C'est ridicule! Exactement sur quel forum suis-je censé poser cette question? Si demandé sur le forum SO normal, ils m'enverraient simplement ici! Il y a beaucoup de questions spécifiques aux plugins ici. Vous êtes beaucoup trop agressif avec la modification de ce forum car ce n'est pas la première fois!
Rob
C'est suffisant. Alors: quelle est la partie spécifique à WordPress de cette question ? Vous posez des questions sur l'importation d'un ensemble de données arbitraires dans une base de données arbitraire, et ce via un fichier CSV. Rien de tout cela n'a à voir avec WordPress. (ps je ne suis pas un mod.)
Chip Bennett
5
@ChipBennett Cela a TOUT à voir avec Wordpress car j'ai besoin de tout dans un format lisible par les cms. Donc, vous dites que les centaines de questions sur les plugins sont trop localisées et que les questions de base de données ne sont pas liées. La barre latérale de mes questions connexes est remplie de questions similaires, mais selon vos "règles", je ne peux pas la publier ici! Exactement où dois-je poster cela alors?
Rob
Qu'entendez-vous par « lisible par le CMS »? Voulez-vous dire que vous essayez de faire une importation SQL brute pour mettre à jour les wp_post_metaentrées de la table DB pour 300 publications existantes?
Chip Bennett

Réponses:

5

On dirait que vous avez réussi à importer les 300 pages sur la base des commentaires. (Peu importe comment vous l'avez fait, soit en utilisant le plugin d'importation WordPress, soit en utilisant un outil MySQL comme phpMyAdmin ou Sequel Pro ou autre) ... Vous avez 300 pages dans le wp_poststableau. Commençons à partir d'ici alors ...

Le plugin ACF utilise le wp_postmetatableau pour remplir et lier des champs personnalisés à des publications / pages spécifiques. (Un design très réfléchi, au fait)!

Ce tableau se compose de 4 colonnes:

meta_id - Une clé primaire unique incrémentée automatiquement

post_id - Une clé étrangère qui renvoie à la publication ou à la page

meta_key - Dans ce cas, le nom (clé) du champ personnalisé

meta_value - Le texte ou le contenu réel de ce champ personnalisé

Donc, si vous avez créé un fichier CSV, vous créeriez essentiellement vos données pour les adapter à ce modèle. Si vous avez 300 enregistrements assis dans votre wp_poststable, ils devraient tous avoir un unique ID(dans la IDcolonne). C'est l'identifiant que vous mettrez dans la wp_postmeta.post_idcolonne.

Maintenant, si vous inspectez le groupe de champs que vous avez créé, vous verrez tous les noms de champs (qui sont les wp_postmeta.meta_keyvaleurs. Voici une capture d'écran d'un exemple dans un projet sur lequel je travaille en ce moment:

Exemple ACF

J'ai nommé le mien header_contentet left_sidebar_contentpar exemple. Enfin, jetez les valeurs de chacun de vos champs dans le wp_postmeta.meta_valuechamp.

Tout cela est une présentation de haut niveau du schéma et de la structure des données. La mise en œuvre réelle de la façon dont vous importez les données dépend de vous. (Que vous utilisiez un fichier CSV, XML ou que vous écriviez réellement du SQL pour insérer les données).

J'espère que cela vous aidera à vous mettre sur la bonne voie!

Jared Cobb
la source
ne peut pas accepter l'approche utilisée par ACF est une bonne conception ou non, car les données ne sont pas faciles à rechercher ou à indexer ...
Raptor