Support

Account

Register Login

Forum Replies Created

  • On second review, you might be facing a field translation problem.

    Reading material:
    http://support.advancedcustomfields.com/forums/topic/wpml-dont-save-custom-fields/
    http://www.advancedcustomfields.com/resources/multilingual-custom-fields/

  • Our studio is currently facing the same issue and we are working on pinpointing the source of the problem.

    To help solve the issue, we will need more information:
    – ACF version
    – WP version
    – Installed / Active WP plugins
    – Installed / Active WP themes

    You can do some general debugging as well:
    – Does field data save if you have a default theme (TwentyFourteen) active?
    – Does field data save if you disable ALL other plugins?

    Here is a sample report for our current debug site:

    * Core: WP v4.0
    * Theme: Enfold 3.0.1
    * Plugins:

    • Admin Columns 2.2.9
    • ACF Pro 5.1.3
    • Duplicate Post 2.6
    • FacetWP 1.4.3
    • Gravity Forms 1.8.19
    • iThemes Security 4.4.23
    • Publish and Redirecto To Add New Post 1.5
    • Really Simple Twitter Feed Widget 2.5.11
    • Redirection 2.3.10
    • SearchWP 2.3.4b3
    • WordPress SEO 1.6.3

  • I’ve made some progress – ACF fields must be added to the post following the wp_insert_post() call if they are to be used in the theme!

    In V4, it seems that calling update_field would add the data to the post and calling get_field() ultimately returned something regardless of whether the post had been updated or not.

    In V5, calling get_field() on uninitialized fields will return NULL until the post is updated through the WP admin!

    My theme was doing logic checks to see if a field was true or false before printing some text. Before upgrading, it didn’t matter if the ACF field was actually populated with data, but now it seems that the field will not return a boolean value (instead returns null) if update_field() was never called.

    Simple solution – call update_field() on all ACF fields directly following the wp_insert_post() call!

  • Hey @elliot, thanks for stopping by.

    The update_field documentation you have just provided is precisely the situation I’m dealing with, and it helped me sort this out in the past. There is a new problem since upgrading to v5 however! Previously, data could be saved properly by using the field_key and users would be able to immediately view the front end and see the content that was retrieved using the field_name. Now with v5, the data is not visible on the front end unless each post is manually updated after populating the ACF fields. Interestingly, get_field($field_key) is not working either.

    Was there a change to the way that update_field() performs in respect to the save_post hook?

    In regards to the updated field keys – closer investigation reveals that the keys were simply updated for a few fields, no fields had duplicate keys. This makes sense though – the field keys that changed were those belonging to Repeater and Gallery fields… I would expect that the new v5 system recreated the fields in migration 🙂

  • Unfortunately, no. I ended up making a workaround lookup table that associates the GUID field name with the clean field name. Here’s what the code looks like:

    
/*==========================================================
=               ACF Field Association Helper               =
==========================================================*/
// Helps ACF make the correct field associations for un-initd post type fields
function custom_get_field($fieldname, $post_id=null){
	global $post;
	$acf_field_pairs = array(
		'field_534c20ba37335:caf_gallery',
		'field_534c209137334:caf_carproof_link',
		'field_534c20e537336:caf_summary_features',
		'field_534c431f9d29f:caf_description',
		'field_534d6eda9dbc3:caf_sale_price'
	);

	$acf_fields = array();
	foreach($acf_field_pairs as $pair){
		$pair = explode(':', $pair);
		$acf_fields[$pair[1]] = $pair[0];
		$acf_fields[$pair[0]] = $pair[1];
	}

	$output = get_field( $acf_fields[$fieldname] , $post_id);
	return $output;

}

    So in this function, I’m using a manual lookup $acf_field_pairs array – it’s a colon-separated pair because that’s how it comes in from my Redux Options Framework, but your system might build this differently. The left side is the unique field ID (can be found by inspecting elements in your ACF field groups) and the right side is the clean field name. This function adds both pairs to the generated array so that it can work in both directions.

    This is obviously a problem because you have to add new ACF fields here when you add them to the admin.

    I have a sneaking suspicion that this might not be a problem in the new ACF v5 however as ACF data will be a full post object instead of meta data.

  • Nice work guys! Glad we got that sorted.


    @mdetoni     be sure to set this thread as solved if we’re good to go.

    @drift2     I’ll be watching that site with interest… shoot me a PM when that goes live 😉

  • @drift2 The code provided will loop through all available terms within that taxonomy, so we have to adjust it if we’re focusing on a single term.

    $current_term = get_taxonomy( get_query_var( 'taxonomy' ) );
$field = get_field('style_id', $current_term->taxonomy.'_'.$current_term->term_id);
echo '<pre>field: '.print_r( $field, true).'</pre>';

    Any luck?

    Edit: sit tight, this code will fail
    UPDATE: Code for single term:

    $term = get_term_by( 'slug', $wp_query->query_vars['term'], $wp_query->query_vars['taxonomy']);
$field = get_field('style_id', $term->taxonomy.'_'.$term->term_id);
echo '<pre>field: '.print_r( $field, true).'</pre>';

  • @madebytincans do you remember where you were making the get_field() calls? I’ve had a few issues recently with using ACF fields before the global query object was initialized.

  • Ok, I’ve done a bit of testing and I agree that something is not working as expected… until I figured out how to get taxonomy fields. I’ll try and lay this out so that you guys can tell me if I’m doing the right thing!

    Steps to reproduce:

    1. Add a new Field Group: /wp-admin/post-new.php?post_type=acf
    2. Add a new field to this group
    3. Set the Location Rules: Show field group if Taxonomy Term is equal to [taxonomy], Save field group
    4. Add a new taxonomy term with the custom field: /wp-admin/edit-tags.php?taxonomy=[taxonomy]
    5. Attempt to retrieve field in theme with get_field()

    I was unable to get the field data properly until realizing that I wasn’t calling the taxonomy field properly.

    http://www.advancedcustomfields.com/resources/how-to/how-to-get-values-from-a-taxonomy-term/

    So getting the field data looks like this (using @mdetoni’s taxonomy):

    $terms = get_terms( 'audiocategorias', array( 'hide_empty'=>false ) );
foreach($terms as $term){
	$field = get_field('ab_rolp', $term->taxonomy.'_'.$term->term_id)
	echo '<pre>field: '.print_r( $field, true).'</pre>';
}

    To get taxonomy fields, the post ID variable must start with taxonomyname_, so in this case audiocategorias, or in the example we pull it directly from the taxonomy term itself: $term->taxonomy.'_'.

    Does this help anyone or am I heading in the wrong direction?

    Edit: @drift2’s example

    $terms = get_terms( 'radioroom', array( 'hide_empty'=>false ) );
foreach($terms as $term){
	$field = get_field('style_id', $term->taxonomy.'_'.$term->term_id)
	echo '<pre>field: '.print_r( $field, true).'</pre>';
}

    Note that in these examples we are using 'hide_empty'=>false in order to force the retrieval of terms. This is required for a term to show up in our list if there aren’t any posts with this term selected.

  • Aha, I missed that this was for a profile! It’s good that you’re seeing the <pre> tags, but to get user profile fields you have to pass in the user ID prepended with “user_”.

    http://www.advancedcustomfields.com/resources/how-to/how-to-get-values-from-a-user/

    So to get the field for user ID zero:

    $user_id = 0;
$field = get_field('test_acf_upload', 'user_'.$user_id);
echo '<pre>'.print_r($field, true).'</pre>';

    You could get the user ID with a variety of functions.

  • Hi mdetoni. Not totally sure I understand – are the custom fields bound directly to the taxonomy itself?

  • ACF field values are loaded through wp_cache_get if cache is available for that object. I’m not entirely sure how this affects normal ACF calls, or if ACF makes other database queries outside of getting field values… but it’s a promising thought.

    wp_cache_get can be seen in action at advanced_custom_fields/core/fields/_functions.php:309.

  • Both usermeta.meta_value and postmeta.meta_value are stored as LONGTEXT. Here’s how the MySQL docs describe the size of a LONGTEXT data type:

    “A TEXT column with a maximum length of 4,294,967,295 or 4GB (232 – 1) characters. The effective maximum length is less if the value contains multi-byte characters. The effective maximum length of LONGTEXT columns also depends on the configured maximum packet size in the client/server protocol and available memory.

    HOWEVER, ACF fields are stored by passing these values by $_POST to the server, so you might be getting hit on PHP’s post_max_size limit. This can be updated in a few different places:

    php.ini:

    post_max_size=20M
upload_max_filesize=20M

    .htaccess:

    php_value post_max_size 20M
