Support

Account

Register Login

Forum Replies Created

  • Woops, didn’t read the part about the modified value in the documentation – changing that fixed the issue.

  • @elliot

    That sounds good. After writing my last post it occurred to me that changing the functioning to be unselected by default could cause problems for existing sites. Adding the “allow null” option would be the better course, unless it is possible to only make the change for fields that are created after the update.

    I’m not clear on what you mean in point 2. Do you mean that you would add that functionality into the radio field as an option? That would be great – it would mean that if a person accidentally clicked a radio option that wasn’t required, they could uncheck it again, which is often not possible in forms and can be really annoying.

  • Hi @elliot

    My take on it is based on a few things:

    • While the purpose of a radio button is that one is always selected, that selection can be exclusively the action of the user, as opposed to anyone else.
    • As far as I know, there is no specification that says one member of a group of radio buttons has to be checked by default (I could be wrong on this but the Mozilla Developer reference for the <input> element, linked in my second post above, supports this idea)
    • Having no radio checked by default increases the utility of the radio field, by enabling the usage described in earlier posts in this thread
    • Having no radio checked by default does not reduce any utility because ACF users can still choose to specify a default to be pre-selected using the current version of the plugin (via the Default Value option).
    • An unchecked group of radio buttons creates useful functionality that can only be reproduced using less user-friendly versions (a single option select element, which is less user-friendly because it requires more clicks and doesn’t present all its options at a glance) or a more code-intensive method (adding javascript that unchecks the element after it loads).

    I’d love to see an unchecked-by-default radio field in ACF, as I’ve had a few scenarios where it would have been the perfect solution.

    Given the perception that one member of a radio group is always selected (expressed by a number of people on this issue), maybe it would be more immediately obvious for admins if there was an “allow null” option.

    That said, because the current interface already allows a default item to be set, my feeling is that it would be more intuitive for no option to be pre-selected unless it is specified in the Default Value area.

    Thanks

  • @Candyman

    This solution does not work in the current version of ACF Pro

  • @James

    I feel somewhat condescended to (I know how selects work); I hope that wasn’t your intention.

    Anyway, I just realised that this topic I opened is over a year old. Last August I filed a bug report, as nothing happened with this topic. That report is here: https://support.advancedcustomfields.com/forums/topic/cannot-create-unchecked-radio-buttons/ .

    I think it would be better to continue this over there, as there has been more discussion and most of the points I was going to make here, I have already made there.

  • Hi @James

    I’m not sure what you mean about not being able to replicate the issue. If you add a radio field, the first option will be checked – that’s the problem.

    The true/false solution doesn’t work because if you make it required it does not validate if left unchecked. Even if it did validate, it would be unreliable because it does not force the user to make a choice – they could leave it unchecked by accident.

    Using checkboxes instead of radios does not work because the user can check both ‘yes’ and ‘no’.

    There is one, elegant solution for the problem: Only make one of the radios checked if it explicitly set as the default. There is absolutely no reason to have the first one checked otherwise.

  • Thanks for the input Jonathon. While the code example you provided caused some issues (including an infinite loop when I added the post_id to the have_rows() function!), the field key suggestion was instrumental in solving it. What does work is this: 

    if (false == update_sub_field(
    array('repeater_key', 1, 'sub_field_name'), 
    $value, 
    $postId
)) {
    update_field(
       'repeater_key', 
        array(
            array('sub_field_name' => $value)
        ), 
        $postId
    );
}

    The difference is using the repeater’s key instead of name in the update functions.

  • Update: Actually, I was wrong about the result of get_field() after running the script. What I reported was actually the result of get_field() only after running the update_sub_field() function.

    However what is actually happening is weird. In the database, the result of running the script on un-saved posts is that the wp_postmeta table entries have some issues.

    Here’s what the correct database entries look like (meta_key and meta_value entries):

    _repeater_name..........................repeater_field_key
repeater_name............................1
_repeater_name_0_sub_field_name..........sub_field_key
repeater_name_0_sub_field_name...........$value

    But here’s what I get:

    _repeater_name..........................
