Support

Account

Forum Replies Created

  • Doesn’t seem to add anything in the second repeater using that. The only way I can get it to add rows is using the code in my question. It feels extremely close but it’s just not iterating through the last repeater, so the first row is always copied over.

  • Hi John,

    I’ve progressed this slightly.

    It’s iterating through and adding the column titles to 7 repeater rows. So that works.

    The update_sub_repeater is adding data to all 7 child repeater fields but it’s counting up for some reason… it’s adding 2 child repeater rows to the first parent repeater, 3 to the second, 4 to the third and so on.

    It’s so close apart from this final part, where am I going wrong?

    // Product Code Titles
    $contents = $html->find('div[class=product-table]', 0);
    $data = array();
    $subdata = array();
    $rows = $contents->find('tr');
    $counter = 0;
    $field_key = "field_5ae0882f9d6f9";
    $sub_field_key = "field_5ae088999d6fb";
    $cellcount = 0;
    foreach ($rows as $key_row => $row) {
    
        if($counter == 0) {
    
          foreach ($row->find('td') as $key_cell => $cell) {
    
            $data[] = array(
              "column_title" => strip_tags($cell->innertext),
            );
          }
    
        } elseif($counter >= 1) {
    
          foreach ($row->find('td') as $key_cell => $cell) {
    
            $subdata[] = array(
              "text" => strip_tags($cell->innertext),
            );
            update_sub_field( array($field_key, $cellcount, $sub_field_key), $subdata, $post_id );        
            $cellcount++;
          }
    
        }
    
    $counter++;
    }
    
    echo $cellcount;
    update_field( $field_key, $data, $post_id );
  • I’ve moved

    update_field( $field_key, $data, $post_id );
    update_sub_field( array($field_key, 1, $sub_field_key), $subdata, $post_id );

    Underneath:

    update_field

    I just set the count to 1 so it’s added ALL cell data except from the first row to the child repeater field of the first parent repeater row. Slight progress!!

    I now need to add the correct data to the $subdata variable.

  • This is what I tried:

    // Product Code Titles
    $contents = $html->find('div[class=product-table]', 0);
    $data = array();
    $subdata = array();
    $rows = $contents->find('tr');
    $counter = 1;
    $field_key = "field_5ae0882f9d6f9";
    $sub_field_key = "field_5ae088999d6fb";
    
    foreach ($rows as $key_row => $row) {
    
          foreach ($row->find('td') as $key_cell => $cell) {
    
            $data[] = array(
              // element for row
              array(
                // field in parent repeater
                'field_5ae0887c9d6fa' => strip_tags($cell->innertext),
    
                // nested repeater
                $sub_field_key => array(
                  // element for row in nested repeater
                  array(
                    // field in nested repeater
                    'field_5ae088b79d6fc' => "Test",
                  )
                )
              )
            );
    
          }
    
        $counter++;
    }
    update_field( $field_key, $data, $post_id );

    It’s still not adding the sub repeater fields with “Test”.

    I got closer trying this, it added the titles to 7 rows in the parent repeater field (which is correct) but then it added 7 child repeater rows to the 2nd, 3rd and 4th parent repeater with no data in them.

    It’s not quite right as I wanted it to add 7 rows of data to the child repeaters of each parent repeater with the data in them.

    Therefore building up the table in the image, with the column titles in a parent repeater field and the data in the columns as child repeater rows.

    // Product Code Titles
    $contents = $html->find('div[class=product-table]', 0);
    $data = array();
    $subdata = array();
    $rows = $contents->find('tr');
    $counter = 1;
    $field_key = "field_5ae0882f9d6f9";
    $sub_field_key = "field_5ae088999d6fb";
    
    foreach ($rows as $key_row => $row) {
    
        if($counter == 1) {
    
          foreach ($row->find('td') as $key_cell => $cell) {
    
            $data[] = array(
              "column_title" => strip_tags($cell->innertext),
            );
    
          }
    
        } elseif($counter >= 2) {
    
          foreach ($row->find('td') as $key_cell => $cell) {
    
            $subdata[] = array(
              "text" => strip_tags($cell->innertext),
            );
            add_sub_row( array($field_key, $counter, $sub_field_key), $subdata, $post_id );
          }
          
        }
    
        $counter++;
    }
    update_field( $field_key, $data, $post_id );
  • Hi John, thanks for replying. Will that update both the parent and child repeaters? The first if statement works, it’s adding the first row of the table as 7 repeater rows with the column titles.

    It’s more the child repeater where I want to add the data in each column to the child repeater.

  • Thanks John… although that didn’t solve my problem it did make me realise the order I had things.

    I had the whole users creation section above $post_id = wp_insert_post( $my_post ); meaning it missed that part out.

    All working now.

  • I had to get it working with the following:

    update_field( 'architecture_email_sent', 'Yes', $ID);

    architecture is the name of the group.
    email_sent is the name of the field.
    Yes is the value.
    $ID is the id of the post.

    That was within the have_rows loop.

  • The code above was missing the $match rules so although you could see the correct pages in the location rules, the ACF rule wouldn’t get applied to anything. This should work:

    /*
    * ACF post parent
    */
    
    add_filter('acf/location/rule_types', 'acf_location_rules_types');
    function acf_location_rules_types( $choices )
    {
        $choices['Custom Post types']['cpt_parent'] = 'Custom post type parent';
     
        return $choices;
    }
    add_filter('acf/location/rule_values/cpt_parent', 'acf_location_rules_values_cpt_parent');
    function acf_location_rules_values_cpt_parent( $choices )
    {
    	$args = array(
    		'hierarchical' => true,
    		'_builtin' => false
    	);
        $posttypes = get_post_types( $args );
     
        if( $posttypes )
        {
            foreach( $posttypes as $posttype ):
            
    			if( $posttype != 'acf' ):
    				$args = array(
    				'post_type' => $posttype,
    				'posts_per_page' => -1,
    				'post_status' => 'publish'
    				);
    				$customposts = get_posts( $args );  
    				if ( $customposts  ) {
    					foreach( $customposts as $custompost ){
    						$choices[ $custompost->ID] = $custompost->post_title;
    					}
    				}
    			endif;
    		endforeach;
    	}
     
        return $choices;
    }
    
    //MATCH THE RULE
    add_filter('acf/location/rule_match/cpt_parent', 'acf_location_rules_match_cpt_parent', 10, 3);
    function acf_location_rules_match_cpt_parent( $match, $rule, $options )
    {
    	
    	global $post;
    	$selected_post = (int) $rule['value'];
    
    	// post parent
    	$post_parent = $post->post_parent;
    	if( $options['page_parent'] ) {
    	
        	$post_parent = $options['page_parent'];
        	
    	}
    
    	if ($rule['operator'] == "=="){
    		$match = ( $post_parent == $selected_post );
    	}
    	elseif ($rule['operator'] != "!="){
    		$match = ( $post_parent != $selected_post );
    	}
     
        return $match;
    }
  • Hi @elliot,

    I’ve been looking into this a bit more. I don’t have any forms on the page apart from what is generated by the acf_front_form so no GET’s etc of my own.

    First and foremost I noticed a hole in my code – I have the edit forms set to display:none; by default, if the user logs in and goes to their profile then little icons appear allowing them to unhide the front end form and thus edit their profile. The bit of code that was wrapped around the icons to check if they’re logged in wasn’t wrapped around the front end form as well. This meant that the form was there but hidden regardless of whether you were logged in or not.

    So I’ve now wrapped the code around the form as well so that was more than likely the way the spammers were hitting the form all the time.

    So the fact they have to create an account before they can spam the fields may deter them but it doesn’t really solve the real problem.

    I’m not really sure what the solution is but if you take out all the checks to see if someone is logged in or not then the front end form can be hit with spam.

    This then points to the usual ways to stop form spam such as Captcha’s, honeypots etc etc. I know those are not ideal but at the moment the front end forms are wide open to spam.

    Cheers

  • Thanks for getting back to me @elliot.

    We had some genuine text that was output in the usual way, this had been replaced on several pages by spurious text, arabic etc etc. Just general stuff you tend to get in spam comments.

    We have several other fields on the page with the front end forms that weren’t touched, it only seemed to be the text and textarea inputs.

    Out of 140 custom posts, there was at least a quarter of them hacked with very similar text.

    We have the WP Security plugin so everything apart from this is very secure. We’re very certain they’re getting in via the front end form text/textarea fields somehow.

  • @elliot Ok we’ve figured out what the problem is – our site contains 10’s of thousands of posts. When when you have a page link field within a repeater and have it set to all posts (as we have thousands of posts over various post types) it simply times out having to loop through so many posts. This then causes the havoc.

    We’ve limited the page links to only show pages and this solved the problem. It is ideal but at least we’re functional again.

    Is there any other way to stop this happening?

  • Hi @elliot, just sent it now – had sent it to [email protected]

    I’ve added some extra info to the email just saying that when the repeater field plugin is disabled everything works fine, when enabled, the problems start.

  • @elliot I’ve also tried all kinds of memory increases but no luck. It definitely seems a problem with ACF rather than any other issue. I’ve emailed you login details so you should be able to see it happening first hand.

  • Hi @elliot

    I can send you log in details, I’ll do that shortly.

    No, the edit page half loads but the wysiwyg doesn’t along with any media buttons then it looks like it gets stuck in an endless loop of loading. I’ve come across this on two completely separate sites now.

    Thanks
    Rob

  • Don’t know if this helps but the full error from my console is:

    Uncaught ReferenceError: wp is not defined input.js?ver=4.3.2:339
    acf.media.init input.js?ver=4.3.2:339
    (anonymous function) input.js?ver=4.3.2:822
    x.event.dispatch load-scripts.php?c=1&load%5B%5D=jquery-core,jquery-migrate,utils,plupload,plupload-html5,plupload-f…:4
    v.handle load-scripts.php?c=1&load%5B%5D=jquery-core,jquery-migrate,utils,plupload,plupload-html5,plupload-f…:4

  • Hi @elliot,

    Has there been any update on this?

    We’re experiencing the exact same error.

    ReferenceError: wp is not defined
    wp-content/plugins/advanced-custom-fields/js/input.js?ver=4.3.2
    Line 339

    Advanced Custom Fields – 4.3.2
    Advanced Custom Fields: Repeater Field – 1.1.1
    WordPress – 3.7.1

Viewing 17 posts - 1 through 17 (of 17 total)