Category: XML RPC

Tutos uses this one:
http://php-pdb.sourceforge.net/

http://prdownloads.sourceforge.net/tutos/palm-1.2.20050306.zip?download

Yahoo Weather (and, I assume other feeds) rss feed dumps neat html into the description field of the first item rather than the title. I've modified function.rss.php to accomodate this and allow users to continue to use the regular module creation interface. Basically, I added a new parameter "desc" such that if you use {rss id=1 max=1 desc=1} the resulting output will use the description field instead of the title field. Skipped items will still be skipped.

Sorry, but I'm very new to Tikiwiki and may not conform to regular documentation standards...please correct me as neceesary.

I have posted several items to a blog through xmlrpc.php, using bloGTK 1.0 (GNU/Linux), and they are posted in Tiki (except for the title, which I already reported another bug at this tracker).

I can select afterwards any of the posted items, and edit from bloGTK. When I post the edition,I get the message (in local) that the post have been successfully updated, but then at Tiki, the blog post dissapears from the list of posts.

Using "Blogger" Blogging system, in BloGTK configuration.

When Posting to a blog through the xmlrpc.php, I can connect to the server and post all content to the chosen blog, but I can't add title text. From blogtk (linux), I can't even see the title field in white (fillable) but in grey (unfillable, non-available). Si can't even write the title text from blogtk.

From gnome-blog-poster, I can insert text in the local form, but after I submit the post, the content is saved correctly but not the title content.

I have several tikiwikis (v 3.0 beta 4) on the same domain. Both behind the same .htaccess protected directory. The goal was to setup a working instance of InterTiki between these two Tiki's.

By way of example
* Apache .htaccess limit: http://www.mydomain.com/p/
* Master e.g. http://www.mydomain.com/p/master
* Client e.g. http://www.mydomain.com/p/client

__BACKGROUND__
A few setup issues have been noted (these details have now been added to the InterTiki documentation). Most notably is correctly specifying the location of "/remote.php" for the above case. For our above example to following is req'd:
* host: http://www.mydomain.com
* path: /p/master/remote.php

On the master, I have successfully made contact using either the IP shown in the Apache logs, or by simply using "127.0.0.1" in this case.

Likewise (also added to InterTiki docs) there was some oddity related to order of events with how the server info was being plugged into MySQL tiki_preferences interlist table. I have not properly tracked this down so will not go into it further at this time.

Also of note (for another bug or support request) is that I am unable to get InterTiki on the master to log out anything.

__BUG/FEATURE REQUEST__
''Note: InterTiki operates as designed and is simply unable to get behind an Apache Basic Auth wall. However, hard-coding in setCredentials line for the XML_RPC_Client should work in this case but does not.''

After getting setup dialed in like above, the client received the following message:
''XMLRPC Error: 5 - Didn't receive 200 OK from remote server. (HTTP/1.1 401 Authorization Required)''

Some digging into /lib/userlib.php finds the calls for setting up the XML_RPC_Client at lines (around) 228, 2812, 2831, 2860 and 2905. Looking into the XML_RPC_Client class in /lib/pear/xml/rpc.php shows that there exists a setCredentials($username, $password) method. The setCredentials method exists to allow for RPC calls to get through Basic Apache Authentication.

__Possible Bug__
I went ahead and modified the clients (and eventually the master's) /lib/userlib.php in the above locations with a simple addition of:
$client->setCredentials("myApacheUsername", "myPassword");

This time, when logging in from the client, the response was:
''XMLRPC Error: 5 - Didn't receive 200 OK from remote server. (HTTP/1.1 302 Moved Temporarily)''

And with that I am stuck. It seems like (as a workaround hack for the time being) the ability is there in the XML_RPC_Client methods to get through an Apache Basic Auth, but the return code is weird at best.

__Possible Actions__
#Ignore -- Explicity note that InterTiki masters/clients must not exist behind Basic Auth walls.
#Investigate why a hacked userlib.php returns a 302 code and determine if this is as designed or a bug.
#Possibly add a basic username/password entry field in the client administration page for driving the setCredentials method.

Contributors

Login works fine at tw.o, dev.tw.o and doc.tw.o though...

The error message on both sites :

XMLRPC Error: 5 - Didn't receive 200 OK from remote server. (HTTP/1.0 500 Internal Server Error)

XML files are cool for data interchange.

For example, you can create an xml file to feed a Flash animation. However, you still need to update that XML file via FTP. What if you could edit a wiki page (with permissions, history, etc) and have the Flash animation get the data from it as if it was xml?

Or maybe a button on a wiki page "save to .xml", which would save on the filesystem WikiPageName.xml? (where the Flash would know to look for it)

Related idea:
* {wish id=467}
* {wish id=3103}


Louis-Philippe Huberdeau --will look into-- used [http://www.yaml.org/|YAML] --to see if this could be useful-- and it is very useful for the ((Profile Manager))

The Export feature is nice, but it would be nice to export/save wiki pages with html formatting intact. A way to edit offline then sync changes would be even better, but for now, I'd settle for a way to just view pages offline.

ML: You can ((doc:mail-in)) and ((doc:watch)) (mail-out), but no true sync

XML-RPC? IMAP?

http://www.socialtext.net/help-en/index.cgi?working_offline_with_unplugged

See: ((Offline))

Would be really nice to combine with an encrypted password manager for offline storage -> ((User Encryption))

- Go to Wiki -> Send Pages
(You'll have to activate "XMLRPC" and "Communication Send/Receive Object" in Admin-> Features for that).

- Enter the remote host information
- select a wiki-page and click "add page"
- see that the remote host information is gone

Bloglib uses fopen to get data from a url. This should be avoided due to security and environments where the tiki server is secured (firewall/proxy), where fopen will not work. Affected function: function send_trackbacks($id, $trackbacks)

I noticed today a bunch of trackback spam in my Tiki-powered blog.

According to Wikipedia, "Many blogs have stopped using trackbacks because dealing with spam became too burdensome."
http://en.wikipedia.org/wiki/Trackback

If you get trackback spam in Tiki, here is how to clean:

Using phpmyadmin, go to the table: tiki_blog_posts

And find the colums "trackbacks_to" and "trackbacks_from". They should contain:

a:0:{}

instead of the spam.


Now, a more permanent solution to avoiding Trackback spam would be nice. Checking how other blogging software does it should provide some tips.

Some ideas:
0- A way to turn it off (this exists in more recent version of Tiki 1.9.x, see "Trackbacks Pings" in the admin panel)
1- Easier mass deletion
2- Email notification to blog owner
3- Using an online service to check for spam.

I have enabled blogging and xmlrpc
and am attempting to use w.bloggar, raven or qumana to post to the blog.

w.bloggar is able to access prior posts only intermittently, though it does work usually on the second or third try. It can post, and use the more text feature if the more text is changed to ...page..., but modifying an existing post seems to delete the post or make it invisible.

raven can post but the title is missing. revising post also "deletes" it or makes it inaccessible via web. it seems ot be able to read prior posts.

qumana tells me that "this operation is ont supported by the blog" when trying to read prior posts. it posts, but title is missing.

No XML RPC interface for Wiki

If I try to contact tikiwiki either with w.blogger 4.0 or 3.3 or with Ecto to post to a blog it don't work. It is as soon as when I setup the account the message ist that the XML returned from xmlrpc.php is invalid ...

So I think this is a major backdraft for those who are pro in creating content - I think there is a demand for using tools like those.