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:
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.
@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:
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.
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 requiredwp_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 valueacf/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 definitionIt 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.
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 🙂
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Privacy Policy. If you continue to use this site, you consent to our use of cookies.