XML-RPC et types de publication personnalisés
Je ne trouve pas beaucoup de documentation sur l'utilisation de XML-RPC et de types de publication personnalisés.
J'ai une exigence spécifique selon laquelle l'affichage et la gestion à distance (le client dispose d'un cms interne) doivent être utilisés pour un type d'article personnalisé.
@keatch a raison de dire que WP prêt à l'emploi _ _ XML-RPC ne prend pas en charge les types de publication autres que 'post' et 'page'. Cependant, une promenade rapide dans le code indique que cela peut être relativement facile à changer.
Dans WP 3.0.4, xmlrpc.php, ligne 1989, nous avons la fonction mw_newPost() (qui effectue le gros du travail). À la ligne 2005, un if-else vérifie le type de publication, mais il serait facile de l'étendre en insérant des vérifications supplémentaires à partir de la ligne 2021. À la ligne 2059, nous avons un switch($post_type) qui serait également facile à étendre.
Et ... c'est à peu près tout pour l'insertion. À la ligne 2196, les données sont encapsulées et insérées et à la ligne 2213, les champs personnalisés sont attachés à la publication et rien d'autre ne semble se soucier de post_type.
Il y a probablement quelques emplacements supplémentaires à étendre pour d'autres commandes, mais il suffit de chercher sur post_type (sans le '$') et de voir si cela fera une différence.
Notez bien: c’est un fichier principal WP et tous les fichiers de piratage qu’il contient vont être écrasés par la prochaine mise à jour de la version principale. D'un autre côté, il s'agit principalement de modifications triviales et vous pouvez vous assurer que le client vous avertit avant qu'il effectue une mise à jour du noyau.
Répondre au commentaire: La vie est plus compliquée que ne le laisserait croire le commentaire de Rarst. Et l'excellente réponse qu'il a donnée est la résolution d'un problème beaucoup plus simple que ce que votre question semble poser. Dans le commentaire de kongo09 à la propre réponse de Rarst sur ce sujet, il a observé qu'il n'y avait "probablement aucune aide" dans ce domaine.
Les messages personnalisés sont un peu une réflexion après coup dans le code WP. Lorsque vous examinez la logique dans un certain nombre d’endroits, vous voyez un code qui disait à l’origine "faites-le avec un message". Lorsque les pages arrivaient, ce code devait être développé pour traiter les pages posts et . Et ensuite, il a fallu l'étendre à nouveau pour traiter des postes de douane. C’est une évolution classique de la programmation: 1, 2, beaucoup.
Le code xmlrpc est l’un des endroits bloqués à "2" (et parfois même à "1"). En essayant d'ajouter des fonctionnalités au code principal, vous ne pouvez pas choisir entre plusieurs chemins possibles, qui présentent tous des inconvénients.
Soumettez un ticket de requête/bug et attendez qu'il soit corrigé par l'équipe principale. Cela peut prendre un certain temps et votre client peut ne pas vouloir attendre. Réf. la déclaration de kongo09.
Corrigez le code vous-même et soumettez un correctif. Réappliquez votre correctif à chaque nouvelle mise à jour sur le noyau en attendant qu'il soit accepté. C’est un peu ce que je suggérais, bien que j’ai passé à la main les détails. La gestion des révisions lors de modifications potentiellement conflictuelles sera plus facile si vous utilisez quelque chose comme MqMerge de Mercurial. Je n'essaierais pas cela avec SVN. Vérifiez chaque fusion avec soin car il s’agit du type de code qui peut être totalement bloqué sur plusieurs tours.
Copiez une quantité substantielle du code xmlrpc principal, apportez vos modifications et connectez-le via le filtre
xmlrpc_methodsmentionné dans le message auquel il a accédé. Cela signifie que vous avez effectivement bifurqué le code. Bien que cela permette une "mise à jour facile", c'est aussi un moyen facile de rater des modifications de sécurité cruciales apportées au code que vous avez créé. C’est un problème non négligeable, comme le montre simplement googler sur "wordpress xmlrpc security". Notez que les versions 3.0.1 et 3.0.2 présentaient toutes deux des problèmes de sécurité XML.
Vous allez probablement être obligé de faire le n ° 3 ou le n ° 2 à la pelle car plus vous regardez la section WP de xmlrpc, plus vous vous rendez compte à quel point il est hasardeux de faire ce que vous pouvez faire avec ce que vous pouvez faire. type d'objets Par exemple En utilisant l'interface WP xml, vous ne pouvez créer qu'une page, mais la méthode MW mw_newPost() (invoquée par la méthode WP wp_newPost()) autorise les nouvelles pages ou nouveaux messages, mais pas de nouveaux messages personnalisés - et ainsi de suite. Soutenir pleinement les publications personnalisées nécessitera un effort important et sa synchronisation avec les modifications apportées au noyau peut poser problème, quelle que soit la méthode choisie.
Mise à jour - 2 semaines plus tard: Un ami vient donc de me poser une question qui était presque exactement identique à celle de Jeremy. Cela m'a obligé à jeter un coup d'oeil vraiment dur sur le code XMLRPC pour voir comment nous pouvons effectuer les modifications tout en évitant le problème de "modification du noyau" soulevé par Rarst. Il s'avère qu’il existe un très grand nombre de points d'ancrage do_action() non documentés, plus (plus important encore à ces fins), une apply_filters('xmlrpc_methods', $this->methods); mentionnée mais non documentée (ligne 203) qui permet une modification/addition/suppression arbitraire de méthodes.
Je maintiens toujours que le code XMLRPC est un marécage, mais cette apply_filter() particulière vous permet de tourner à gauche du marais sans modifier le code principal.
Il a été inclus dans Wordpress 3.4. Vous pouvez accéder au type personnalisé post via ces fonctions:
- wp.getPost
- wp.getPosts
- wp.newPost
- wp.editPost