• Daniel

• in reply to: Ajax the ACF way
• August 26, 2016 at 12:46 am

I found my error. I was using the wp_ajax_acf hook. I should have been using the wp_ajax one.

• Daniel

• in reply to: Ajax the ACF way
• August 25, 2016 at 7:51 am

I was adding the hook inside the custom field class __construct:

class acf_field_my_custom_field extends acf_field {

//ajax hooks here

}

That’s in the acf-my_custom_field-v5 file.

I couldn’t get it to work there, so I added out side the class in the main plugin file, and it worked. However that creates another problem… I don’t have access to the data inside the class my_custom_field.

• Daniel

• in reply to: Ajax the ACF way
• August 25, 2016 at 6:51 am

I went the WP way , but I had to place the add_action(‘ajax_… hooks outside the main custom field class. I guess once the field loads, it’s too late to add the ajax action.

• Daniel

• in reply to: Ajax the ACF way
• August 25, 2016 at 6:09 am

I see, I thought that the input.js file, that comes with the custom field template, already had that access because of the other acf functions that are used inside that template.

• Daniel

• in reply to: global $post and acf/init hook
• August 9, 2016 at 4:05 am

Never mind, I was mistaken. I can access it using $_GET.

• Daniel

• in reply to: Tab Layout Reset
• August 4, 2016 at 12:41 am

1 year later and I didn’t even know this option was available. Thanks!

• Daniel

• in reply to: How to get/set repeaters field cloneindex?
• July 22, 2016 at 12:44 am

Problem fixed. I created a dummy field to capture the acfcloneindex and from their I can pass it to my js file.

• Daniel

• in reply to: How to get/set repeaters field cloneindex?
• July 21, 2016 at 7:36 am

Thanks. I think that will help me solve my issue. My custom field creates more field inputs via js, but the ids are not replaced because I am passing them using my own data attribute and the code is looking for the attribute ID.

• Daniel

• in reply to: How to get/set repeaters field cloneindex?
• July 21, 2016 at 6:49 am

No problem. Thanks for taking a look. I have also been digging through the js files. Trying to figure out how the value is passed.

• Daniel

• in reply to: How to get/set repeaters field cloneindex?
• July 21, 2016 at 6:28 am

Sorry… it’s acfcloneindex.

• Daniel

• in reply to: How to retrieve field type keys and default values?
• July 16, 2016 at 3:56 am

Totally missed that php comment. Thanks. That will save some headache later on.

• Daniel

• in reply to: How to retrieve field type keys and default values?
• July 16, 2016 at 3:39 am

Thanks. You bring up a interesting point.. .do the field keys need to start with field_? I didn’t see that as a requirement. And what about the field group key? Does it need to start with group_?

• Daniel

• in reply to: How to retrieve field type keys and default values?
• July 16, 2016 at 3:17 am

Sorry. I am pretty terrible at describing things… the key fields are generated on the fly but based on a bunch of other information, so they will be unique but the same every time.

Anyway, no worries, because I was trying to merge my arrays with the default acf array, but that’s is already done by ACF when adding a field.

• Daniel

• in reply to: How to retrieve field type keys and default values?
• July 16, 2016 at 2:50 am

I think we are talking about 2 different things, and it’s probably my fault. I’m working on a options page. All fields in the options page are created on the fly, so I wanted to get the default field keys per field type as defined in the plugin and then merge with the key/values I am using. I was try to access the class directly… but I failed to realize that the acf_add_local_field already does that for me.

• Daniel

• in reply to: How to retrieve field type keys and default values?
• July 16, 2016 at 2:28 am

get_field_object() expects the field to be saved. I am trying to retrieve the default values found in the field classes.

But I think I wont need that anymore, since the defaults are passed during field creation.

• Daniel

• in reply to: "Loading failed" on post_object field
• July 9, 2016 at 3:53 am

Thanks for the write up @hube2. Helps me understand a bit more how acf works.

• Daniel

• in reply to: "Loading failed" on post_object field
• July 8, 2016 at 8:15 am

One question while on this subject. I know that each group field needs a unique key, and the same goes for each field. However, is the group and/or field key associated to the actual value stored for a post? Or just the field name/slug?

I am looking at the postmeta table, and I can’t seem to find a relation between the field key and field value stored for a post.

I ask because I am wondering if I need to always use the same unique key for a group, if the group is created on the fly (registering with php)

• Daniel

• in reply to: "Loading failed" on post_object field
• July 8, 2016 at 1:46 am

I figured out my issue. I was printing to the browser console using a php function that echo a js console.log. That was causing the issue.

Thanks.

• Daniel

• in reply to: ACF as modules
• June 28, 2016 at 1:35 am

Thanks for the reply. I didn’t know I could register fields directly with PHP. That would be ideal. Thanks.

• Daniel

• in reply to: Different values for same field groups on different options pages?
• May 24, 2016 at 11:54 pm

Thanks Edd. I misunderstood what you said previously. I thought you meant giving the pages different slugs. Duplicating the fields using different slugs was my initial approach.

As a test, I modified the ACF code to include the page slug as part of the option_name, but that causes other issues down the road.

Thanks for taking a look.

• Daniel

• in reply to: Different values for same field groups on different options pages?
• May 24, 2016 at 12:14 am

This is weird, because I tried that. I gave all options pages unique slugs, but when the data is saved, it doesn’t create any relationship (that I can tell) between the option page and the field data. So the data shows up on every page. My initial thought was that the page slug would have been added to option_name. But option_name, in the options table, only contains options_name_of_the_field.

• Daniel

• in reply to: Different values for same field groups on different options pages?
• May 21, 2016 at 4:26 am

After taking a look at the code. I only see this being possible if I added the current page options slug to the option_name. That way each field would have a unique name according to it’s option page. However, that would also require me to update the get_options and get_field functions to look at the correct option values.

Does anyone see any other issues with changing the option_name value?

• Daniel

• in reply to: Get all field groups related to post
• February 11, 2016 at 4:24 am

Yeah. I just didn’t realize it was already doing it for me.

• Daniel

• in reply to: Get all field groups related to post
• February 11, 2016 at 4:03 am

John, thank you very much. That worked. I had already moved on and tried other approaches, like getting all field groups and then filtering them out by location rule. But this is a lot easier.

• Daniel

• in reply to: Get all field groups related to post
• February 11, 2016 at 3:28 am

This is pretty confusing… but it looks like “post object”, “post id” or “global $post” in the function’s description are expected to be an ACF Group Field ID, object, global… and NOT the post ID where the group is being used. So for example, not the home page ID.

“This function will take either a post object, post ID or even null (for global $post)”

And acf_get_field_groups() accepts an array of arguments, so passing $post_id/$post->ID won’t return anything. The default arguments indicate that’s also looking for all field_groups that have been published.

I can’t seem to find a function, that given a $post->ID will return all related field groups that are being used in that post.

My ultimate goal is to:

-> on page load, get’s id ($post->ID)
-> retrieve all field groups that have been used in this page
-> and then loop through each group, printing a different layout for each group.

I can do this easily right now using the “Flexible Content” field, because when I call get_fields, each layout has specific name, that I can check against.