Support

Account

Forum Replies Created

  • It works the second way, it’s based on the currently logged in user, that being you.

  • The field names you’re seeing are the ACF field id value of your field which is how ACF keeps track of them. Each field you create has 2 values, the field name you give it as well as a unique ID value generated by ACF. ACF uses the unique ID value in all forms. When editing a field group in ACF there is an option in the WP view options that will turn on the display of these field ID values.

  • I think you’d have to do in manually by creating a script to do the work.

    You field, not as a repeater requires two postmeta entries

    • your_field_name => your field value
    • _your_field_name => ACF field id: this field name is the same as your field name prefixed with an underscore and contains a reference to the ACF field id generated when creating the field.

    When you have a repeater this changes to

    • repeater_field => count of rows
    • _repeater_field => ACF field id of the repeater
    • repeater_field_X_sub_field => each row subfield value, the X is the index of the row starting at 0
    • _repeater_field_X_subfield => ACF field id of the sub-field

    My suggestion would be to leave it as it is and create a new field for your repeater. Tell the client that on new posts to ignore the old field and use the new one, and when updating an old post to move the old images to the new field. Then in the front end use values from both fields in the display.

  • Is this something like what you are seeing? a:1:{i:0;s:1:"1";}
    That is an array of user IDs in serialized format. In this case an array with one element. To get this you can convert using something like:
    <?php serialize(array($user_id)); ?>

  • I do that when I mean to hit duplicate all the time, in too much of a hurry 🙂

    Good thing is, if you haven’t changed too much, you can reload the page and have it reset to the last time you did a save.

  • remove the “echo”. Not required, but you should also add some checking and set a default value:

    
    $email_to = '[email protected]';
    $contact_form_email = get_field(‘contact_form_email’,'options’);
    if ($contact_form_email) {
      $email_to = $contact_form_email;
    }
    $email_subject = “Submission from Website”;
    
  • If you need to apply different sizes to an image added with ACF the I’ve found the best choice is to have it return the attachment id rather than any of the other things it can return. Then it is simple to us a different images sizes of the same image.

    
    $attachment_id = get_field('taximage', 'industrygroups_'.$lc->term_id);
    if ($attachment_id) {
      $image = wp_get_attachment_image_src($attachment_id, 'my-custom-size');
      if ($image) {
        ?><img class="img-responsive img-thumbnail" src="<?php echo $image[0]; ?>" /><?php 
      } // end if image
    } // end if attachment_id
    
  • Sorry, confused, I read the acf/setup_fields and completely missed the “JS” part.

    Have you looked at the new acf-field-type-template setup? https://github.com/elliotcondon/acf-field-type-template. The JS side has changes as well. There is an example JS file that has the if/else statement for setup depending on if ACF4 or ACF5 is running.

  • I’ve never had a problem with it, except for sometimes returning too much 😛 There are setting for the plugin to tell it where to search and what to return. If you create custom post types that should not be searched you need to make sure they are not public. But I haven’t had any problems or conflicts with ACF.

  • You need to use the taxonomy and the term_id value in your get_field call

    
    $group=get_field('channel_group', 'channel_'.->$event->term_id);
    
  • I know this is old, but the problem with most importers is that they don’t do images and other attachments and most of the ones you pay for can’t handle fields like repeaters and some of the other more complicated stuff, and even when they say they do they don’t always work… like one of them assuming that a post type named “product” means you are using Woo even when you don’t check the box and do check ACF. I think what we need is a plugin that works specifically with ACF and just ignores everyone else. If it was not attempting to be all things to all people it might do a better job at dealing with ACF.

    I’ve actually been building a php tool that does what I need by jamming everything directly into the DB. I’ve been getting a pretty good handle on what it takes to get ACF to see the data that’s been jammed in there. Problem is that I have to customize it for every site.

    Honestly the main issue I have doing through the WP interface is having the import timeout before it’s completed so I’ve been running it using a cron.

    What I’d really like to see is a system where you can associate columns in a spreadsheet with the post and meta keys to be inserted, upload csv files and images to be used in the import. It would also need to be able to handle custom post types, multiple taxonomies, custom taxonomies. It somehow also needs to contend with importing custom fields used on terms. And it has to be CSV because everyone wants to be able to edit the import in Excel and they want it to be easy, single columns of data.

    Too bad I don’t have a few months of vacation I could take..

  • Images are always stored as the ID value. So the meta_value will be the ID of the post attachment containing your image.

  • I walked away from the computer thinking about this, because you’re creating a new type of custom field….

    You might want to think about having a choice of things to return, the stylesheet url… maybe the script to call in some way. This is going to be a hard one because as a developer using you’re field type I’d want to be able to determine where I put it and how the value is used, on the other hand, if done by using a script then you’d have to have some way to ensure the script that loads up the styles heet into the header is only loaded once.

    Creating a field type is about outputting a value that another developer can use for something. Not sure how you’re going to work that out.

  • I’m assuming that the custom field is associated with a post of some type.

    Is would be the same principle that you did in the back-end. You enqueue a script, localized with the css file to load. Then when the script runs it can add the the stylesheet to the header. This would probably be the way you’d want it to work if you want to somehow add the stylesheed to the page during the “get_field()” or “the_field()” function calls.

  • As far as true/false fields go. The value “1” is stored for true and “0” for false. So you’d need to do exact checking:

    
    if ($variable === false) {
      // get_field() returned exactly false, so the value is not set.
      // set the default value
    }
    

    The links above also include the links to the action hooks for when a theme is activated or switched. You’d need to create a function that runs on one or both of these hooks and use the update_field() function to insert all of your default values. You could probably loop through the “fields” sub-array of the export to get the field keys and values to insert. The difficulty of actually inserting the values will depend on the field types involved. I think that repeater fields (and maybe some others) will be problematic.

    Really, there are only 2 choices, value checking in the theme when the value is loaded or building a function to insert the data when your theme is activated, and of course seeing if it was already inserted by a previous activation of your theme or removing the data when your theme is deactivated.

    This isn’t really a problem is the options page addon. The insertion of data does not happen until someone edits the options page. You’re suggesting that instead, when a field group is created that all the default values are auto inserted. There is no way to tell where that data needs to be inserted because you can attach the same field group to many places (posts, pages, options pages, users, custom post types, etc) many of which will not even exist when when the field group is created. Doing this would by pretty much impossible to detect when to do it and where to insert the data.

  • @newlife07,

    That would be better handled by using an options page. Either ACF Pro version or if your using ACF4 then http://www.advancedcustomfields.com/add-ons/options-page/.

    With this you can create a “Theme Options” option page and create fields on it that are easily accessed from header.php.

  • You can look at this: http://www.advancedcustomfields.com/resources/functions/update_field/, as well as http://codex.wordpress.org/Plugin_API/Action_Reference/after_switch_theme and http://codex.wordpress.org/Plugin_API/Action_Reference/switch_theme

    But this feels like fixing a problem that could have been prevented in the first place by applying some basic coding standards.

    For me, basic value validation is an automatic thing and I think much easier to deal with then building a script to populate the database when my theme is activated.

    Do you attempt to echo $_POST[‘some_key’] before you test to see if it has a value? Well, if you don’t care about warnings and errors, or security I guess. Personally I don’t use any value unless I’m sure I know what it contains before I use it; that’s just basic security and PHP best practices.

  • Hopefully this will help, but I think I understand what you’re doing. I’m not exactly sure on the details of how to accomplish it, but I can give you a general outline.

    Enqueue a JavaScript.
    When your field is loaded or changes the script is run.
    The script will look at the field and get the font that needs to be include then creates a new <style> element in the head of your document with the link to the correct CSS file.
    You may also want to delete any previous <style> elements that were created when the user switches fonts.

  • I recently just ran into this myself and did some digging around in the code. It appears the doc on this filter is incorrect.

    The actual hook looks like acf/render_field/type={$field_type}, which is consistent with all the other ACF filters.

  • You custom field data is saved into the database just like any postmeta value… mostly. Fields on options pages, repeaters and some other places are stored differently or in other places.

    If you’re going to bypass WP for showing the front end then I’d suggest digging through the database to see how all of your fields are stored and where. Doing a search using phpMyAdmin on you field name will get you to the areas you need to look at.

    Is there a particular reason why you completely bypass WP on the front end?

  • There is no setting to restore the default value. I think you have 2 options.

    If you want the editor to see that it’s being restored to the default value, that would take writing some javascript to include with your field group. Probably the more difficult of the 2 options.

    The other option is to add a filter to check the value before the database is updated, probably the easier option.

    
    add_filter('acf/update_value/name=my_field_name', 'my_acf_update_value', 10, 3);
    function my_acf_update_value($value, $post_id, $field) {
      if (empty($value)) {
        $value = $field['default_value'];
      }
      return $value;
    }
    

    for more information see the update_value doc page: http://www.advancedcustomfields.com/resources/filters/acfupdate_value/

  • You need to check for and set default values because there are not values saved until the user saves the page. get_field() returns false when a value has not been saved yet.

    
    $variable = get_field('my_field', 'option');
    if (!$variable) {
      $variable = 'my_default_value';
    }
    
Viewing 25 posts - 14,376 through 14,400 (of 14,470 total)