Unable to get ecto to work with Metaweblog API and XML RPC

[electroteque]

Ive just had a look at getting ecto to connect using the MT API however, it will only display two of the posts of r some reason. I setup a XMLRPC client to see what the response was and yes only 2 posts are being recieved, what could be the problem ? Ecto calls the getRecentPosts method and within that i can see this, is there areason to get all entries and then do yet another sql query to fetch a single entry i dont get it , what a double up ??? It weould be nice if the db functions would log stuff , has anyone considering using something like PEAR's DB DataObjects or MDB2 or even PDO lol.


$entries = serendipity_fetchEntries('', false, $numposts, true);
$xml_entries_vals = array();

foreach ((array)$entries as $entry) {
$entry = serendipity_fetchEntry('id', $entry['id'], true, 'true');
serendipity_plugin_api::hook_event('xmlrpc_fetchEntry', $entry);
if ($entry['id']) {
$xml_entries_vals[] = new XML_RPC_Value(
array(
'dateCreated' => new XML_RPC_Value(XML_RPC_iso8601_encode($entry['timestamp']), 'dateTime.iso8601'),
'postid' => new XML_RPC_Value($entry['id'], 'string'),
'userid' => new XML_RPC_Value($entry['authorid'], 'string'),
'description' => new XML_RPC_Value($entry['body'], 'string'),
'mt_excerpt' => new XML_RPC_Value('', 'string'),
'mt_allow_comments' => new XML_RPC_Value($entry['allow_comments'] ? 1 : 0, 'int'),
'mt_text_more' => new XML_RPC_Value($entry['extended'], 'string' ),
'mt_allow_pings' => new XML_RPC_Value(1, 'int'),
'mt_convert_breaks' => new XML_RPC_Value('', 'string'),
'mt_keywords' => new XML_RPC_Value(isset($entry['mt_keywords']) ? $entry['mt_keywords']:'', 'string'),
'title' => new XML_RPC_Value($entry['title'],'string'),
'permalink' => new XML_RPC_Value(serendipity_archiveURL($entry['id'], $entry['title'], 'serendipityHTTPPath', true, array('timestamp' => $entry['timestamp'])), 'string'),
'link' => new XML_RPC_Value(serendipity_archiveURL($entry['id'], $entry['title'], 'serendipityHTTPPath', true, array('timestamp' => $entry['timestamp'])), 'string')
),
'struct');
}
}

[garvinhicking]

You can easily add logging to your include/db/mysql.inc.php file. Just edit the serendipity_db_query and add

Code: Select all

$fp = fopen('debug.log', 'a');
fwrite($fp, $query);
fclose($fp);

within the function. You could even create your own DB layer "mysql_debug" and choose that whenever you need debugging.

The XMLRPC APIs often require first fetching several rows, and then a specific row.

Regards,
Garvin

[electroteque]

Yes, i dont want to be rude here, but i cant see why every product has to make their own DB Ab layer and not use a standardised one, it just makes life hard, as its quite obvious this RPC is borked and i need to fix it to help u fix it lol.

There seems to be alot of PEAR packages used so cant see why none of the DB ones were used, i use them alot and never have issues with performance. What are your thoughts here, i could build a driver to use some of the packages ?

[garvinhicking]

It's very simple: Available DB layers like PEAR are just too heavyweight for a blog application. It would perform BAD in our specialised environment, trust me. There is no reason to enforce a DB object with child objects, when we just need simple result sets. I had a quick try; implementing PEAR-DB on top of our system would be no problem. It performed 9 times (!) slower than our current system.

Actually, RPC works in the clients I've tested in the past on my system... But I agree, RPC is a part of Serendipity which is not absolutely actively maintained. Which is also a reason why XMLRPC has become a plugin instead of a part of the core. That is because I personally don't like or use XML-RPC clients. Maybe if you want to contribute patches, I will gladly implement them.

Regards,
Garvin

[electroteque]

I use the MDB2 package on a high traffic server no worries. I have found some of the sql in the blog quite slow actually, like using LIKE to search for an id ???? Here is the sql generated, its quite odd i dont know whats going on , i think some plugins i installed have wrecked the sql maybe

SELECT
mr.read_date,
e.id,
e.title,
e.timestamp,
e.comments,
e.exflag,
e.authorid,
e.trackbacks,
e.isdraft,
e.allow_comments,
e.last_modified,

a.realname AS author,
a.email


