Forum Replies Created

  • +1 For Flexible content also

  • This reply has been marked as private.
  • This was NOT acf related. Really sorry for this, it was either an update of WPML or when we added Danish and German languages that caused the problem. It converted all permalinks from for example: Allmänt -> allmaent. Before it was Allmänt -> allmant.

    We solved it by:
    a. Defining: ‘menu_slug’
    b. Adding a filter that solved the permalinks problem

    If anyone need the solution, please contact me.

    Thank you for the quick help ACF and sorry again!

    Marking this as solved.

  • Hi! Sorry for not adding enough info about the problem. I’m talking with Elliot directly about it right now. I wrote this to him:

    We have tried to recreate the issue on one of our other installations but without luck so i think this was only on one specific site of ours.
    This happened on a pretty big and complicated site. My guess is that it happened in combination with WPML and a few specific settings.

    We declared the options page like this:
    ‘title’ => ‘Allmänt’,
    ‘parent’ => ‘ac-settings’

    So it is most likely the translation from “Allmänt” that changed somehow when we updated the plugins.

    We have now added the ‘menu_slug’ => ”, for future installs so that this problem won’t appear again.

  • No response from Elliot since September. Is this problem a priority? Is it going to get fixed? Would really appreciate an answer on that.

    Best regards


    I’m using nested Flexible Content fields and this function really slows down my backend when dealing with alot of fields. Also it slows down the Media-modal that comes up when you choose a picture for example.

    It seems append is called to often? I can’t figure out why it slows down at the moment, i’m putting this on ice until i have more time.

    Hopefully Elliot makes this functionality part of core!

  • I would like to present an alternative solution as the one marked above didn’t work for me. This is how i did it, since i needed to keep the while loop and had to use get_sub_field();

    Hope anyone can find it useful.

    $flexible_row_number = 1;
    //Count rows
    $flexible_row_count = count( get_field("flexible_content_field_name") );
    //Create random number out of number of rows. 
    $flexible_row_rand = rand(1, $flexible_row_count);
    // check if the flexible content field has rows of data
    if( have_rows('flexible_row_flexible') ):
         // loop through the rows of data
        while ( have_rows('flexible_row_flexible') ) : the_row();
    		//check if flexible row number equals random row number. 
    		if ( $flexible_row_number == $flexible_row_rand ):
    			if( get_row_layout() == "layout"):
                            //If they do equal, add 1 to $flexible_row_number;
    		else :
    			//If they dont equal, add 1 to $flexible_row_number;
  • Also solved a problem where the value in the colorpicker (not the input field) gets nulled after each post update.

    Above code updated.

  • Eureka!

    Thanks to @ractoon and this snippet i managed to solve it:

    This is how my function looks right now:

    In my child themes functions.php i declare the colors:

    // Adds client custom colors to WYSIWYG editor and ACF color picker. 
    $client_colors = array(

    Then in my main themes functions.php:

    global $client_colors;
      array_push($client_colors, "FFFFFF", "000000");
      function change_acf_color_picker() {
        global $parent_file;
        global $client_colors;
        $client_colors_acf = array();
        foreach ( $client_colors as $value ) {
          $client_colors_acf[] = '#'.$value;
        $client_colors_acf_jquery = json_encode($client_colors_acf);
        echo "<script>
          acf.add_action('ready append', function() {
            acf.get_fields({ type : 'color_picker'}).each(function() {
                color: $(this).find('.wp-color-picker').val(),
                mode: 'hsv',
                palettes: ".$client_colors_acf_jquery.",
                change: function(event, ui) {
                  $(this).find('.wp-color-result').css('background-color', ui.color.toString());
      add_action( 'acf/input/admin_head', 'change_acf_color_picker' );

    One problem remains though: when i click(not drag circle) on the colorpicker, it seems to hold the old color value from when i’ve grabbed the circle and dragged it around. This becomes obvious when i drag the vertical slider.

  • Kudos to you guys for trying to solve this. I tried above solution but can’t get it to work 100%.

    I managed to solve to things:

    1. When changing palettes the mode in iris changes aswell. i solved this by adding: mode: ‘hsv’,(See documentation: This is standard in wpColorPicker that acf uses.
    2. Sometimes the values in the hex value box didn’t change when i did changes on the color picker, i think that is solved now.

    See my revised jquery code below:

              if ($('.acf-color_picker').length) {
                $('.acf-color_picker').each(function() {
                  $( this ).iris({
                    mode: 'hsv',
                    palettes: ['#e40571', '#4b63a4', '#ffcb05', '#fff', '#000'],
                    change: function(event, ui){
                      $(this).find('.wp-color-result').css('background-color', ui.color.toString());

    I use Flexible Content for some of my color picker fields and those are not initialized on page load. Therefore above hack doesn’t affect them.

    I think the best solution is to do these changes when ACF initializes.

    The only way i could accomplish this was to change the file: /wp-content/plugins/advanced-custom-fields-pro/js/input.min.js

    Which isn’t good since it will get removed on updates.

    I would really appreciate if Elliott or someone could help to solve this via a function or a plugin.

    Best regards

  • Aaah! PERFECT! Thank you Jochen!!!

  • @AlleyOop, acf-exported-fields.php is created when you go to Custom fields / Import/Export and click on “Download export file”. Then you have to include that file in your functions.php file. I don’t know of any way to translate the fields while they’re in the database though.

    Sorry for not replying about the spinning wheels. I guess it got sorted on some update! Is there a more dynamical way of translating the fields in backend now? It would be great to have all the text-strings automatically wrapped in “translation tags” upon export. Labels, instructions etc.

  • I’ve been waiting for this release as well, but now that it’s here i can’t find how to translate an options page? Can Elliott or anyone else explain how to start translating it? 🙂

  • There we go!

    Including the exported fields inside an init function did the trick:

    add_action('init', 'load_exported_fields');
    function load_exported_fields(){
    	include 'acf-exported-fields.php';

    I would like to do a request.

    As i mentioned before, you have a function that wraps certain fields in __() in your nightly build in the file:
    /core/controllers/export.php on line 387:

    // add the WP __() function to specific strings for translation in theme
    				$html = preg_replace("/'label'(.*?)('.*?')/", "'label'$1__($2)", $html);
    				$html = preg_replace("/'instructions'(.*?)('.*?')/", "'instructions'$1__($2)", $html);

    Could you make this include other necessary fields as well? For example: ‘title’, ‘choices’, ‘sub_fields’, ‘layouts/sub_fields’?

    Or are you planning on some other way to translate fields?

    I would also like to report a bug.
    When i export fields that have the following location values they show up on every page with a loading sign going on and on, see attached file. Do you know why?

    'location' => array (
    			array (
    				array (
    					'param' => 'options_page',
    					'operator' => '==',
    					'value' => 'acf-options-admin',
    					'order_no' => 0,
    					'group_no' => 0,
    				array (
    					'param' => 'user_type',
    					'operator' => '==',
    					'value' => 'administrator',
    					'order_no' => 1,
    					'group_no' => 0,

    Thank you Elliot!

  • Also, the title of the register_field_group needs to be translatable.
    And Layouts/Sub fields for Flexible content fields.

    Elliot, am i missing something obvious or is the theme not supporting translatable fields fully yet?

  • I really need to fix the choices and sub_fields/label and instructions as well.
    Any idea how i can do that?

    I realized what the above fix does and with that you wouldn’t have to export the fields for translation. Well for the Po edit program to pick up the strings but that maybe can be done in some other way? If the end-purpose is to translate the fields and not to translate exported fields that is to say.

  • Perfect! That did the trick for me!

    However, i need to translate ‘choices’ and ‘sub_fields’ as well.

    How can i do this?

  • The latter.
    My poedit program is picking up the fields but the data isn’t being translated.

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