Типы XML-RPC и пользовательских сообщений

Я не могу найти много документации по использованию XML-RPC и настраиваемых типов сообщений.

У меня есть специальное требование, чтобы удаленная проводка и управление (клиент имел встроенные cms) должны использоваться для настраиваемого типа сообщений.

Solutions Collecting From Web of "Типы XML-RPC и пользовательских сообщений"

@keatch правильно, что готовый WP XML-RPC не поддерживает типы сообщений, отличные от «post» и «page». Однако, быстрая прогулка по коду показывает, что это относительно легко изменить.

В WP 3.0.4, xmlrpc.php , строка 1989, мы имеем функцию mw_newPost() (которая делает тяжелый подъем). На строке 2005 есть проверка if-else типа post, но ее было бы легко расширить, вставив дополнительные проверки, начиная с строки 2021. Затем в строке 2059 есть switch($post_type) , который также будет легко расширяться.

И … это о нем для вставки. На строке 2196 данные завернуты и вставлены, а в строке 2213 пользовательские поля прикреплены к сообщению, и ничто другое не заботится о post_type .

Вероятно, есть еще несколько мест для других команд, но просто post_type поиск в post_type (без «$») и посмотрите, не изменится ли это.

Хорошо заметьте: это основной файл WP, и любые хаки будут перезаписаны следующим обновлением до ядра. С другой стороны, это в основном тривиальные изменения, и вы можете убедиться, что клиент уведомит вас, прежде чем они сделают обновление для ядра.


Ответ на комментарий: Жизнь сложнее, чем комментарий Рарста. И отличный ответ, на который он указал, – это решение проблемы значительно проще, о чем, по-вашему, спрашивает ваш вопрос. В комментарии kongo09 к собственному ответу Рарста в этой теме он заметил, что «в этой области, вероятно, нет помощи».

Пользовательские сообщения являются немного запоздалыми в WP-коде. Когда вы смотрите на логику в нескольких местах, вы видите код, который изначально сказал «сделайте это с сообщением». Когда страницы приходили, этот код должен был быть расширен, чтобы иметь дело с сообщениями и страницами. И затем его пришлось снова расширить, чтобы иметь дело с таможенными постами. Это классическая эволюция программирования: 1, 2, много.

Код xmlrpc является одним из мест, застрявших в «2» (а иногда даже «1»). При попытке добавить функциональность к базовому коду вы застряли в выборе между несколькими возможными путями, все из которых имеют свои недостатки.

  1. Отправьте запрос / билет с ошибкой и дождитесь, когда он будет исправлен основной командой. Это может занять некоторое время, и ваш клиент, возможно, не захочет ждать. Ссылка заявление kongo09.

  2. Исправьте код самостоятельно и отправьте патч. Повторно применяйте патч с каждым новым обновлением до ядра, пока вы ждете его принятия. Это то, что я предлагал, хотя я подробно рассказал подробности. Управление изменениями по возможным конфликтующим изменениям будет проще, если вы используете что-то вроде Mercurial's MqMerge. Я бы не пробовал это с SVN. Проверяйте каждый слияние тщательно, потому что это тип кода, который может полностью зависеть от оборотов.

  3. Скопируйте значительную часть основного кода xmlrpc, внесите изменения и подключите его через фильтр xmlrpc_methods упомянутый в сообщении, которое он связал. Это означает, что вы эффективно разветвили код. Хотя это делает «легкое обновление», это также простой способ пропустить важные изменения безопасности, внесенные в код, который вы раздвоили. Это не такая незначительная проблема, как просто поиск по Google WordPress xmlrpc security покажет вам. Обратите внимание, что в версиях 3.0.1 и 3.0.2 были проблемы с безопасностью XML.

Скорее всего, вам придется делать # 3 или # 2 в пиках, потому что чем больше вы смотрите на раздел WP xmlrpc, тем больше вы понимаете, насколько он бесполезен в отношении того, что вы можете делать с каким типом объектов. Например, используя WP xml-интерфейс вы можете создавать только страницу, но метод MW mw_newPost() (вызывается методом WP wp_newPost() ) позволяет wp_newPost() новые страницы или новые сообщения, но не новые пользовательские сообщения – и так оно и происходит. Для полной поддержки пользовательских сообщений потребуются значительные усилия, и синхронизация с изменениями в ядре может быть проблематичной, независимо от выбранного вами метода.

Обновление – 2 недели спустя. Так что друг просто задал мне вопрос, который был почти таким же, как у Джереми. Это заставило меня внимательно посмотреть на код XMLRPC, чтобы увидеть, как мы можем внести изменения, но избегаем проблемы с «изменением ядра», поднятой Rarst. Оказывается, существует очень большое количество недокументированных do_action() крючков плюс (что более важно для этих целей) упомянутые, но недокументированные apply_filters('xmlrpc_methods', $this->methods); (строка 203), которая допускает произвольное изменение / добавление / удаление методов.

Я все еще утверждаю, что код XMLRPC – это болото, но этот конкретный apply_filter() позволяет вам левого поворота из болота без изменения кода ядра.

Он был включен в WordPress 3.4. Вы можете получить доступ к такому типу сообщений через функции thoses:

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

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

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

http://codex.wordpress.org/XML-RPC_wp сообщает документацию XML-RPC и немного устарел.

http://core.trac.wordpress.org/browser/trunk/wp-includes/class-wp-xmlrpc-server.php является фактическим сервером XML-RPC. При быстром просмотре, кажется, что публикация в пользовательский тип сообщения не поддерживается!