repeater_name............................a:1:{i:0;a:1:{s:16:"sub_field_name...
_repeater_name_0_sub_field_name..........
repeater_name_0_sub_field_name...........$value

    So instead of the row count, the repeater_name entry has a serialized array of the sub fields and all the field keys are missing.

  • That worked! Thanks John 🙂

  • Thanks for the effort John. I have just tried this on a similar setup to yours – nothing but ACF and an unmodified twentyfifteen theme, and it still doesn’t work.

    One thing that might account for the difference is that I’m trying to update a select within a repeater – would that explain it?

    I don’t have a local JSON folder.

  • I’m using ACF Pro v5.3.3.2

    Yes, I have removed the filter by removing the ‘add_filter’ statement 🙂

  • Thanks for the suggestion John, but unfortunately it doesn’t work. The choices section was empty after I removed the filter.

  • Thanks @hube2 – I wasn’t aware that topics needed to be flagged. Does Elliot not read the Bug Reports forum?

    Regarding your statement “it’s a radio button, of course it’s required”, I think we’re kind of talking at cross-purposes. You’re talking about the code needing one of the options to be checked in order to provide information. I’m talking about the user being required to take an action.

    Say I have a form that asks for the user’s age range. The options are “Under 21” or “21+”. In order to answer the question, of course, one of these is required – but maybe I don’t care if the user answers the question; or maybe I do. But one of the radio inputs being required in order to answer the question is a different issue from the question be required to have an answer.

    If the form always has “Under 21” checked when the form loads, how do I know if the user just didn’t bother changing it? Or passed over it by accident? I know you suggested that I should have a third option “Rather not say” that would be the default – but what if the information is mandatory?

    You could make the argument that a <select> element could be used, but selects are meant for combining mid- to large- size groups of options in a compact display. When you only have 2 options (or only a small number), radio inputs are clearer and easier to use. For mandatory questions with binary options they are the exact right solution.

  • @hube2
    There is no reason that one radio button from a set has to be pre-selected. Mozilla’s section on the <input> element says nothing to that effect (https://developer.mozilla.org/en/docs/Web/HTML/Element/Input).

    ACF has a “Required” setting for radio fields, which is completely redundant if one of them is always pre-selected.

    ACF also has a setting for radio fields called “Default Value”, with the description “Appears when creating a new post”. If there is nothing entered there, it follows that nothing should be set as the default.

    All this would be academic, but the functionality I am describing has a particular (and important) use: A set of radio buttons with none pre-selected is a well-established way to ensure that users have to make a decision about relevant question/setting/etc. In other words, they are a way to get the form to generate an error if the user hasn’t selected one of the options. This is not possible if one of the radio inputs is always pre-selected.

  • Similar to Robby, I’ve been faced with this a couple of times. What I would like to know is: Would it be possible, with ACF Pro, to have it so that if you drag an existing field into a repeater, ACF would update the corresponding saved data automatically on update?

  • This is still happening in v5.1.11. To clarify, this is a problem because it means that if a field is hidden by conditional logic, you can get an error saying a required field is empty and not be able to see the field.

  • @Elliot – any chance you could take a look at this?

  • Hi @elliot,

    Yes, that makes sense – I should have thought of that! However, shouldn’t it change when max rows is set to 1? There are other changes that acknowledge the fact that no more rows will be added, like the order numeral and add/remove cells being removed.

    Cheers

  • Actually this is no longer an issue as I have just discovered that if you set a repeater to min 1 and max 1 you don’t get any of the repeating logic in the interface, which is great – nice one!

  • I don’t think wordpress has a built in method of adding capabilities to CPTs after they have been created.

    That said, there’s a post here: http://simonwheatley.co.uk/2012/07/capabilities-for-custom-post-types-in-wordpress/ that looks like it explains how to do that through the $GLOBALS array.

  • Thanks @elliot, I figured as much! Basically I need permanent storage for my field definitions, such as in the database.

    In a way it seems overkill to use the database for this purpose, but from the moment I started using ACF I’ve been meaning to add a feature suggestion of saved field definitions that you could choose from when setting up an actual field, so I’ll do that now!

  • Hi Elliot,

    Thanks for the reply. I found it helpful and I am creating a series of classes now to build fields and field groups.

    I have run into an issue though:

    I have a base acfField class from which I extend the different types. I was using the uniqid() function in the constructor to generate the key IDs as you suggested, but they weren’t ‘sticking’. Every time I refresh the page, the key for any new acfField() object regenerates. This actually prevents the field from getting written to the database when saving a post with the field(s).

    Any suggestions on how to get around this? In reality I only need it in situations where 2 fields exist with the same key (the key is based on the name at the moment). So far my solution has been to manually add a incremented number to the key for situations where there is a clash, but tracking that manually could become really unwieldy, depending on the complexity of the setup. It also seems risky, in that problems could arise that are not immediately obvious.

  • That’s because you’re using ‘the_field()’ instead of ‘get_field()’. As I said above, ‘the_field()’ prints the value to the screen immediately.

  • <?php

$postMeta = get_post_meta($post->id);
print_r($postMeta);

?>

    That should give you a print of all the custom fields attached to the post in a 'field_name' => 'field_value' array. This is just temporary code to find out the name of the field that holds the image information.

    Once you have identified the ‘field_name’ that is matched with your image ‘field_value’, do this:

    <?php

foreach ( $posts as $post ) {
   if (has_post_thumbnail($post->ID)) {
    $post_thumbnail_id = get_post_thumbnail_id( $post->ID );
    $image_src=wp_get_attachment_image_src($post_thumbnail_id,'post-thumb');
    $homepage_secs.='<div class="thumb-container"><div class="thumb"><img class="image" src="'.$image_src[0].'" /></div></div>';
   }
  $second_image = get_field('field_name', $post->ID);
  // do whatever you need to with the second image

?>

    The difference between get_field() and the_field() is just that the_field() prints the field value to the screen immediately, whereas get_field() allows you to assign the result to a variable.

  • Hi @cosgrove,

    To start you should probably use get_post_meta($post->id) and print the results to screen in order to see what the custom field that has the image info is actually called.

    Once you know that, you can use either the_field('image-field-name') to print the field directly, or get_field('image-field-name') to retrieve the value as a variable.

Viewing 25 posts - 1 through 25 (of 30 total)
1 2