Advanced Custom Fields Export PHP vs JSON

Bonjour,

Cette problématique aurait sa place sur le support ACF mais j'ai un peu de mal à y trouver des informations suffisamment claires dans un anglais que je peux comprendre, donc :

Je voulais utiliser ACF sous wordpress pour générer mes champs perso et pensais que l'export en code PHP me permettrait d'éviter d'installer ACF sur le site en production.
Sauf que vraisemblablement cela ne marche pas : mes champs n'apparaissent dans l'admin en prod que si j'installe et active ACF. Autant les coder moi-même dans ce cas.
Il y a sinon un export JSON proposé. Mais cela veut dire que les champs sont déclarés dans la base et pas dans le code en dur ? Je trouve ça dangereux, dans le sens où j'ai l'habitude d'avoir du code pour chaque champ.
Ma question : ai-je tout compris à l'export / utilisation externe des champs ACF ou rien du tout ?

Merchiiiii

Mais quel est l'intérêt de ne pas installer acf sur le site en production ?

C'est certain que tu ne pourras pas utiliser l'export php car il contient des fonctions définies par ACF et les fichiers json doivent certainement être lu par le plugin eux aussi.

L'intérêt c'est toujours l'indépendance.
Déjà jme coltine une indépendance côté dev front :
http://www.billerickson.net/advanced-custom-fields-frontend-dependency/
J'aurais bien voulu faire de même côté back.

Bon j'ai capté entre temps qu'il fallait inclure ACF dans le thème de façon invisible, mais au final, à force d'utiliser du code pour générer du code qui génère un code afin d'obtenir un résultat... jcommence à me demande si des copier/coller/adapter de codes WP de création de custom fields seraient pas plus rapide.

Là, tu es toujours dépendent du plugin donc c'est contre productif de chercher à faire cela. Ce qui va plus vite c'est d'utiliser ACF complétement, pas de refaire à la main ce que celui-ci fait déjà.

D'autre part il est bien plus difficile de reconstruire une admin comme la génère acf avec des repeaters, champs relationnels et compagnie que de recoder un template. Et si quelqu'un désactive le plugin le site ne sera de toute façon plus opérationnel (même si il aura peut être l'air de) car il ne pourra plus être alimenté correctement.

Oui, enfin du côté front, l'indépendance a son intérêt puisque les données seront toujours affichées si le plugin est désactivé ou supprimé.
Je suis d'accord par contre que l'admin acf, le temps de la recoder serait assez conséquent. Mais j'imaginais qu'ils étaient capable de générer le code que je me tapais lorsque je construisais mes custom fields à la main. Et donc qu'il ne serait pas nécessaire d'embarquer acf en prod. Bon, c'était pas des custom fields ultra élaborés...
Ensuite, inclure acf dans un thème a ses désavantages puisqu'invisible, il n'est ni mis à jour, ni supprimable ce qui annule l'intérêt de l'indépendance...

http://www.advancedcustomfields.com/resources/including-acf-in-a-plugin-theme/

Beaucoup de questions au final pour lesquelles il va falloir que je trouve rapidement des réponses si je veux avancer

Je pense qu'a un moment c'était possible car il y avait un export xml compatible avec celui de wordpress. (aujourd'hui remplacé par celui en json).

Pour info, il y a possibilité de créer un dossier spécial pour les plugins qui ne doivent pas être désactivé ou subir les auto update ; Must Use Plugins

Oui, je gère mes fonctions principales orientées données dans un mu-plugin, même si mon client n'est pas censé changer de thème mais pour acf il est difficile de l'intégrer de cette manière sans changer quelque-chose ailleurs dans la config donc au final je l'embarque comme ils le préconisent sur leur site. Je tente le remplacement des fonctions propriétaires par celles de wp par contre parce que cela accélère le traitement même si cela doit être infime.