WAITING (next drafts release): HTML unescaping results from DokuWiki XML-RPC API

I want to load / save data from / to my DokuWiki using the XMLRPC scripting object. So far I’m able to request data from the wiki and load it into a draft, but the content always is HTML escaped. I can easily fix that by running the returned text through HTML.unescape(), but I can’t do that when sending the draft back to the server.
Something like <box>My content</box> will end up as &lt;box&gt;My content&lt;/box&gt; on the actual wiki page.

EDIT: Actually, the text looks like this: &lt;box>My content&lt;/box>. :face_with_raised_eyebrow: Only the opending brackets are escaped in DokuWiki. Here is my test page: http://www.helmholtz-it.de/testseite

Is this the expected behavior for the xmlrpc api or am I missing something? I would have thought, that the XMLRPC object would handle any escaping for me.

Here is the code and an example action:

function get_credentials() {
	const c =
		Credential
		.createWithHostUsernamePassword(
			'DokuWiki default',
			'Enter credentials for accessing your DokuWiki instance.'
		);
	c.authorize();

	return {
		username: c.getValue('username'),
		password: c.getValue('password'),
		host: c.getValue('host')
	}
}

function login() {
	const cred = get_credentials();
	const url = `${cred.host}/lib/exe/xmlrpc.php`;
	let response = XMLRPC.request(
		url,
		'dokuwiki.login',
		[cred.username, cred.password]
	);
	if (!response.success) {
		alert(response.error);
		context.fail();
		return false;
	} else {
		return response.params[0];
	}
}

function load_page(id) {
	const cred = get_credentials();
	const url = `${cred.host}/lib/exe/xmlrpc.php`;
	
	let response = XMLRPC.request(
		url,
		'wiki.getPage',
		[id]
	);
	if (response.success) {
		//draft.content = HTML.unescape(response.params[0]);
		draft.content = response.params[0];
		draft.update();
		retry = false;
	} else {
		alert(response.error);
		context.fail();
	}
}

function save_page(id) {
	const cred = get_credentials(id);
	const url = `${cred.host}/lib/exe/xmlrpc.php`;
	
	let response = XMLRPC.request(
	  url,
	  'wiki.putPage',
	  [id, draft.content, []]
	);
	if (!response.success) {
		alert(response.error);
		context.fail();
	}
}

login();
load_page('testseite');
// sace_page('testseite');

I hab a look at the actual data being send and it appears that the opening bracket is escaped twice: &amp;lt;box&gt;My Content in a box&amp;lt;/box&gt;.

are you an a mac?
Do you know pandoc?
That might do the trick…
You can convert from HTML to markdown and proceed forward from there.

The wikipages are already written in Markdown. But there are some tags that need to be written in HTML because they just don’t exist in Markdown or are required by DokuWiki in that format. Like the <box>-Tag in my example.

As far as i can tell it’s a bug in the XMLRPC api, but maybe I’m missing something.

Hard to debug from here.

Could you alert() or console.log()

And post a screenshot or even better the text of it ?

Sorry did not see that you provided a testpage, but what is the user and password?

I created a test user with access to the ‘testseite’:

Username: remote
Password: remote1234
Host: http://www.helmholtz-it.de

But for debugging it might be more useful to send the requests to something like requestbin.io to have a look at the actual data being send. I did that here: https://requestbin.io/17h5a291?inspect

Just set the host to https://requestbin.io/17h5a291 and call save_page(‘testseite’). The draft I used looked like this:

<box>My Content in a box</box>

The escaped content in the xml request should look like this:

&lt;box&gt;My Content in a box&lt;/box&gt;

But as you can see in requestbin, the data actually looks like this:


&amp;lt;box&gt;My Content in a box&amp;lt;/box&gt;

Somehow just the opening bracket < was escaped twice.

I reduced the example to just the XML-RPC request:

const url = 'https://requestbin.io/17h5a291';
	
XMLRPC.request(url,
	 'wiki.putPage',
	  ['<box>My Content in a box</box>']
	);

Still the same result. Seems to be a bug in the XMLRPC api?

Can confirm, this is a Drafts bug entifying the parameter string. Will be fixed in the next update.

1 Like

thanks @agiletortoise

we will check in the next beta.

Nice. Seems to be fixed in 22.1.3. beta :+1: