Support

Account

Forum Replies Created

  • You know what?

    I was just creating a new field group and realized you don’t need to build any of this. There is already a “Page Type” selection with “Top Level/Parent/Child” choices.

    Don’t ask me what I was thinking, but I assumed that since you were asking about this that it did not already exist.

  • I imagine that you’ll need to do several things. The first three functions that set up the rules when creating a field group in ACF should be pretty straight forward. Actually I don’t think you need to use acf_location_rules_operator() because I would use the standard == != and use “Top Level Post” or “Child Post” for the choices.

    Your custom rules also do not need to make the post_type selection. When creating your group you’d just use two rules

    • Post Type == your custom post type
    • Post Level == top level or child

    That leaves the function for testing the parent/child rule. Take a look at this for information on testing to see if a page is a child page: http://codex.wordpress.org/Conditional_Tags#A_PAGE_Page

  • Then you have me stumped. The only time I’ve ever had a problem creating more fields is when I exceed max_input_vars.

    There are a couple other php settings you can try increasing:
    post_max_size
    max_input_nesting_level

  • There is a document here about adding custom location rules: http://www.advancedcustomfields.com/resources/tutorials/custom-location-rules/

    I don’t have an example of adding a custom location rule for a post parent/child rule, but I do have an example of adding a taxonomy parent/child rule.

    This is all built into a class for a custom theme I built for a client, hopefully it helps you get an idea what you need to do.

    private function __construct() {
      add_filter('acf/location/rule_types', array($this, 'acf_location_rules_types'));
      add_filter('acf/location/rule_operators', array($this, 'acf_location_rules_operators'));
      add_filter('acf/location/rule_values/taxonomy_depth', array($this, 'acf_location_rules_values_taxonomy_depth'));
      add_filter('acf/location/rule_match/taxonomy_depth', array($this, 'acf_location_rules_match_taxonomy_depth'), 10, 3);
    }
        
    public function acf_location_rules_types($choices) {
      $choices['Other']['taxonomy_depth'] = 'Taxonomy Depth';
      return $choices;
    }
    
    public function acf_location_rules_operators($choices) {
      //BY DEFAULT WE HAVE == AND !=
      $choices['<'] = 'is less than';
      $choices['>'] = 'is greater than';
      return $choices;
    }
    
    public function acf_location_rules_values_taxonomy_depth($choices) {
      for ($i=0; $i<6; $i++) {
       $choices[$i] = $i;
      }
      return $choices;
    }
    
    public function acf_location_rules_match_taxonomy_depth($match, $rule, $options) {
      $depth = intval($rule['value']);
      if (isset($_GET['taxonomy']) && isset($_GET['tag_ID'])) {
        $term_depth = count(get_ancestors($_GET['tag_ID'], $_GET['taxonomy']));
      }
      if($rule['operator'] == '==') {
        $match = ($depth == $term_depth);
      } elseif($rule['operator'] == '!=') {
        $match = ($depth == $term_depth);
      } elseif($rule['operator'] == '<') {
        $match = ($term_depth < $depth);
      } elseif($rule['operator'] == '>') {
        $match = ($term_depth > $depth);
      }
      return $match;
    }
  • Your php setting for max_input_vars is 3000

    Look at the field group you’re creating. Each field you’re creating has many inputs there may even be a bunch of hidden inputs. If you add them all up they are most probably near your 3000 limit.

    When you submit the page to save your fields, if there are more than 3000, php simply throws away the excess, so they are not submitted to the script that needs to save your field group.

    Does your host allow you to increase that setting? I would suggest upping it to 5000 see what happens. If your host does not allow you do change that php setting then you’ll need to figure out a different way to accomplish what you want to do using less fields.

  • I find that extremely interesting. For example, this is a field I created for a plugin for ACF4

    
    array('key' => '_acf_key_acfop_menu',
          'label' => 'Menu Text',
          'name' => '_acfop_menu',
          'type' => 'text',
          'instructions' => 'Will default to title if left blank.',
          'default_value' => '',
          'placeholder' => '',
          'prepend' => '',
          'append' => '',
          'formatting' => 'none',
          'maxlength' => '')
    

    I was thinking to myself… “It would be nice if all those fields didn’t appear in the ‘Custom Fields’ drop down in WP”… so I tried changing them to start with an underscore. When that worked I just started changing the “key” value to whatever I wanted and that worked.

    If this is a bug in ACF4 I would ask that it’s a bug you ignore. πŸ˜›

    ~JH

  • You are most likely running into a problem with your php installation rather than an ACF bug. PHP setting max_input_vars usually has a default value of 1000.

  • In order to have access to WP functions in ajax you need to use it the way that WP considers “proper”. Your need to make all ajax requests through admin-ajax.php.

    The best information on using ajax in WP can be found here: http://codex.wordpress.org/AJAX_in_Plugins

    All the information about functions and add_actions and so forth can be used in your functions.php file as well as it can be used in a plugin.

  • the url in the link at the top of this page is wrong, it points to http://www.advancedcustomfields.com/store/account/. the actual url is http://www.advancedcustomfields.com/my-account/. If you click the account link on the 404 page you’ll get there.

  • You need to alter your php ini setting max_input_vars. You’re reaching the maximum number of input fields allowed on your server.

  • The only thing I could see you adding is limiting it to the Grandparent at the most:

    
    if ( 0 == $post->post_parent ) {
        the_title();
    } else {
        $parents = get_post_ancestors( $post->ID );
        $parents = array_slice($parents, 0, 2);
        echo apply_filters( "the_title", get_the_title( end ( $parents ) ) );
    }
    

    I think that should give you either the parent or the grandparent, but not further back. If you want to limit it only to the grandparent then you’d need to make sure that the slice has a count of at least 2.

  • Thanks E for the quick response. I was wondering how I was going to alter some of the fields according to http://www.advancedcustomfields.com/resources/updates/upgrading-v4-v5/ and have compatibility with both 4 & 5. This answers that question as well.

  • I don’t know the solution. Figured I’d post something because I recently looked at doing the same thing.

    I was building my own code to do the importing from a CSV, the main reason for this is that most of the plugins available do not really understand how to import data for ACF (even if they say they do) especially for things like repeater fields. Or for that matter importing attachments.

    Anyway, I dug through everything looking for something that got stored in the DB to tell WP that there was a gallery there. I went as far as going through the steps of creating a WP gallery in a post, exporting the DB at every step and comparing the exports for any differences and doing the same thing for my imported data. I could find no reason for the gallery shortcode to not be processed properly from my import.

    No matter what I did I found that the only way to get WP to recognize the gallery was to open and save every post. Not a very good solution for the client that was importing 800+ products all with a gallery.

    I finally gave up, but I’d also really like to understand what I’m missing to get this done because I’m sure I’ll revisit this in the future. I don’t think this is really an ACF issue though, I’m sure it’s something to do with WP and some bit of data I’m missing somewhere, somehow.

    There is one thing that I did not try now that I think about it. For every field you create ACF creates 2 fields in the postmeta table when you add values to a post. the first is the field name you created, for example “my_gallery_field”. The second is a has a key of “_my_gallery_field” and this one’s value is the ACF “key” value for your field. I know that for repeater fields that all fields, including the ACF key references need to be inserted into the database to make them work. I will give this a shot the next time I’m working on my import script. Could be a while before I get to it though. But maybe something you can try.

  • As far as the fields with names that are “field_bunch of numbers”. Maybe in a future release if you can have the “key” values for fields start with and underscore (_), or maybe have a setting that allows us to set that the key values should be hidden from WP by starting with an underscore, that might help.

    A way to delete unused fields would be nice though.

  • “…I don’t want to create the field/group of fields inside the admin of a site and then export the code and copy/paste the piece of code in my plugin…”

    I think that is basically what you need to do. I’ve created a few plugins that use ACF fields. You use the function register_field_group() …

    Which I’m suddenly not finding any documentation on, I’m sure it used to be around here somewhere…

    you call this function on the action hook “acf/register_fields”… which I’m also not finding any documentation on.

    You could type out the array for the field group by hand, but it would be much easier to use ACF to create the fields and export the PHP code to copy into your plugin.

    But in the documentation that I can’t find it outlined the steps.

    
    add_action('acf/register_fields', 'my_register_fields_function');
    function my_register_fields_function() {
      if (function_exists('register_field_group')) {
        // use the field group you export from ACF for $my_field_group
        $my_field_group = array();
        register_field_group($my_field_group);
      }
    }
    
  • I think you’re going to need to check the value of your field that sets the condition for the field you want to display, and then write the PHP to either show or not show the conditional field. This is what I do when building templates.

    
    if (get_field('condition_field')) {
      the_field('conditional_field');
    }
    

    Not sure how you can translate that with the array returned by get_fields(). The test is going to need to be build into the loop you’re using to show your values, probably defeating the purpose using of get_field() since I’m assuming it is because you have a lot of fields to display.

    I don’t use this function because 99% of my field names begin with “_” (underscore) which makes the function pretty useless for me.

    You’re suggestion of deleting the value if the condition is false I think would be difficult. I think the only way to do this would be to find and delete all value before inserting the new values. My suggestion here would be to use the hook “acf/save_post” and in your hooked function use the WP function “delete_post_meta()” to delete all the meta values you want to have cleared. You may also need to scrub through the $_POST array to remove any values that should not be set. Really, it would be easier to use my first suggestion and do a test when displaying them then to do all of the work involved with clearing values before the save.

    I don’t think this is something that ACF should do by default because everyone may not want this to happen. For example, having the values saved and not cleared makes it easy for users to switch back and forth between 2 options without needing to reenter any data. My clients would find that quite annoying.

    I don’t think the JavaScript used in the admin/forms for showing and hiding conditional fields will work without the form or in templates, you may need to write your own JS to do this.

  • I agree, this is already available for radio type fields, it would be nice to have this ability with select fileds. Adding it to checkbox fields would also be nice, though I think that would be a bit more complicated because they may want to add more than one value at a time.

    Generally when I want this I use the radio field figuring that eventually this will be added to select and I can easily transition, I hope. πŸ™‚

  • You can either use the normal ACF functions, you just need to make sure you access them after all the plugins are loaded or depending on the type of field your using you can use the standard WP get_options() https://codex.wordpress.org/Function_Reference/get_option

    Values set on options pages are stored in you options table. The formatting of the value will depend on the field type. If you have things like repeater fields then using get_option could be a bit complicated.

    I don’t include ACF premium plugin in my own plugin, instead I state that they are required. It saves me the hassle of needing to redistribute them or update my plugins when they’re updated. It’s a personal choice, but I include the fact that these are required in the plugin description and leave it up to the user to get the premium add-ons themselves. Most of my plugins are not available from the WP repository because of this, in fact, many of them are not publicly available at all.

  • I’m thinking it was ok for me to do this because I do not include the Options Page addon. This plugin requires you to already have that, it simply won’t work if you don’t have it installed.

    Let me know if I’m wrong though.

  • I’ve put it up on GitHub https://github.com/Hube2/Advanced-Custom-Fields-Options-Page-Adder

    It’s really a pretty simple plugin, but for those that don’t want to muck around in code, or don’t know how…

  • get_the_ID() can only be used inside the loop, see the WP Codex

    Using this function for the <body> tag would usually be outside the loop, so there is no telling what value is actually being returned.

    When you’re assigning classes you’ll need to get the post id using some other method.

    I’d probably use is_single() and/or possibly get_queried_object()

  • It has to be added to the page where the html link is generated. May not be possible and we’d have to see where the link is generated. Not really an ACF question… but I have a better solution than putting onclick events in your code.

    Set up Google Tag Manager on the site. Once you’ve removed your standard GA code and added the Google Tag Manager code you can set up GA and add events to just about anything on the site without mucking about in the code.

  • Does each user have their own options page? Or that is what you’re looking for, so that each person can create their own values for all the options?

    In order to have all those custom field names you’d have to create them dynamically in the first place. First you need to export the field group from ACF and then make modification to it.

    So, first you’d need to generate all the field groups dynamically based on the logged in user.

    
    <?php 
     
     $username = 'user_1'; // whatever code you use to get the user name
     
     if(function_exists('register_field_group')) {
      $field_group = array(
       'id' => 'acf_adwords',
       'title' => 'Adwords',
       'fields' => array(
        array(
         'key' => '_key_adwords_cost_for_'.$username,
         'label' => 'Adwords Cost For '.$username,
         'name' => 'adwords_cost_for_'.$username,
         'type' => 'text',
         'default_value' => '',
         'placeholder' => '',
         'prepend' => '',
         'append' => '',
         'formatting' => 'none',
         'maxlength' => '',
        ),
       ),
       'location' => array(
        array(
         array(
          'param' => 'options_page',
          'operator' => '==',
          'value' => 'acf-options-my-options-page',
          'order_no' => 0,
          'group_no' => 0,
         ),
        ),
       ),
       'options' => array(
        'position' => 'normal',
        'layout' => 'no_box',
        'hide_on_screen' => array(),
       ),
       'menu_order' => 0,
      );
      register_field_group($field_group);
     }
     
    ?>
    

    Now that you’ve generated a dynamic option name based on the logged in user you can retrieve the value based on the logged in user.

    That’s going to make for a lot of options in your option table.

  • When you create a subfield of a repeater it’s given the name and key just like the parent field is given. so you create the filter for that field name or key.

    http://www.advancedcustomfields.com/resources/filters/acfload_value/

    For example, when I do this my setup will have 3 filters, on for the repeater and 1 for each of the 2 sub-fields in that repeater. The first filter will set a number of default rows for the repeater based on the number of rows in options. The other two will set the values for each row. The only thing I left out of my description above is that I only want to set the value if the first filter actually set the number of rows. So my first function would actually look something like:

    
    add_filter('acf/load_value/name=my_repeater',  'afc_load_my_repeater_value', 10, 3);
    function afc_load_my_repeater_value($value, $post_id, $field) {
      if ($value === false) {
        // this is a new post since value === false
        // set value to number of default # of rows to create
        // based on number of rows created on options page
        $value = 5;
        // add filters to call subfield filters here
        // they are only created if we're supposed to use the default values
        add_filter('acf/load_value/name=sub_field_1',  'afc_load_sub_field_1_value', 10);
        add_filter('acf/load_value/name=sub_field_2',  'afc_load_sub_field_2_value', 10);
      }
      return $value;
    }
    function afc_load_sub_field_1_value($value) {
      // get next value for subfield 1 and return
      return $value
    }
    afc_load_sub_field_2_value($value) {
      // get next value for subfield 2 and return
      return $value
    }
    

    the actual subfield filters would be a bit more complicated because the values from the options page would need to be stored in an array in a global variable so that it can be accessed by my function and then each function would need to step through the values to return the next value for each subfield.

    Like I said, I have not actually gotten to building the part where the subfields are set to the options page value. I just know what I’ll need to do when I get back to it and will test and figure out the details then.

    Sorry, that’s about the best I’m going to be able to do as far as an explanation right now.

  • I’m building a plugin, so I’m building everything into a PHP class. I say this because you need to create some counters to keep track of where you are. If you’re not using classes then you’ll need to use global variables to do the counters.

    Here are the steps.

    During initialization I read in the values from the repeaters and store them into an array. The array will need to be either a class property or global variable. this function should probably run at “plugins_loaded” to make sure that ACF functions are available for retrieving your repeater field data.

    the next step is to set the correct number of repeats. That’s done with the function I gave in my last comment. You just need to return the count of the array that holds your subfield data.

    For each subfield you need to create a another filter, along with a counter to keep track of where you need to be.

    
    global $subfield_1_counter;
    $subfield_1_counter = 0;
    add_filter('acf/load_value/name=subfield_1',  'afc_load_dubfield_1_value', 10, 3);
    function afc_load_dubfield_1_value($value, $post_id, $field) {
      global $subfield_1_counter;
      // code to calculate next value for this field
      // the exact code here will depend on the type of field being initialized
      // after setting the value, increment the counter and return the value
      $subfield_1_counter++;
      return $value;
    }
    

    To be honest, I don’t have exact details on what I did because I haven’t completed this part yet. Like I said, I’m doing this for a plugin that I’m building and my attention has been diverted from that project. This is how I plan to proceed when my workload drops enough so I can return to it.

    Hope this helps.

Viewing 25 posts - 14,426 through 14,450 (of 14,467 total)