Repeater with XML-RPC

• amsross

• October 4, 2013 at 2:48 am

I saw this post: http://support.advancedcustomfields.com/forums/topic/using-acf-with-the-xml-rpc-interface/

I’m curious if this is the case in general or with his specific usage?

When sending a wp.newPost request, I am able to tell ACF Repeater how many fields to create (this is a File repeater field), but the values are empty. In my case I have a repeater field called pdf_xls with child fields file and type. I can send pdf_xls as a custom_fields value to determine the count of the rows, but sending pdf_xls_0_file (which is the format the response contains when using wp.getPost) or pdf_xls_0_type where 0 is the row number does not insert any values into the fields.

Any suggestions or am I chasing my own tail here?

• Elliot

• October 4, 2013 at 2:11 pm

Hi @amsross

I am yet to look at ACF and the XML rpc interface, however, I do believe it is possible to save the repeater field data.

Take a look at the repeater field docs page. On there you will see an example of how the data is stored. I think you could post across all the sub field / row data as separate custom field values in the correct format (see repeater field docs) and the repeater field should work with the data.

Give it a go, and let me know how you get on.

Thanks
E

• amsross

• October 4, 2013 at 11:48 pm

Hey @elliot, thanks for the quick response!

As it happens, I was nesting my file and type field values an extra level before generating the XML call so I was sending an array like this:

array(
   'pdf_xls' => 1,
   array(
      'pdf_xls_0_file' => 1111,
   ),
   array(
      'pdf_xls_0_type' => 'pdf',
   ),
);

When it should have been more like this:

array(
   'pdf_xls' => 1,
   'pdf_xls_0_file' => 1111,
   'pdf_xls_0_type' => 'pdf',
);

• amsross

• October 5, 2013 at 12:33 am

Hey @elliot, I do still seem to have one issue here.

Although I am now able to send up all of this data via XML-RPC and receive it back as I expect it (via wp.getPost), the data does not seem to be readable in the theme.

If I execute something like this:

if (get_field('pdf_xls', $report->ID)) {
	while (has_sub_field('pdf_xls', $report->ID)) {
		$file = get_sub_field('file');
		$type = get_sub_field('type');
		?><a target="_blank" href="<?=$file['url']?>"><?php the_sub_field('type'); ?></a> <?php
	}
}

Then the output is <a target="_blank" href=""></a>, which seems to indicate that the get_sub_field() values are empty. If, however, I got into the post to edit it and hit UPDATE POST(without making any other modifications), then the theme code returns the values as expected.

Am I missing something that may rationalize the data for the WP database?

Unfortunately I don’t have direct access to the DB for this project, but I’m trying to set up an example so I can see what changes there may be before vs after the additional UPDATE.

I’ll post any findings.

• amsross

• October 5, 2013 at 12:41 am

Just a quick update to my last question/issue.

I got into the DB and looked at wp_postmeta. In there I see several new fields created after manually updating the post from within the dashboard. These are _pdf_xls_0_file, _pdf_xls, and _pdf_xls_0_type. In this instance, they have values of field_5244a55cc2d61, field_51ffa871373aa, and field_5244a63d620cd respectively. Unfortunately, I don’t think I can correctly provide this information via XML-RPC.

Do you have any suggestions on this @elliot?

EDIT: Obviously, this works too because I can get the post_meta, but still…

for ($i=0, $x=get_post_meta($report->ID, 'pdf_xls', true); $i < $x; $i++) {
	$file = wp_get_attachment_url(get_post_meta($report->ID, "pdf_xls_{$i}_file", true));
	$type = get_post_meta($report->ID, "pdf_xls_{$i}_type", true);
	?><a target="_blank" href="<?=$file?>"><?=$type?></a> <?php
}

• Elliot

• October 7, 2013 at 4:04 pm

Hi @amsross

ACF requires 2 rows of data to be saved for each value.
The first row is the actual value, the other is a reference to the field key.

This reference is how ACF knows what field type / options are associated to the value, and then it will be able to return the data formatted correctly.

Perhaps you can post over the data using the field_key instead of the field_name?
This is the best way to save data with the update_field function.

Hope that helps.

Thanks
E