Support

Account

Forum Replies Created

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

  • 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.

  • 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.

  • 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.

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

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

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

  • 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.

  • 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.

  • Sorry… it’s acfcloneindex.

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

  • 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_?

  • 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.

  • 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.

  • 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.

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

  • 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)

  • 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.

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

  • 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.

  • 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.

  • 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?

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

  • 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.

  • 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.

Viewing 25 posts - 1 through 25 (of 46 total)

We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Cookie Policy. If you continue to use this site, you consent to our use of cookies.