FROM
serendipity_entries AS e
LEFT JOIN serendipity_authors a
ON e.authorid = a.authorid
LEFT JOIN serendipity_entrycat ec
ON e.id = ec.entryid
LEFT JOIN serendipity_category c
ON ec.categoryid = c.categoryid
LEFT OUTER JOIN serendipity_markread
AS mr
ON (mr.entryid = e.id AND mr.visitor = '063abfef24e8685ca06f68f1398e838f')
LEFT JOIN serendipity_authorgroups AS acl_a
ON acl_a.authorid = 2
LEFT JOIN serendipity_access AS acl_acc
ON ( acl_acc.artifact_mode = 'read'
AND acl_acc.artifact_type = 'category'
AND acl_acc.artifact_id = c.categoryid
)
WHERE ( c.category_left BETWEEN 19195 AND 19196) AND e.timestamp <= 1138200874 AND (
c.categoryid IS NULL
OR ( acl_acc.groupid = acl_a.groupid OR acl_acc.groupid = 0)
OR ( acl_acc.artifact_id IS NULL

)
)
GROUP BY e.id
ORDER BY timestamp DESC
LIMIT 50

[garvinhicking]

Where do you see that "LIKE" to search for an id? At least it's not in the query you posted. If there were some place like it, it would be a place to fix the SQL query, I sure agree to that.

Well, as soon as you use an object to handle queries, it gets slower than just using functions. I see no real advantage of using PEAR-DB, because we don't really need it in the project. Debugging is already quite easy, IMHO.

I understand your concern, and usually I am all for using things that have been invented. But the s9y API does all that is required, nothing more and nothing less. It does some things that a MDB2 or PDB wouldn't be able to, and then we'd need to extend an object which is also overhead.

The overhead might be smaller or larger depending on the DB-layer, but it will be an overhead compared to the current way always.

What happens with the SQL query you pasted? Does it give you an error?

Regards,
Garvin

[electroteque]

No error but it only shows 3 entries when there are tonnes to load into the client. I dont know where mr.read_date is coming from !

Im gonna look into a resitifed or Atom alternative to RPC for Ecto as it handles the Atom API, it looks cleaner. RPC still is not working properly here.

[garvinhicking]

Ah! That is a good hinter indeed! It seems you have installed the serendipity_event_markread plugin! That one joins on a table to see which entries have already been read by an author.

You might want to uninstall some extra event plugins to check the RPC posting, because plugins can interfer with each other.

Actually, serendipity does not support ATOM Posting yet. However, if you'd get an implementation for that, I'd happily include it!

RPC itself does work, but I guess in your case some plugin is the cause of your problems.

Regards,
Garvin

[Guest]

Im looking into the implimentation of Atom atm. Ecto supports the Blogger Atom API here ,


http://code.blogspot.com/archives/atom-docs.html

The spec is here

http://code.blogspot.com/archives/atom-docs.html

I like it alot, especially for this kind of implimentation, the only thing i find wrong here is features like categories etc, i cant see how they can carry through in a post. Ive already removed that plugin btw but its still there.

[Guest]

I worked out where the problem is, noticed the filter on the category, i have the start page category plugin, its kinda needy so i can choose with categoyr goes on the frontpage. Is there a workaround ?

[garvinhicking]

Ah, that's good! Great you figured it out...I must admit I didn't notice that category filter on my own.

Yes, you can bypass it pretty easily. Within the serendipity_event_xmlrpc.php, add those lines:

Code: Select all

                case 'frontend_xmlrpc':
                    // Those variables should not be set by other plugins!
                    unset($serendipity['GET']['category']);
                    unset($serendipity['GET']['hide_category']);

                    if (!class_exists('XML_RPC_Base')) {
                        require_once dirname(__FILE__) . '/PEAR/XML/RPC.php';
                    }

Note the two unset() calls, that will unset the variables set by the startcat plugin.

Regards,
Garvin

[Guest]

Its loaded finally, taking out that plugin, but the categories still dont show up :\

[garvinhicking]

Did you edit your "serendipity_xmlrpc.inc.php" file and set the $debug variable to true? Then it will log each RPC request into a file, and you can see if there's maybe a call to an API function that is not implemented?

Regards,
Garvin

[Guest]

forgot to add what ecto says

Method "metaWeblog.getCategories" produced a server error: "Unknown method".

[garvinhicking]

I guess then we didn't implement that method yet. Did you try to use the blogger API? One of them should be complete, but I can't remember which one, as I don't really use it.

Well, we could really need a helping hand for that plugin.

I suppose adding the getCategories method for metaweblog would also not be too hard. You don't happen to have a spec at hand, do you?

Regards,
Garvin