• View
• Edit
• History
• Attach
• Print
• Backlinks

XMLRPC-Talk

Help Test XMLRPC - Instructions

Every blogging software package is different. Here's some general guidelines, please note what actually works in the software you test in the chart below.

• Important: If there's a network log or console in the application which logs the xml transactions, please try to send them to Crisses at her kinhost.org email address.
• The custom "blog XMLRPC API url" for the test blog is http://xmlrpc.eclectictech.net/pmwiki/pmwiki.php?action=xmlrpc
• Whenever possible select the MetaWebBlog API -- if not listed, other blogging platforms may use MetaWebLog API (i.e. try selecting WordPress or other blog platforms which allow a custom API url).
• Use your own username (it's arbitrary, but will show up in Recent Changes & page history), and the password "pmwikiuser" (no quotes).
• Some software pulls in all available "BlogId"s (PmWiki Groups) for your username and password. When you need to enter the "BlogId" or "Blog name" try "Blog" or "Main". On the test site, "Blog" has been populated with past blog posts.
• Try 2 ways to "title" your posts (some software works the first way, some requires the second way):
  • Simple post title: "This Is My New Page"
  • Explicit post title with group name: "Blog.This Is My Other New Page"
• Use HTML Mode or "Source Code" mode, but write wiki code just as if you were editing pages on your website i.e. use wiki markup, not HTML
• Check the option/preferences/settings for the client application: disable changing linebreaks to HTML & disable processing Markdown if it's an option
• Check on changes you post at http://xmlrpc.eclectictech.net/pmwiki/pmwiki.php/Blog/Blog or http://xmlrpc.eclectictech.net/pmwiki/pmwiki.php/Site/AllRecentChanges
• Add your experiences to the chart below.

Feel free to alter posts or create new posts in the Blog group. It's a scrap wiki, you can post anywhere, but it will be easier to find if it's in the Blog group, and you'll be able to tell whether the software works as expected.

State of the Package XES February 19, 2014, at 04:26 PM

Thank you to testers, good to know just how broken this package currently is :)

The xmlrpc-0.2.zipΔ package is out-of-date (Linux users with access to Drivel should try the old package -- it may "just work" out of the box). Blogger (by Google) no longer uses XMLRPC, and MetaWeblog is more of a standard than the old Blogger (1.0) API (it includes some of the same calls and functionality, but there are some significant changes to content handling of pages/posts most specifically, and no API key in the MetaWebLog XML makes the 2 standards completely incompatible). I have eliminated both blogger.php and voodoopad.php included in the old package, and am working to support the MetaWeblog API in the hopes that it will return full functionality to the package. Some services have moved on to SOAP, but that is out of the scope of this package.

The new package will have all PmWiki API support in the xmlrpc.php file and the phpxmlrpc package includes (*.inc files) in the xmlrpc/ folder (which can probably be periodically updated to the upstream files without affecting functionality as bugs are fixed or security holes patched). As mentioned above, Blogger API has fallen out of favor in the blogosphere, and hopefully VoodooPad supports MetaWebLog and thus this should "just work" anyway -- so both the blogger.php and voodoopad.php have been eliminated from the package (I may add Blogger functionality back in to support Blogger 1.0 API in the basic package in the future). This package is not for RSS feeds, so I decided not to use the Atom protocol (and reserve the right to change my mind).

Content delivered is full markup, thus you should require at least edit permissions to view page contents.

Progress

• simple PmWiki password works ("Page Title" becomes "Group.PageTitle") in client software unless otherwise noted.
• handles "list of blogs" (i.e. PmWiki Groups)
• lists pages in the selected blog/group (, working on meeting page data specs...then will fix the data itself.)
• hands real page URL to client (for "view in browser")
• hands real page title to client (as defined by (:title xxx:) OR the unadulterated Group.Name of the page)
• pulls in Category list as defined by $CategoryGroup (per PmWiki standards) $Name's
• now allows tagging of new and updated pages - TO DO: recognize & check-off existing tags already on a page
• now deletes pages
• now records the author's Profile link on Recent Changes
• now attempting to sniff network traffic via Wireshark on my mac to debug app
• Detect newlines: added feature to detect \n when content is sent back from the client software package: if undetected will attempt to change <br> and <p> tags into newlines. This helps ScribeFire work as expected, and may help other client packages.
• Now has SDV filters to modify Groups included in "BlogId" (i.e. you can now eliminate PmWiki, Site, SiteAdmin, Data, Category...), can add desirable blog groups to list even if they don't exist yet (i.e. Profiles or Events or other potential PmWiki groups you desire) and can ignore all of the above by supplying a static list of groups i.e. if you only want "Blog,Main" groups, you can just override with a static list and save some processing power.

