Support

Account

Register Login

Forum Replies Created

  • When we upgraded a client from 5.6.1 to 5.6.3, TinyMCE editors were stuck in **text** mode. Strangely, only the 2nd and on were affected. Clicking on the “visual” tab triggered an error from within core TinyMCE.

    Another hint: problem went away when we disabled all other plugins AND switched to Twentyfifteen.

    Also, we are not using Types Toolset.

  • arcanipsyche –

    aren’t these three lines doing the same thing?

    $repeater = get_post_meta($post_id, 'choose_tps_members', true);

if (get_post_meta($post_id, 'choose_tps_members')) {
   $existingRows = get_post_meta($post_id, 'choose_tps_members', true);

  • Hi Jonathan,

    I think there is an update/change to the code that make the minus 1 to $new_repeater_count unnecessary.

    looking in .//advanced-custom-fields-pro/api/api-template.php for ACF Pro v 5.4.2 – on line 1607 there is this.

    			if( is_numeric($s) ) {
				
				// get row index
				$row_i = intval($s) - 1;
				
				// add to name
				$name .= "_{$row_i}";
				
			} else {

    So it seems like the -1 is now built in the code.

    I’m not too thrilled with this, as now I have to remember yet another hidden functionality to the update_sub_field() function.

    I would update Jonathan’s code to something like this.

    $repeater = get_post_meta($orgPost, 'org_users', true);
$index = (!$repeater) ? 1 : $repeater + 1;
update_field(ORG_USERS_FIELD_KEY, $index, $orgPost);
update_sub_field(array(ORG_USERS_FIELD_KEY, $index, ORG_USER_SUB_FIELD_KEY), $user_id, $orgPost);

  • Hi John,

    Thanks for following up on this. Unfortunately this was so long ago I can’t even remember what project this was for and it seems most likely no one else has had this issue. Oh well, thanks!

  • Hi Jess –

    Yes, understood. I might approach this differently.

    When you save a form, typically that form then posts to the page, or some other page, to process the form data. It sounds like you have two forms on the page, two ways for the user to post to the backend to process data from two seperate forms.

    You might want to look into combining the two forms into one, so that when the form is finally posted, all the form data is sent to the backend to create the PDF.

    You could do this by filtering in opening and closing div tags when certain fields are loaded. Say, you have 10 fields, add a filter to add an opening div tag for field 1, than a closing after field 5 (or a closing and opening before field 6) and then another closing after field 10.

    <form>
    <div>
        <input>
    </div>
    <div>
        <input>
    </div>
    <input type=submit>
</form>

    Now all your input values will be posted to the server at once. There are some other ways to tackle this as well. LMK if this is along the path that might be helpful.

  • Hi Jess –

    Not sure I 100% follow – is there an acf_form() on the page. I believe the acf javascript obj gets loaded with the header scripts. <?php acf_form_head(); ?>

    It wouldn’t be hard to just write some jquery/javascript to basically change a var if the user changes a field, and throw a warning like this.

    window.onbeforeunload = function(){
  if (change) {
    return 'Are you sure you want to leave?';
  }
};

    See: http://stackoverflow.com/questions/7080269/javascript-before-leaving-the-page

  • Hi @[email protected]

    If I recall, doesn’t WPMU create new tables for each site in the db. Switching the blog should switch the tables being used. Is the repeater in all the tables?

  • Hi @James –

    Thanks, that does make sense. I guess I assumed that updating a sub field would initialize the repeater, or did at some point. To me it seems like it should, or the docs should say to do an initialization to a repeater before calling update_sub_field().

    Thanks

  • Dumping out the meta_data for one of these post reveals that when the post is saved via the admin save button, it has a [_primary] => array ([0] => field_key).

    When dumping out the meta for a post that has only had its repeater field sub fields saved, it is missing the [_primary] key in the meta array.

    I guess I maybe able to resolve this (glitch, bug, or miss understanding of how ACF update_sub_field() works) by adding that meta value and array with key, programatically.

    FIXED
    Add this after the update_sub_field() function is called appears to fix this issue.

    
update_post_meta($submission_id, '_primary','field_559eee03f62d2');

    The repeater name is “primary” and ACF needs the “_primary” meta to hold the “primary” field key ID. It would be nice if this was done via update_sub_field() but apparently it isn’t.

  • Hi James –

    I’m using the outside have_row() version of update_sub_field.

    
update_sub_field( array( 'field_559eee03f62d2', intval( $field['data']['group'] )+1, 'field_559eee10f62d3' ), $field['data']['term_id'], $submission_id );
update_sub_field( array( 'field_559eee03f62d2', intval( $field['data']['group'] )+1, 'field_559eee26f62d4' ), ucfirst( $field['value'] ), $submission_id );

    If I convert over to update_field() than I have to rewrite the code to make the whole array first, then send to update field all at once, correct? (A lot of investment in that.)

    The very odd thing is, when the admin page loads, the fields are set correctly, but when trying to get the values in code, only the number of rows is returned and have_rows() returns false. Seems like a bug with update_sub_field()

    I’d also like to add that this code was working previously and I wonder if an update introduced a bug. Unfortunately this code is only run quarterly. I remember it working fine when I launched it 6-9 months ago. But now there are problems.

  • Thanks John, Thanks for this, I’ll take a look into it.

    To expand on some detail. I have a custom post type called campaigns. Each campaign post has a custom taxonomy associated with that post. (you can do this with some filters of what meta boxes display on the right column of the edit admin screen – so it is kind of faking it since all the taxes are really associated with the post type.). I do this because I need the user to be able to create different categories in the different taxonomies that only show on that specific post admin screen.

    In the front end acf_form() I load the list of campaigns, once the users selects a campaign, I then need to load the taxonomy associated with that campaign. I have ajax that sends the campaign post ID after the user selects. I then need to load or reload the taxonomy checkbox field that is associated with that selected campaign post. On the backend I’m using acf/load_field/ filter to alter which taxonomy loads based on what campaign the user has selected.

    I’m hoping to do that load/reload in an ACF way (either by loading the field HTML on the server and sending it back in the ajax, though I don’t think this will work because it appears that ACF uses a load of javascript to actually create the fields and values, or loading the taxonomy (field options) in a JSON config and then sending that through ACF javascript that loads with the acf_form() and header functions.)

    Thanks,

  • +1 for this

  • DOH!

    Yes, I forgot to upgrade and we were a couple small version back. I feel dumb!

    Thanks John, sorry for wasting your time.

  • Hi E,

    Understood. In my use case though, there are going to be multiple forms on a single page, in an accordion.

    <accordion>
  <panel>
    <acf_form()>
  </panel>
  <panel>
    <acf_form()>
  </panel>
</accordion>

    It will actually be a 8 step form. Anyways, for this, it is good to know how to set the ID for the form so I can tie specific front end js validation checks to specific forms on the page. John’s research helps with this, but the documentation on the acf_form page, at least to me, is not very clear. Normally if I’m told I’m setting the id of the form in $args, I’d expect to see that in <form id=””>.

  • Hi E,

    So does that mean you are only envisioning 1 form per page, since the actual form ID is hard (not clear) to change? I’ve not tried multiple forms on a single page, but that is where I”m headed.

    Anyways, thanks for the clarification, though def not clear in the acf_form() doc.

  • Hi John,

    Good to know, thanks. But still seems like a bug or at least documentation error.

  • Thank John,

    Either way, it would be great to be able to set the ID of the form. I plan to use several forms on a single page (still not sure if that even works, haven’t had time to test) and I’d like to use the ID to trigger form specific JS.

    Thanks,

  • Hi John,

    Thanks, I was able to hook acf_form_head into:

    wp_localize_script( 'csm-csf', 'acf_form_head', array( 'ajaxurl' => admin_url( 'admin-ajax.php', 'http' ) ) );
add_action( 'wp_ajax_nopriv_acf_form_head', 'acf_form_head' );
add_action( 'wp_ajax_acf_form_head', 'acf_form_head' );

    And pass it data via ajax and get a response. Looks like building out the data for basic form elements is easy enough, but repeater fields and select2 off screen fields are going to take some work.

    But I’ll look at other links you provided. Thanks!

  • Hi John,

    acf_form() code looks like this:

    <?php $options = array(
  'id' => 'data-subsection',
  'post_id' => $submission_post->ID,
  'fields' => array(
    'field_55b1208a40b0e',
    'field_5595c1f4a3e3a',
    'field_5595c20aa3e3b',
    'field_5595c26fa3e3c',
    ),
  'submit_value' => 'Save',
  'updated_message' => '',
  );
  ?>
<?php acf_form( $options ); ?>

    Form tag always has id=’post’, which is not what docs say, so bug/ or doc issue there. Rendered HTML looks like this:

    <form id="post" class="acf-form" action="" method="post">

    In file api-tmeplate.php starting around line 1277 ( I have been messing w/ this file for testing of ajax submit form, so lines probably don’t exactly match what is in un altered code base) looks like this:

    	// defaults
	$args = wp_parse_args( $args, array(
		'id'					=> 'acf-form',
		'post_id'				=> false,
		'new_post'				=> false,
		'field_groups'			=> false,
		'fields'				=> false,
		'post_title'			=> false,
		'post_content'			=> false,
		'form'					=> true,
		'form_attributes'		=> array(),
		'return'				=> add_query_arg( 'updated', 'true', $url ),
		'html_before_fields'	=> '',
		'html_after_fields'		=> '',
		'submit_value'			=> __("Update", 'acf'),
		'updated_message'		=> __("Post updated", 'acf'),
		'label_placement'		=> 'top',
		'instruction_placement'	=> 'label',
		'field_el'				=> 'div',
		'uploader'				=> 'wp'
	));
	
	$args['form_attributes'] = wp_parse_args( $args['form_attributes'], array(
		'id'					=> 'post',
		'class'					=> '',
		'action'				=> '',
		'method'				=> 'post',
	));

    I was able to get my $args id to appear by changing:

    	$args['form_attributes'] = wp_parse_args( $args['form_attributes'], array(
		'id'					=> 'post',
		'class'					=> '',
		'action'				=> '',
		'method'				=> 'post',
	));

    to

    	$args['form_attributes'] = wp_parse_args( $args['form_attributes'], array(
		'id'					=> $args['id'],
		'class'					=> '',
		'action'				=> '',
		'method'				=> 'post',
	));

    And if no id is supplied in the $args list, then ‘acf-form’ is the form ID, like the docs say it should be.

  • Thanks,

  • Hey John,

    You are right, it could be like infinite loops in save_post hook. Thanks!

    https://codex.wordpress.org/Plugin_API/Action_Reference/save_post

    But using the get_post_meta() is easy enough, just wanted to make sure it was either a known issue or if it was a bug that could be addressed.

    Edit…
    Yes, that actually works. Remove and then reset the filter inside the filter when calling get_field().

    //sudo code

    add_filter('acf/load_field/key=field_55b1208a40b0e', 'form_load_field_55b1208a40b0e');
function form_load_field_55b1208a40b0e ( $field )
{
  remove_filter( 'acf/load_field/key=field_55b1208a40b0e', 'form_load_field_55b1208a40b0e' );
  $repeater_min_max = get_field( 'display_all_sites', $submission_post->ID );
  add_filter('acf/load_field/key=field_55b1208a40b0e', 'form_load_field_55b1208a40b0e');

  return $field;
}

  • had same issue – your solution didn’t work for me, E’s solution did. So I just want you to know about it incase. I’m using ACF5Pro.

    I put this in as last script before /body. Though I suppose it only has to be below the ACF scripts. I’m using acf_form() w/o the form component to load a repeater field, and navigating away after changes to that field were causing that popup to appear. But no now. 🙂

    link for ref: http://support.advancedcustomfields.com/forums/topic/disable-acf_form-navigate-away-warning/#post-27915

    <script>
(function($) {
  $(document).ready(function() {
    // disable the ACF js navigate away pop up
    acf.unload.active = false;
  });
})(jQuery);
</script>
</body>

  • Hi E,

    Thanks, that works.

    For anyone else who needs this, I’m using as the last script to load on the page.

    <script>
(function($) {
  $(document).ready(function() {
    acf.unload.active = false;
  });
})(jQuery);
</script>
</body>

  • Thanks John,

    I will take a look at that over the weekend.

  • Thanks John,

    I have not been able to test your initial email suggestion. Going to do that over the weekend. But if Elliot knows, that would be best.

    It seems that if you are going to use acf_form() w/o the <form> markup, it would be best, or at least be a good option, to also disable any JS that checked for the form being altered before navigating away. That should be left up to the form developer to do that check or not.

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