5/19 build…

How come some users have the problem and some don’t? Is it because of the webhost we are using or what?

I’ve noticed that I can ping someplaces and not others. Same with trackback. I thought it was fixed, but maybe not.

class-xmlrpc.php line 615 has bug.
– if function_exists(‘get_settings’){
+ if (function_exists(‘get_settings’)) {
and I found other problem.
if wp send xmlrpc response in wp encoding, then almost all xmlrpc clients in CJK can’t handle the response.
because, the clients in CJK countries always send and expects utf-8 encoding.and the users not necessarily uses utf-8 encoding in their sites.(in one country three or more encoding used.)
wp xmlrpc server need to convert the request encoding(utf-8) to
site encoding(something used in the wordpress, charset).
same problem happens in trackbacks, of course.

Whoops, my bad for the if error. Fixed now.
As for encodings, the situation is rather confusing.
The responses we used to send were obviously invalid XML because they were not announcing any charset (default charset in XML in UTF8) yet they were sending stuff in the blog’s charset.
Announcing the charset makes the the responses valid XML, which any sane library/client shouldn’t have any problem with.
Can you give more details about what exactly are the errors?

(at first,my english skill is poor.)
in japan, we use multiple charset.
so like this.
client may use shift_jis encoding.
but maybe blog uses utf-8 encoding.
so the strings are not displayed properly.
then shitf_jis to utf-8 conversin needed.
so japanese xmlrpc client only supports utf-8 encoding.
of cause, ideally, blog client should detect the encoding of response,and convert it to the native encoding of the client.
but if then, problem remain. still, it can be differnt between blog charset and client charset.
so we do like this.
client (some encoding to utf-8)==>>utf-8===>>
===>>utf-8===>>server(utf-8 to some blog encoding).
and retuen.
client(utf8 to native charset)<<===utf-8 <<==server(some charset to utf-8)

One more… My blogroll is not updating even though my prefs are set to do so.

Have you chmoded links-update-cache.xml to 666? I believe the documentation says to do this to link-update-cache.xml, but the filename is wrong.

Don’t you also need to add this line to index.php?:
include_once(ABSPATH.WPINC.'/links-update-xml.php');
<rb>

atmasphere, have you updated your permalink’s mod_rewrite rules?
I had some issues with trackback and pingbacks on my CVS install, until I just deleted old mod_rewrite rules and re-generated them.

Just checked and made sure it is… guess I have to wait now and see if the file gets updated.
Thanks!

I’d say enough time has passed… no change

Thanks for clarifying the matter with that japanese blog client and UTF8.
We may make our xmlrpc responses output only UTF8, however the problem is that there is no way on most webhosts to switch from anything other than ISO-8859-1 to UTF8 and vice-versa. So for CJK charsets there may still be issues.
In the foreseeable future, I advise that CJK users just use UTF8 as their blog’s charset…

thanks michel.
example modfication.
https://www.kowa.org/modules/xfmod/forgecvs/cvsbrowse.php/wordpress/xmlrpc.php.diff?r1=1.1&r2=1.1.2.1
(by nobnob.it is not me.)
and in functions.php

function mb_conv($str,$to,$from)
{
if (function_exists(‘mb_convert_encoding’)) {
$retstr = mb_convert_encoding($str,$to,$from);
} else {
$retstr = $str;
}
return $retstr;
}