it-swarm.com.de

XML-RPC und benutzerdefinierte Beitragstypen

Ich kann nicht viel Dokumentation zur Verwendung von XML-RPC und benutzerdefinierten Beitragstypen finden.

Ich habe eine spezielle Anforderung, dass Remote-Posting und -Management (der Client verfügt über eine interne CMS) für einen benutzerdefinierten Post-Typ verwendet werden muss.

1
Jeremy Boyd

@keatch ist richtig, dass "out-of-the-box" WP XML-RPC keine anderen Beitragstypen als "Beitrag" und "Seite" unterstützt. Ein kurzer Spaziergang durch den Code zeigt jedoch an, dass dies relativ einfach zu ändern sein kann.

In WP 3.0.4, xmlrpc.php, Zeile 1989, haben wir die Funktion mw_newPost() (die das schwere Heben übernimmt). In Zeile 2005 gibt es einen if-else, der den Post-Typ überprüft. Eine Erweiterung ist jedoch einfach, indem ab Zeile 2021 zusätzliche Schecks eingefügt werden. In Zeile 2059 haben wir dann einen switch($post_type), der ebenfalls einfach zu erweitern ist.

Und ... das war's schon zum Einfügen. In Zeile 2196 werden die Daten verpackt und eingefügt, und in Zeile 2213 werden die benutzerdefinierten Felder an den Beitrag angehängt, und nichts anderes scheint sich um post_type zu kümmern.

Es gibt wahrscheinlich noch ein paar weitere Erweiterungsmöglichkeiten für andere Befehle, aber suchen Sie einfach nach post_type (ohne das '$') und prüfen Sie, ob es einen Unterschied macht.

Beachten Sie auch: Dies ist eine Core-Datei WP, und alle dazugehörigen Hacks werden beim nächsten Update auf Core überschrieben. Auf der anderen Seite handelt es sich meistens um triviale Änderungen, und Sie können sicherstellen, dass der Client Sie benachrichtigt , bevor ein Update für Core durchführt.


Antwort auf Kommentar: Das Leben ist komplizierter, als es Rarsts Kommentar vermuten lässt. Und die ausgezeichnete Antwort, auf die er hinwies, ist die Lösung eines Problems, das wesentlich einfacher zu sein scheint als Ihre Frage. In kongo09s Kommentar zu Rarsts eigener Antwort in diesem Thread stellte er fest, dass in diesem Bereich wahrscheinlich keine Hilfe kommt.

Benutzerdefinierte Posts sind im Code WP ein wenig nachgedacht. Wenn Sie sich die Logik an mehreren Stellen ansehen, sehen Sie Code, der ursprünglich lautete: "Tun Sie dies mit einem Beitrag". Als Seiten hinzukamen, musste dieser Code erweitert werden, um mit Postseiten und umgehen zu können. Und dann musste es wieder ausgebaut werden, um sich mit Zollposten zu befassen. Dies ist eine klassische Programmierentwicklung: 1, 2, viele.

Der xmlrpc-Code ist eine der Stellen, an denen "2" (und manchmal sogar "1") festsitzt. Wenn Sie versuchen, dem Kerncode Funktionen hinzuzufügen, müssen Sie nicht mehr zwischen mehreren möglichen Pfaden wählen, die alle ihre Nachteile haben.

  1. Senden Sie eine Anfrage/ein Fehlerticket und warten Sie, bis es vom Kernteam behoben wurde. Dies kann einige Zeit in Anspruch nehmen und Ihr Kunde ist möglicherweise nicht bereit zu warten. Ref. Erklärung von kongo09.

  2. Korrigieren Sie den Code selbst und senden Sie einen Patch. Wenden Sie Ihren Patch mit jedem neuen Update auf Core erneut an, während Sie darauf warten, dass es akzeptiert wird. Dies ist eine Art, was ich vorschlug, obwohl ich die Details handwedelte . Das Verwalten der Revisionen über möglicherweise widersprüchliche Änderungen hinweg wird einfacher, wenn Sie so etwas wie Mercurials MqMerge verwenden. Ich würde das nicht mit SVN versuchen. Überprüfen Sie jede Zusammenführung sorgfältig, da dies die Art von Code ist, die über die Drehzahl hinweg völlig durcheinander gebracht werden kann.

  3. Kopieren Sie eine erhebliche Menge des Kerncodes xmlrpc, nehmen Sie Ihre Änderungen vor und schließen Sie ihn über den xmlrpc_methods-Filter an, der in dem Beitrag erwähnt ist, mit dem er verlinkt ist. Dies bedeutet, dass Sie den Code effektiv gegabelt haben. Obwohl es sich um ein "einfaches Update" handelt, ist es auch eine einfache Möglichkeit, wichtige Sicherheitsänderungen zu übersehen, die an dem von Ihnen gabelten Code vorgenommen wurden. Dies ist ein nicht unerhebliches Problem, wie Sie sehen, wenn Sie einfach auf "wordpress xmlrpc security" googeln. Beachten Sie, dass sowohl 3.0.1 als auch 3.0.2 XML-Sicherheitsprobleme aufwiesen.

Sie werden wahrscheinlich gezwungen sein, # 3 oder # 2 in Pik zu machen, denn je mehr Sie sich den Abschnitt WP von xmlrpc ansehen, desto mehr wird Ihnen klar, wie zufällig es ist, was Sie mit was tun können Art der Gegenstände ZB Mit der XML-Schnittstelle WP können Sie nur eine Seite erstellen, aber die MW-Methode mw_newPost() (aufgerufen von der WP-Methode wp_newPost()) ermöglicht neue Seiten oder ) neue Beiträge, aber keine neuen benutzerdefinierten Beiträge - und so geht es. Die vollständige Unterstützung benutzerdefinierter Posts ist mit erheblichem Aufwand verbunden, und die Synchronisierung mit Änderungen am Core kann unabhängig von der gewählten Methode problematisch sein.

Update - 2 Wochen später: Ein Freund hat mir gerade eine Frage gestellt, die fast genau der von Jeremy entsprach. Es zwang mich, den XMLRPC-Code wirklich genau zu betrachten, um zu sehen, wie wir die Änderungen vornehmen können, aber um das von Rarst hervorgerufene Problem "Kern ändern" zu vermeiden. Es stellt sich heraus, dass es eine sehr große Anzahl von undokumentierten do_action()-Hooks sowie (was für diese Zwecke noch wichtiger ist) eine erwähnte, aber undokumentierte apply_filters('xmlrpc_methods', $this->methods);-Methode (Zeile 203) gibt, die das willkürliche Ändern/Hinzufügen/Löschen von Methoden ermöglicht.

Ich behaupte immer noch, dass der XMLRPC-Code ein Sumpf ist, aber mit diesem speziellen apply_filter() können Sie den Sumpf nach links verlassen, ohne den Kerncode zu ändern.

5
Peter Rowell

Es wurde in Wordpress 3.4 aufgenommen. Sie können über die folgenden Funktionen auf benutzerdefinierte Posts zugreifen:

  • wp.getPost
  • wp.getPosts
  • wp.newPost
  • wp.editPost

http://codex.wordpress.org/Version_3.4

http://codex.wordpress.org/XML-RPC_WordPress_API

7
Félix Delval