Known Issues:

Package-specific

• Posts pulled off the server lose their association to categories. Your blog software may or may not remember the association, but the information should be retrieved from the server.
• There is currently no difference between tags and categories... not sure if there should be, per PmWiki's standards. You can go nuts and use Categories like tags, or you can go simple and just assign a few broad categories to your posts...they'll all end up in the Category group by default or whatever group you set as your category group in your config.php.
• Need to eliminate category divs when there are no post tags/categories (see Blogsy).

PmWiki Good Manners

• Need SDV filter to exclude category pages (i.e. Category.GroupHeader or Category.Category, user-configurable) (will be similar to groups/BlogId above)

Notes

• If "Link" field is available, "Title" field in blog editor can be treated as arbitrary. "Link" should be the wiki page name. When link field is empty or unavailable, title & group (the current "BlogId" chosen in the blogging package) will help determine wikipage's $FullName. Use (:title:) markup to specify the page $Titlespaced per usual.
• I may make it such that the blog "Title" field fills in (:title:) markup later (if so, it will be at the end of the page and automatically remove any other (:title:) markup on the page).
• Some other recipes may break XMLRPC's functioning. Toying with how to fix this problem. This is an authentication issue; XMLRPC needs to run BEFORE authentication. Most recipes are unneeded when using XMLRPC unless they change how page markup is saved. XMLRPC will probably need to be included directly after setting up passwords, and I may have to change the authentication portions to authenticate the blog software user earlier than waiting for HandleAction.

I will upload a new package and keep the old package linked on the page in case anyone wants to use old Blogger-compatible software with their wiki. It should still work, although I haven't been able to test it. If you have a package compatible with the pre-2014 package, please post specs here for others, I will be updating the main XMLRPC page to reflect the 2014 package once it appears to be basically bug-free:

Old Package:

Old Notes

Updating for PHP5.x

I'm working on upgrading this package, want to keep notes in case I get interrupted or anyone wants to join in the fray. Here's what I've tested on my PHP5.4 server:

• Package fails with latest PmWiki. faultcode 105
• Installed pmwiki-2.0.beta26 -- the last reported "working" version for XMLRPC and installed the base recipe (without .inc upgrade) in a new blank wiki. I get the same fault code I get with the latest PmWiki. The problem is likely php5 related.
• Package fails (same code) if I upgrade the .inc files to latest from http://gggeek.github.io/phpxmlrpc/ & add in the new .inc to the recipe. The class calls appear to be the same. The problem is likely the actual recipe, not the upstream code.
• Turned each of Voodoopad & Blogger off, same error, so it's not just one of the interfaces producing a problem.

• XML is being produced, but recipe is not delivering data to the functions included. I can connect, authenticate, etc. in Ecto, but no files are listed. Simply putting ?action=xmlrpc into the browser shows the XML error message nested into XML.

Recipe Files

Former Progress

I'm out-of-touch on current PmWiki pagestore and grabbing raw markup...AND I'm not up on differences between php4 & php5. So this might be over my head. There are no errors or warnings being thrown in my error console. Also, the problem may be a combination of things. Difficult to debug without error messages on the logs. XES February 04, 2014, at 02:05 PM

