Support

Account

Forum Replies Created

  • I think what you’re looking for is $block[textColor]; ?

  • +1 on this question! 🙂

  • Ha, one last tweak – if you still want the layout to show up on the Custom Fields editing screen, add this to the if (!is_admin()… line:

    if (!is_admin() || 'acf-field-group' == $current_screen->post_type) {
      // not on front end and not when editing the Flexible Content field itself
      return $field;
    }
  • I think something changed in the code between 2017 when John’s solution was posted and now (ACF 5.8.5) – I had to edit the foreach loop to make this work without throwing an illegal offset error. Here’s my working code. It looks to see if someone is editing an ‘application’ custom post type – if they are not, it won’t show the ‘integration_logos’ layout.

    add_filter('acf/load_field/key=field_5d9e369133b92', 'remove_layouts', 99);
    function remove_layouts($field) {
    	if (!is_admin()) {
    		// not on front end
    		return $field;
    	}
    
    	// you need to check to see if it's where you want to remove the layout
    	$current_screen = get_current_screen();
    	if ('application' == $current_screen->post_type) {
    		return $field;
    	}
    	
    // move current layouts into a var
    	$layouts = $field['layouts'];
    
    	// clear layouts
    	$field['layouts'] = array();
    	
    	// list of layouts you don't want to include
    	$remove = array('integration_logos');
    
    	foreach ($layouts as $k => $layout) {
    		$name = $layout['name'];
    		// check
    		if (!in_array($name, $remove)) {
    			$field['layouts'][ $layout['name'] ] = $layout;
    		}
    	} // end foreach
    	return $field;
    } // end function
  • Thanks so much @extrasmall you did indeed save me hours with this! 🙂

  • John you are totally correct, that would solve it. THANK YOU! It’s been a long hard week – you’re so kind to have stuck with me through all that. Thank you!

  • Okay, I think I’ve narrowed down the bug.

    In my original ‘Columns’ layout I had a radio button so people could select the column layout they wanted, for example “100%” or “33% / 66%” or “33% / 33% / 33%”.

    I set up 3 WYSIWYG editors and used conditionals to hide/show them in the editing panel based on what the user selected. So if you chose “100%” you’d see just one editor (this is the default), if you chose “33/66” you’d see two editors, and 3 editors for 33/33/33.

    So here are the steps to recreate the issue.

    1. Add a new ‘column’ layout on a page, select ’33/66′ and enter content in the two visible editor panels.
    2. Add another column’ layout, select ’33/33/33′ and enter content in the three editor panels.
    3. Save/update the page, you now have 2 column layouts displaying, the first with 2 columns, the second with 3.
    4. Click the (-) symbol to delete the 33/33/33 layout. WITHOUT SAVING, add another ‘column’ layout in the same spot. By default it shows with one 100% editor showing, and it’s blank. Looks like a totally empty row. Choose 33/66 – both still blank – same for 33/33/33. Now switch back to 100% and the single editor, enter a piece of content, and “Update” the page.
    5. Now look at the front end – your second column layout will show your new content in the first column/editor space, and the old content (that you thought was deleted) in the other two spots – still 3 columns. It’s like a magic trick. 🙂

    So, the “fix” is to delete all content out of all three Editors, save the page, then delete the layout, then save the page again – every time you want to delete a layout row. If you don’t do that, and get too many layout addition/deletions down the road, it becomes impossible to find the content that’s saved in the db because it doesn’t appear in the WYSIWYG editors when you add new layout rows.

    Or is it just me? 🙂 I just updated to the most recent ACF Pro though I’m not on 4.3 yet.

  • In this scenario, there was only one layout, called “columns”. The ‘columns’ layout contained 5 visual editor fields which were shown/hidden conditionally based on a radio-button field also within the layout.

    I was going to add other layouts, but the issue with all the deleted content showing happened before I could get to that.

  • John, sorry, I feel like I’m being so dense! My code did have get_row_layout() checks (see above) but was still showing content for the rows/layouts that had been deleted via the admin. What am I missing?

  • John, if your clients’ data isn’t deleted, how do you get it not to show up on the front-end of their sites? I am doing the “not-empty” checks to ensure only fields with data get displayed, but obviously these fields contain content. Is there another check I’m missing that would hide “deleted” fields that still contain content?

  • I don’t think I am? I started with just one layout, “columns”, displayed like this:

    `// check if the flexible content field has rows of data
    if( have_rows(‘sections’) ) {

    // loop through the rows of data
    while ( have_rows(‘sections’) ) {
    the_row();

    if( get_row_layout() == ‘columns’ ) {

    if (get_sub_field(‘column_1_content’)) {
    echo ‘<div class=”col col-1″>’ . get_sub_field(‘column_1_content’) . ‘</div>’;
    }
    if (get_sub_field(‘column_2_content’)) {
    echo ‘<div class=”col col-2″>’ . get_sub_field(‘column_2_content’) . ‘</div>’;
    }
    if (get_sub_field(‘column_3_content’)) {
    echo ‘<div class=”col col-3″>’ . get_sub_field(‘column_3_content’) . ‘</div>’;
    }
    if (get_sub_field(‘column_4_content’)) {
    echo ‘<div class=”col col-4″>’ . get_sub_field(‘column_4_content’) . ‘</div>’;
    }
    if (get_sub_field(‘column_5_content’)) {
    echo ‘<div class=”col col-5″>’ . get_sub_field(‘column_5_content’) . ‘</div>’;
    }

    }

    }

    }

  • I’m not concerned about efficiency, so much as all that “deleted” data showing up on my site pages. Because the data is still in the db, the usual if-not-empty,please-display-it code in my templates shows all those rows. I can’t find any way to say “if deleted (even if not empty) don’t show it”.

  • It feels really broken, maybe because I’m more familiar with Repeater fields. When I am editing a Repeater field in a post, and delete one of the repeated-fields, it deletes both the field (from the admin) and the CONTENT of that field. When I add a field back in again, it adds it back in as a blank field. It consistently works this way no matter when I click the main post Update button.

    When I do the same with a Flexible Content row, the row disappears from the admin, but then if I click the ‘+’ button to add a row back in, it appears with all the old content pre-populated. If I delete the row, then Update the post, then add a new row back in, the new row appears blank – but the wp_postmeta from the first deleted row is still in the database and shows up on the front end display (because its contents aren’t blank). And now the only way I can delete the contents of the row I deleted is to go into the database manually and delete them.

    I don’t think this is how it’s supposed to work. Is it?

  • I can confirm this is happening for me too in the latest version (5.2.9). It makes editing the fields really difficult as you have to ‘update’ between each change or risk hidden field data showing up on the site – clients don’t get it at all 🙂 Any news on a fix?

  • +1 to this feature request! Thanks 🙂

  • No answer here, and I understand the limitations of the db/code right now, just another +1 for the idea of being able to retrieve values from specific options pages. This would be super-useful for specific custom-post-type options pages where the fields are similar/same across all CPTs.

  • Thank you all for this thread! I was experiencing the same issue and disabling Object/Transient Cache fixed it. Whew. 🙂

  • I’m seeing this too – bummer! Deactivated TEC and the values are shown in the control panel again (they were always correct in the front-end display).

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