I am very glad to hear the field keys are stable! I’ll eventually do some experiments to set up a custom API endpoint to retrieve field metadata based on field group and/or name, and will relay what I find if the ACF keys are accessible in a different manner for blocks. I hope that’s more of a surface level distinction on the location rules for the field group. I wonder if anyone has made the acf-field-group
and acf-field
CPTs accessible via the REST API? ty for your help!
I just encountered this with a client, and though the Screen Options was my first thought, I’d not run into this before since switching to Gutenberg. Screen Options were so easily accessible in Classic, now they’re fully buried. For anyone searching, they’re located here: Top Righthand Hidden Menu (three vertical dots) -> Preferences (at the very bottom of the menu) -> Panels tab (lefthand tab in the popup) -> “Additional” section.
ACF Pro gives you options pages, this can be used for things that should be accessible to anywhere on the site and can be edited in it’s on location.
Without using this you could create a CPT and have posts in this CPT to add fields for this type of thing and then you would get the values by telling ACF what post ID they are on.
The value that would return for client would be the value of this select: so 990003
<select id=”acf-field_63b1e4a196201″ class=”select2-hidden-accessible” name=”acf[field_63b1e4a196201]” data-ui=”1″ data-multiple=”0″ data-placeholder=”Select” data-allow_null=”0″ data-query-nonce=”aa8b4f40ca” tabindex=”-1″ aria-hidden=”true” data-ajax=”1″>
<option value=”990003″ selected=”selected” data-i=”0″>[email protected] (Hoppes User)</option>
</select>
I’m not super familiar with Elementor Custom Skin but it sounds like you’ve made a product loop, but your ACF image field is located on a taxonomy term which means that the image itself isn’t accessible from the product loop and you’d instead need a taxonomy term loop to get that data. I wish I could tell you exactly how to do this with Elementor Custom Skin but I tend to use Loops & Logic for this kind of thing. You could add a Tangible Template widget within your product loop and write something like this to make that work:
<Loop taxonomy=your_custom_taxonomy_name post=current>
<img src="{Field acf_image=your_image_field_name field=url}" />
</Loop>
Can the attribute name be something else than ID or Anchor? Just to avoid whatever it is ACF is doing.
As I understand you need a unique identifier that doesn’t change on save. And it doesn’t need to be accessible for change in the editor. Right?
Whoa, that’s a pretty mammoth task!
My approach would be to make use of the API and batch processing.
The idea being that it can work through without (in theory) timing out.
You would need to handle that for each custom post type. I assume it’s the same repeater for each post type?
As a possible starting point, perhaps something like the below:
<?php
add_action( 'wp_ajax_nopriv_get_batch_posts_from_api', 'get_batch_posts_from_api' );
add_action( 'wp_ajax_get_batch_posts_from_api', 'get_batch_posts_from_api' );
function get_batch_posts_from_api() {
$current_page = ( ! empty( $_POST['current_page'] ) ) ? $_POST['current_page'] : 1;
// create a file to test the output (this will be the same dir as your functions file if you add this code to functions.php)
$page_report = get_stylesheet_directory() . '/page_report_'.date("dmY").'.txt';
$data = 'Current Page: '.$current_page;
file_put_contents( $page_report, $data . "\n", FILE_APPEND ); // useful to debug
// Create an array
$posts = [];
// $results return an array of objects - CHANGE /posts/ to your custom post type
// Go to the URL https://www.domain.com/wp-json/wp/v2/posts/ to check it shows posts (amend URL accordingly)
$results = wp_remote_retrieve_body( wp_remote_get('https://www.domain.com/wp-json/wp/v2/posts/?page=' . $current_page . '&per_page=10') );
// convert JSON string to PHP array
$results = json_decode( $results );
// either the API is unavailable or we have an error, so bail
if( ! is_array( $results ) || empty( $results ) ){
return false;
}
$posts[] = $results;
foreach( $posts[0] as $post ){
if( have_rows('repeater_field_name', $post->id) ):
while( have_rows('repeater_field_name', $post->id) ) : the_row();
$sub_value_1 = get_sub_field('sub_field_1');
$sub_value_2 = get_sub_field('sub_field_2');
// Create post object
$post_title = wp_strip_all_tags( $sub_value_1 );
$new_post = array(
'post_title' => $post_title,
'post_content' => $sub_value_2,
'post_status' => 'publish',
'post_author' => 1,
);
// Insert the post into the database
$post_id = post_exists( $post_title ) or wp_insert_post( $new_post );
endwhile;
endif;
}
// browse to the URL to trigger this script
// https://www.domain.com/wp-admin/admin-ajax.php?action=get_batch_posts_from_api
$current_page = $current_page + 1;
wp_remote_post( admin_url('admin-ajax.php?action=get_batch_posts_from_api'), [
'blocking' => false,
'sslverify' => false, // we are sending this to ourselves, so trust it.
'body' => [
'current_page' => $current_page
]
]);
}
The code works for batch processing but clearly not tested for your needs! So may require tinkering.
I assume the CPT is accessible via the API (check by browsing to the API URL).
I also assume the repeater is the same in each post
Finally, you would need to map the repeater fields to the new post fields.
Hope that helps!
Ok, I don’t know why, but it’s working as expected now.
It must have been a cache issue, but I swear I was clearing the cache regularly.
For the sake of closure, here’s the code that worked (once the field was accessible):
<section class="center-align stories" id="stories">
<div class="wrap cf">
<div class="row">
<?php
if (have_posts()) : while (have_posts()) : the_post();
$my_id = get_the_ID();
?>
<?php // Only show posts where 'visibile_on_index' is not 0 (either 1 or unset)
if (get_post_field('visible_on_index', $my_id) != 0) { ?>
<div class="fourth <?php foreach(get_the_category() as $cat){ echo ' '.$cat->slug; }?>">
<div class="inner">
<a href="<?php the_permalink(); ?>" class="img-holder" style="background-image: url(<?php the_post_thumbnail_url('full'); ?>)"></a>
<a href="<?php the_permalink(); ?>">
<h4><?php the_title(); ?></h4>
</a>
<?php the_excerpt(); ?>
</div>
</div>
<?php }; ?>
<?php endwhile; ?>
<?php bones_page_navi(); ?>
<?php endif; ?>
</div>
</div>
</section>
You can change field labels but not field names (slugs) without losing the connection to previously entered data.
For example, if you have a text field with label “Camera Lens 1” and field name “camera_lens_1” you can change the label and the new label text will be shown in the templates where this label is used. But if you change the field name it will not update the old data in the database, so you would start with an empty list again. The old data isn’t lost, it’s still in the database, but it won’t be accessible unless you change the name back to the old one.
I hope I’ve understood your question correctly. For more specific answers you’ll have to post your field setup exactly.
Hey @matthias-wagnerfalkemedia-at,
Thanks for the report, we did make changes in 5.10 that could potentially cause this, but we’ve been unable to reproduce it locally – it could be caused by the browser loading a cached or old version of the acf-input.js file though.
Are you able to clear the browser cache and see if it’s still happening? Alternatively, if you could send us your field group export to [email protected], I’ll pick this up with you there and see if we can figure this out.
If you’ve go the issue happening on a publicly accessible site you’re able to grant us access too, even better.
Thanks for your help!
Block color settings are available via the $block
array, but it’s trickier than it seems. First of all, if you’re referencing an array value by key name, the key must be in quotes. E.g.:
$block[textColor]; // <-- THIS *WON'T* WORK.
$block['textColor']; // <-- THIS *WILL* WORK.
The next thing to note is that different $block
settings will be returned depending on whether a predefined named color was picked from the palette or a custom color was picked.
If you pick one of the default palette colors (or if you have set your own palette colors with the add_theme_support('editor-color-palette', array( ... ));
, it will return the slug
of the color (e.g., blue
) instead of a hex-value, and in two separate array keys.
If you pick custom colors, they will be accessible via $block['style']['color']['background']
and $block['style']['color']['text']
.
If you pick two predefined colors:
$block Array => (
...
[backgroundColor] => bright-purple
[textColor] => white
)
If you pick two custom colors:
$block Array => (
...
[style] => Array (
[color] => Array (
[background] => #cccccc
[text] => #aa0000
)
)
)
And if you pick one palette color and one custom color:
$block Array => (
...
[textColor] => black
[style] => Array
(
[color] => Array
(
[background] => #cccccc
)
)
)
Mention to us what you are attempting to do in German language?
My site utilizes ACF Pro in the back end.
I have a gathering field with 3 subfields:
1. A radio catch. which shouldn’t be deciphered. I just need to get to the catch esteem picked by the site’s manager. This worth is something very similar for any language.
I set this present field’s Translation inclinations to duplicate
2 and 3. Picture handle each. a similar picture can be utilized in any of the dialects, yet it’s Alt, Captions, and title tag ought to be deciphered (which btw, is the situation for all media in my site).
Interpretation inclinations for these two picture fields: not certain what to utilize?
Furthermore there’s simply the interpretation inclinations for the gathering field itself. Which confounds me, since I’m as of now being approached to set the inclinations for each of the subfields.
When
Is there any documentation that you are following?
Your docs.
My seetings are
* Dashboard > WPML > Settings > Post Types Translation checked the ‘Translatable – use interpretation if accessible or fallback to default language’ for the Media (connection)’ post sort.
* Dashboard > WPML > Settings > Media Translation > How to deal with media for new substance: checked ‘While transferring media to the Media library, make it accessible in all dialects’ and different ones are unchecked.
Hi,
Mention to us what you are attempting to do in German Language?
My site utilizes ACF Pro in the back end.
I have a gathering field with 3 subfields:
1. A radio catch. which shouldn’t be deciphered. I just need to get to the catch esteem picked by the site’s manager. This worth is something very similar for any language.
I set this present field’s Translation inclinations to duplicate
2 and 3. Picture handle each. a similar picture can be utilized in any of the dialects, yet it’s Alt, Captions, and title tag ought to be deciphered (which btw, is the situation for all media in my site).
Interpretation inclinations for these two picture fields: not certain what to utilize?
Furthermore there’s simply the interpretation inclinations for the gathering field itself. Which confounds me, since I’m as of now being approached to set the inclinations for each of the subfields.
When
Is there any documentation that you are following?
Your docs.
My seetings are
* Dashboard > WPML > Settings > Post Types Translation checked the ‘Translatable – use interpretation if accessible or fallback to default language’ for the Media (connection)’ post sort.
* Dashboard > WPML > Settings > Media Translation > How to deal with media for new substance: checked ‘While transferring media to the Media library, make it accessible in all dialects’ and different ones are unchecked.
Hi,
Mention to us what you are attempting to do in the German Language?
My site utilizes ACF Pro in the back end.
I have a gathering field with 3 subfields:
1. A radio catch. which shouldn’t be deciphered. I just need to get to the catch esteem picked by the site’s manager. This worth is something very similar for any language.
I set this present field’s Translation inclinations to duplicate
2 and 3. Picture handle each. a similar picture can be utilized in any of the dialects, yet it’s Alt, Captions, and title tag ought to be deciphered (which btw, is the situation for all media in my site).
Interpretation inclinations for these two picture fields: not certain what to utilize?
Furthermore there’s simply the interpretation inclinations for the gathering field itself. Which confounds me, since I’m as of now being approached to set the inclinations for each of the subfields.
When
Is there any documentation that you are following?
Your docs.
My seetings are
* Dashboard > WPML > Settings > Post Types Translation checked the ‘Translatable – use interpretation if accessible or fallback to default language’ for the Media (connection)’ post sort.
* Dashboard > WPML > Settings > Media Translation > How to deal with media for new substance: checked ‘While transferring media to the Media library, make it accessible in all dialects’ and different ones are unchecked.
I think I’m having this problem as well. It’s really wierd.
I’m building a custom WooCommerce-action that does a bunch of stuff for the given order. I initiate the action, by adding this to the functions.php-file:
function custom_add_order_action( $actions ){
global $theorder;
$actions['custom_thing'] = 'My own custom action';
return $actions;
}
add_action( 'woocommerce_order_actions', 'custom_add_order_action' );
add_action( 'woocommerce_order_action_custom_thing', 'custom_action_content' );
function custom_action_content( $order ){
$my_class = new WcActionCustomActionClass( $order );
}
… and inside WcActionCustomActionClass a bunch of things happen.
One of which should be to update the ACF-fields for the WooCommerce order. Let’s say that the order_id is 12345.
Regardless of what I do, then I can’t get it to update _any_ of the fields, when I run update_field()
inside my class, _unless_ if I write die()'
afterwards(?!).
So if I do this:
update_field( 'test', 'some value', 12345 );
and run the action, then the value of the test
-field hasn’t changed.
But if do this:
update_field( 'test', 'some value', 12345 );
die();
… and then check it in another browser-window, then the value _does_ change. Really wierd!
————–
### Solution attempts
**1. New field**
I tried creating a new field and trying to update that. Exactly the same bug as described above.
**2. Updating the field elsewhere**
I tried updating the field in the init
-hook, ensuring that my code actually works:
function test_init(){
update_field( 'test', 'another test value', 12345 );
}
add_action( 'init', 'test_init' );
This updates the field (as it should).
**3. Updating the field before my class is initialized**
I tried changing my code, so it looks like this instead:
...
function custom_action_content( $order ){
update_field( 'test', 'another another test value', 12345 );
$my_class = new WcActionCustomActionClass( $order );
}
**4. Using the field_key**
I tried using the field key, like this:
...
function custom_action_content( $order ){
update_field( 'field_603f667437ba9', 'another another another test value', 12345 );
$my_class = new WcActionCustomActionClass( $order );
}
… Same thing. No change.
And again. If I do this:
...
function custom_action_content( $order ){
update_field( 'field_603f667437ba9', 'another another another test value', 12345 );
die();
$my_class = new WcActionCustomActionClass( $order );
}
… and open the order in a new window, then the value updates(?!). Omg…
**5. get_the_object**
Inside my class, I tried getting the field object, ensuring that it was accessible. So I did this:
$field = get_field_object( 'field_603f667437ba9' );
vardump( $field );
die();
and it returns an array of the field:
array (
"ID" => 48617
"key" => "field_603f667437ba9"
"label" => "Test"
"name" => "test"
"prefix" => "acf"
"type" => "text"
...
So it _is_ accessible! Hmm…
**6. Moving the function up to fire earlier**
I figured, that maybe something ‘got in the way’ of the ACF-function firing, so by moving it up to be the first thing that runs during that action, then maybe that could make a change.
… But it was the same result: No change, unless I made it die()
just after.
**7. Moving the function, making it fire later**
So that means doing this:
...
function custom_action_content( $order ){
$my_class = new WcActionCustomActionClass( $order );
update_field( 'field_603f667437ba9', 'another another another test value', 12345 );
}
… Same thing. Doesn’t change, unless I write die();
after.
**8. Clear cache and restart Apache/Nginx**
Didn’t change anything.
**9. Try using update_post_meta() instead**
Same result.
This doesn’t change anything:
update_post_meta( 12345, 'test', 'Another another another... value' );
This make the value change:
update_post_meta( 12345, 'test', 'Another another another... value' );
die();
As a quick fix, I tried this solution where you increase the width of the block panel upon clicking on a “.wp-block” element.This way, the panel expands and the ACF fields are more accessible and big enough to enter the content. Clicking on the top panel exits the mode.
Please feel free to improve the code and use percentage based width if required.
Javascript:
window.addEventListener("load", function (event) {
var wp_blocks_list = document.getElementsByClassName('wp-block');
var get_tool_bar = document.getElementsByClassName('edit-post-header__toolbar');
for (var i = 0; i < wp_blocks_list.length; i++) {
this.addEventListener('click', elementclick, true);
}
get_tool_bar[0].addEventListener('click', function () {
document.body.classList.remove('widen');
})
});
function elementclick() {
if (!document.body.classList.contains('widen')) {
document.body.className += ' widen';
}
}
CSS:
.widen .edit-post-sidebar{
width: 500px;
}
Functions:
function widen_block_panel_script($hook) {
if ('post.php' !== $hook) {
return;
}
wp_enqueue_script('custom-admin-js', get_stylesheet_directory_uri(). '/custom-admin.js');
}
add_action('admin_enqueue_scripts', 'widen_block_panel_script');
add_action('admin_head', 'widen_block_panel_style');
function widen_block_panel_style() {
echo '<style>
.widen .edit-post-sidebar{
width: 500px;
}
</style>';
}
I am trying to do something similar and am having the same issue. I suspect that the issue relates to the javascript and jQuery that should be replacing either box with a search & select (jQuery select2) field. I noticed that a post_object field’s select box gets the class “select2-hidden-accessible” and an extra span with classes “select2” and “select2-container”. My custom object multi-select does not get that class nor the additional span element.
As for the “number box”, that is just what a multiple select field looks like when it is a single line. The arrows allow one to scroll through the options to select/deselect them.
Right, I’ve finally got to the bottom of this after much googling.
The issue is $post->ID. It looks like the global $post is not accessible at that point when you’re using the standard (working code) when the variable is through a Post Object.
Changing it to this, seems to have done the trick:
$thumb = wp_get_attachment_image_src( get_post_thumbnail_id( get_the_ID() ), 'large' );
$thumb_id = get_post_thumbnail_id( get_the_ID() );
Migration – as usual – export db into file, change all occurrences of old domain to new one. Everything else works fine without problem. I have lot’s of experience in WP.
It’s not the first time I’m doing this, that’s also why I’m bit confused.
Two years ago I migrated the same WP instance from same development server, to almost same live server. Difference between those two live servers is in MySQL – on first (where it works, installation two years ago) is 5.6.49 and on second (where I have a problem) is 5.0.12.
But, all in all, it looks like those ACF variables are not “registered” or something like that… looks like they are not “visible” or accessible on front end. Can I help myself by adding something in functions.php file or something like that?
Thank you in advance!
Hello,
Did you find why this was happening?
I have the exact same issue, in the admin the select seems to work since the option has the selected attribute:
<select id="acf-field_5e78f48412b5e" class="select2-hidden-accessible" name="acf[field_5e78f48412b5e][]" data-ui="1" data-multiple="1" data-placeholder="Choisir" data-allow_null="0" multiple="" size="1" tabindex="-1" aria-hidden="true">
<option value="3" selected="selected" data-i="0">jason.g@….ch</option>
</select>
But the select2 doesn’t work, and when saving again from the admin, it resets the value.
Thank you,
Jason
Although this is from 2017, thanks John for the idea!
It might be helpful to others, that the existence of a custom option for the checkbox field is accessible from the field variable.
In class-acf-field-checkbox.php within function update_value() you will find
// save_other_choice
if( $field['save_custom'] ) {
...
Since the select field does not have an option for custom values, you have to check for the text field ‘other, as described by John.
I had trouble accessing the value of this field when working with the acf/update_value filter, since I can only check for either the select field or the custom text field. get_field() will pull the field value from database, the value that was just posted is within the array and I was not sure how to control wich field will be processed first.
acf/save_post is the filter that allows access to all posted values.
However, the $_POST variable delivers just the field keys (like field_1e6543821dge2) and their posted values. So I have to know wich field is the select field and wich is the custom text field. At this point, it would be extremely helpful to have the $field[‘save_custom’] value set, like it is for the checkboxes.
My workaround, which unfortunately needs to check for the exact field keys is as follows. Biggest diadvantage is that whenever I change the fields in WordPress backend, I need to change the code. If someone had an idea how to make this approach more generic, help would be appreciated. I put the code inside a plugin, so setting up an option page would be reasonable to assign custom fields to select fields.
However, I hope that we will see the select fields featuering custom values, soon!
Please note that the following code is used within a WooCommerce site, so please check your post_type!
function my_custom_select_field( $post_id ) {
$new_custom_values = array();
$repeater_key = 'field_1e6543821dge2'; // in my case, select field is inside a repeater field
$select_key = 'field_1e72471e52424';
$custom_key = 'field_1e82477957985';
// not a product, not our business
if( 'product' != get_post_type( $post_id ) ) return;
// not generic yet... check for specific field or leave
if ( !( $_POST['acf'][$repeater_key] && is_array($_POST['acf'][$repeater_key]) ) ) return;
// STEP 1:
// if cusotm values are submitted, just move them to our select field
//
$repeater_field = $_POST['acf'][$repeater_key];
// check if we have a custom value
foreach ( $repeater_field as $row => $repeaters) {
if ( ( ( $repeaters[$select_key] === 'custom' ) ) && ( !empty( $repeaters[$custom_key] ) ) ) {
// assign custom value to our actual select field
$repeater_field[$row][$select_key] = $repeaters[$custom_key];
// gather new custom values to update select field
$new_custom_values[] = $repeaters[$custom_key];
// clear the custom field, no need to keep it
$repeater_field[$row][$custom_key] = '';
}
}
// save modified values to actual POST, please note that no return value is neccessary since this
// filters the $_POST wich will be processed afterwards
$_POST['acf'][$repeater_key] = $repeater_field;
// STEP 2:
// lets go update the select field to have our new custom options available
//
// if there are no custom values, leave it
if ( empty($new_custom_values ) ) return;
// otherwise, we need our raw select field from db
$field = acf_get_field( $select_key, true );
// bail early if no ID (JSON only)
if( !$field['ID'] ) return;
// loop through custom values
foreach ( $new_custom_values as $v ) {
// ignore if already eixsts
if( isset($field['choices'][ $v ]) ) continue;
// unslash (fixes serialize single quote issue)
$v = wp_unslash($v);
// sanitize (remove tags)
$v = sanitize_text_field($v);
// append
$field['choices'][ $v ] = $v;
}
// save
acf_update_field( $field );
}
add_filter('acf/save_post', 'my_custom_select_field', 5, 1); // priority < 10 = filter before db update
I also stuck on this problem. I’ve imported some posts, but one group ist not accessible via get_field(), although all values appear in the backend. So I guess I need to update these group values to register them correctly in the database. But how to do it? They are placed inside flexible content fields themselves, so the meta_key in the database look like
content_section_3_button_text
…..
…..
…..
content_section_9_button_text
Which means, ‘content_section’ is the flexible content field with different sections inside, and these sections have got a group called ‘button’ with a child field ‘text’ (for the button text) inside.
I also tried to access them with the field_keys, but no success yet. Any ideas? Thanks a lot!
Seems to be a new issue with the overlay and the latest version of ACF Pro. The overlay appears over the crop stage making the buttons inaccessible. Screen shot of issue here.
No, a tool does not exist to do this. If you move fields around (in or out of repeaters or group fields) or you rename them then the values already save will not be accessible.
Altering the database to reflect any changes would be completely dependent on the exact changes made and could likely cause other things to break.
There are paths for making these changes but there is nothing simple, and again, it would be dependent on the changes made.
Let’s say for example that I want to do something as simple as change a field name, instead of changing the field name I would leave the old field alone and add a new field with the new name. Then I would add several filters.
Please not that this us just an example and it may not work for your specific field, it is just a starting place.
// use the field key of the old field
add_filter('acf/prepare_field/key=field_XXXXX', 'hide_old_field');
function hide_old_field($field) {
// this prevents displaying the field so the value can no longer be edited
// but any existing value will be preserved
return false;
}
// load the old value when getting the new field
add_filter(acf/load_value/name=your-new-field-name', 'load_old_value_in_new_field', 1, 3);
function load_old_value_in_new_field($value, $post_id, $field) {
if ($value === NULL) {
// a value was never saved for this field
// get the value from the old field
$value = get_field('old_field_name', $post_id);
}
return $value;
}
It has to do with whether the video is publicly accessible or not. If you look at where the comments would be and see “comments are disabled for this video” then ACF’s oEmbed module is unable to get metadata to properly display video
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.