php_value upload_max_filesize 20M

    It might be worth trying some larger values on those variables and testing submissions of different lengths.

  • It should be printed at the very top of your outward-facing theme, like on the home page. There is a chance that your theme’s CSS could hide or distort the output, so you might have to view your page source to see it.

    I like to put a string in front that I know is unique so that I can Ctrl+F and search for the text, like so:

    echo '<pre>testdump999: '.print_r($field, true).'</pre>';

    There’s a pretty slim chance that “testdump999” will show up anywhere else on its own, so if I can find that then it’s the output I’m looking for.

  • test_acf_upload should be the slug for your custom field. Insert this into your active theme’s functions.php file:

    $field = get_field('test_acf_upload');
echo '<pre>'.print_r($field, true).'</pre>';

  • We’ve been doing a bit of troubleshooting. The problem seems to lie with a failed field GUID lookup, having provided a top-level field name.

    • Clicking the “Publish” or “Update” button executes actions that do not get executed by manually calling the save_post action. This means that the database contains errant meta keys and values for myfield, _myfield, field_myfield and field_###########
    • wp_insert_post() does execute the save_post action, but again does not produce the final meta key/value associations required
    • During this in-between state of wp_insert_post() and manually updating the post, get_field_object() returns empty field definitions since the $field_key variable contains the name of a field that does not have a corresponding meta value
    • Executing acf/save_post manually does not work as the function requires a populated $_POST variable. Manually saving the post works, since the $_POST object contains field GUIDs, then calls acf/update_value
    • acf/update_value fails because $field is an empty field definition
    • Updating fields with their GUIDs works fine at any point

    It seems that we need a solid way to update fields that are attached to a programmatically-created post before the post ACF meta data has been initialized.

  • There’s something fishy going on right now, and we’re having some straaange issues over here as well.

    Try adjusting your meta_key value to field_select_attorney_type and see what happens.

  • Process of elimination 😉

    Cheers!

  • Are there any Javascript errors in your browser console? (usually found by pressing F12 and navigating to “Console” tab)

  • Cool, glad to help! We’re all (forever) learning, and I agree that the WP Forums don’t always get the best results. Thanks for stopping by 🙂

  • That should work fine, and the alternate if(): endif; structure is a bit cleaner than the echo code which will do the same thing (even though my example had it in a mixed-up order).

    Analyzing the code structure line by line:

    <?php if( get_field( "review_summary" ) ): ?>
    We check with PHP to see if the custom field review_summary returns any results at all. If the field is not populated, the next few lines of code gets skipped entirely. Nothing is printed or echoed here.

    <h3><?php _e('Summary'); ?></h3>
    Prints the title “Summary” in an <h3 /> tag. This only happens if the previous if() statement validates.

    <p><?php the_field( "review_summary" ); ?></p>
    Prints the review_summary field. Unlike the initial get_field("review_summary") field call, this one actively outputs its contents without having to set an echo in front of it.

    <?php endif; ?>
    Closing if statement.

    Sometimes it helps to indent code to get a better view of the flow:

    <?php if( get_field( "review_summary" ) ): ?>
	<h3><?php _e('Summary'); ?></h3>
	<p><?php the_field( "review_summary" ); ?></p>
<?php endif ?>

    Forgive me if this is too obvious – just trying to help answer any questions you might have. Good luck!

  • The Repeater field (and all ACF Addons) are now available as separate plugins instead of activation codes! You should be able to find a download link for the plugins you’ve purchased by logging in to your store account at http://www.advancedcustomfields.com/store/account/ and poking around through your previous purchases.

    The upgrade path from v3 to v4 is fairly straightforward – update your core ACF through the usual WP plugin update routine, then install and activate your new ACF addon plugins. The Repeater field should show up exactly as you had it before 🙂

  • I might be missing the point here, but…

    <?php
$result_cmb_is_review = get_post_meta($post->ID, 'cmb_is_review', true);
if ($result_cmb_is_review == 'checked'){
	include 'inc/template_review.php';
	echo '<h3>'._e('Summary').'</h3>';
	echo '<p>'.get_field("review_summary").'</p>';
}

    Is this what you mean?

  • <?php while(has_sub_field('image')): ?>

    Should that be <?php while(has_sub_field('gallery')): ?> instead?

  • Hey, no worries… stockpiling information like this will be useful to somebody, someday 🙂

Viewing 25 posts - 1 through 25 (of 80 total)
1 2 3 4