Ok, I've fussed with it a lot more. Using Ecto and its console, I have XMLRPC actually talking. Part of the problem is that settings in Ecto have changed and you must use the Movable Type or Movable Type 4 rather than Blogger (which auto-connects to Google, and they don't understand your credentials). Handshakes are made, Ecto gets "Blog" (=PmWiki groups) info, but then it fails with methods that are requested by Ecto but our XMLRPC recipe doesn't provide. Need to figure exactly what it expects, but "Category" (method "mt.getCategoryList") is pretty easy to guess and is the one that I think finally breaks the conversation with a fault code of 1. Should also look into "mt.supportedTextFilters" method, which just throws an "unknown method" fault but doesn't end communications. We might get preliminary communication by simply fixing (or adding) the category method. XES February 04, 2014, at 05:25 PM

Oh, and for the record, I tried again with the old XMLRPC (rather than with the upgraded package) just to check and it also performs the same handshakes. One thing I will do is remove UserAuth. There will have to be a future update to add AuthUser name->password combo to the package. For now I want to restore basic admin access to XMLRPC for simple passworded sites. XES February 04, 2014, at 05:29 PM

API Notes

MetaWeblog API

From the text at http://xmlrpc.scripting.com/metaWeblogApi.html

The blogid, username, password and publish params are as in the Blogger API. newPost returns a string representation of the post id, again as defined by the Blogger API. The struct is where the juice is.

Page Struct notes

Page struct contents are the elements as in RSS 2.0:

• Minimal: title, link and description. For blogging tools that don't support titles and links, the "description" element holds what the Blogger API refers to as "content."
• For categories, pass an array of strings of names of categories that the post belongs to, named categories.
• In getPost, the returned value is a struct containing the same elements corresponding to the struct passed to newPost and editPost.

Note: unsupported methods and attributes

The following are completely unsupported in this PmWiki implementation:

• Namespaces
• Elements with attributes
• Enclosures (attachments)
• metaWeblog.newMediaObject
• Future functionality: category description, urls.
• flNotOnHomePage (boolean flag to not include post/page on home page of site)

Other Potential API Resources

• MovableType XML-RPC API spec -- hard-to-find document!!
• Supported in XMLRPC plug-in

Notes

firstname is the Movable Type username up to the first space character, and lastname is the username after the first space character.

metaWeblog.newPost Notes

the struct content can contain the following standard keys: title, for the title of the entry; description, for the body of the entry; and dateCreated, to set the created-on date of the entry. In addition, Movable Type's implementation allows you to pass in values for five other keys: int mt_allow_comments, the value for the allow_comments field; int mt_allow_pings, the value for the allow_pings field; str mt_convert_breaks, the value for the convert_breaks field; str mt_text_more, the value for the additional entry text; str mt_excerpt, the value for the excerpt field; str mt_keywords, the value for the keywords field; and array mt_tb_ping_urls, the list of TrackBack ping URLs for this entry. If specified, dateCreated should be in ISO.8601 format.

Page Struct Notes

the struct content can contain the following standard keys: title, for the title of the entry; description, for the body of the entry; and dateCreated, to set the created-on date of the entry. In addition, Movable Type's implementation allows you to pass in values for five other keys: int mt_allow_comments, the value for the allow_comments field; int mt_allow_pings, the value for the allow_pings field; str mt_convert_breaks, the value for the convert_breaks field; str mt_text_more, the value for the additional entry text; str mt_excerpt, the value for the excerpt field; str mt_keywords, the value for the keywords field; and array mt_tb_ping_urls, the list of TrackBack ping URLs for this entry. If specified, dateCreated should be in ISO.8601 format.

Notes

link and permaLink are both the URL pointing to the archived post.

Notes

dateCreated is in the timezone of the weblog blogid; link and permaLink are the URL pointing to the archived post

newMediaObject Notes: the struct file should contain two keys: base64 bits (the base64-encoded contents of the file) and str name (the name of the file). The type key (media type of the file) is currently ignored.

Note mostly to myself: if we create a more API-type structure, it may be possible to use 1 API to link to a variety of RPC protocols such as JSON-RPC. Didn't even know it was an option -- see ServePageByJSON and http://kodi.wiki/view/JSON-RPC_API. What I don't know is whether there are blogging clients of the quality listed on this page that work on a JSON back-end or not. XES September 21, 2017, at 04:45 PM