Support

Account

Forum Replies Created

  • Couldn’t agree more. But I appreciate you at least supplying the CSS to override those and provide a better UX.

  • Yeah, huge bummer. I can understand why they are having issues and how ridiculous it is that iframes are being used for this. It makes targeting nearly impossible. REACT WAS A MISTAKE haha.

    Anywho, maybe just make a patch for non-WYSIWYG-havin’ field groups. I could easily figure out how to manage my ACF fields knowing that WYSIWYG field wasn’t an option.

    Really does suck that I have about 25 sites that utilize ACF Blocks and Patterns. Just gonna stop using Patterns.

  • @hube2 your contributions to ACF and this forum have been monumental. I’ve been an ACF member since ~2014 and your name has always come up with wonderful answers and suggestions

    …but this request has been made countless times to the devs. Since the inception. People are resorting to this because it falls on deaf ears.

    Obviously with blocks and ACF Blocks, the need for a WYSIWYG editor has gotten smaller and smaller but after creating themes/blocks for countless clients, I can tell you, the demand for a clean interface and minimal WYSIWYG rich text editor is just as meaningful now.

    I still use this snippet to tackle this issue:

    function PREFIX_apply_acf_modifications() {
    ?>
      <style>
        .acf-editor-wrap iframe {
          min-height: 0;
        }
      </style>
      <script>
        (function($) {
          acf.add_filter('wysiwyg_tinymce_settings', function(mceInit, id, $field) {
            mceInit.wp_autoresize_on = true;
            return mceInit;
          });
          acf.add_action('wysiwyg_tinymce_init', function(ed, id, mceInit, $field) {
            ed.settings.autoresize_min_height = 100;
            $('.acf-editor-wrap iframe').css('height', '100px');
          });
        })(jQuery)
      </script>
    <?php
    }
    add_action('acf/input/admin_footer', 'PREFIX_apply_acf_modifications');

    and it works great in most cases. However, one quirk still persists.

    If I add a repeater row, the WYSIWYG is the correct height and the fields are all condensed to be the height of the largest field within that row.

    If I save and refresh the page, every field within the row is given a minimum height which I believe is being set based on the size ACF *thinks* the WYSIWYG field is. There ends up being a fair amount of white space below the WYSIWYG editor and each .acf-field has been given a minimum height CSS value.

    If I add a new row, or delete a row, it resizes all of the field heights to the correct minimum height and everything nice and tight.

    So the action to evaluate the current height of the fields, get the largest field height and set them all to that seems to be firing 1) when a new row is added or 2) when a row is deleted, but not when the page first loads.

    I’ve tried to modify when the action is called, whether init or admin_head, etc.

    Perhaps you can provide some insight as to when that hook/action gets called and if there’s another method to ensure that when ACF evaluates the field heights and sets their minimum, it’s accounting for the modified WYSIWYG field height on page load.

    Thanks.

  • Yeah, that’s wild. I spend all this time converting my acf_register_block_type() Blocks over to the new Block.json method because none of my theme.json default declarations were taking affect. I figured that was the reason.

    Turns out, WordPress gives you the keys to a car that can’t steer. Then they ask you why you would need a car to turn.

    Boy do I miss the good ol’ PHP days…. *insert old man yells at clouds gif*

  • Super strange but @hhenning’s suggestion helped lead me in the right direction, too.

    I removed those entries “meta-box-order_page” and “meta-box-order_post” but did not have success. I also found an entry called “metaboxhidden” and in the meta_value is clearly had an ACF field group key. Once I removed that the ACF fields appeared for that user.

    Thanks @hhenning

  • In case anyone is still searching this, I was able to accomplish it by going into phpMyAdmin and finding the tables, exporting them, and importing them into the new DB table.

    The real tedious part comes when you have to find each option’s “name” in the table. I had one options page, with 1 field, with a bunch of repeater rows, so it was really quick for me. If you have a lot of option values, this may not be the ideal scenario…

    In my case, the options were all under “options_clubs” as “Clubs” was the field’s name. Yours will vary and you will have to look in the DB table to find out what they are named. I am using it as an example.

    **Keep in mind you need to export/import your fields BEFORE this step.**

    1) Log into phpMyAdmin, and go to wp_options table of your OLD installation.
    2) Run the Query: SELECT * FROM wp_options WHERE option_name LIKE '%options_clubs%' where options_clubs will be your field name.
    3) Once it produces the rows, scroll down to where it says “Query Result Operations” and hit EXPORT
    4) Open up the export file it produces, find the SQL code where it is inserting values. It will begin with “INSERT INTO wp_options (option_id, option_name, option_value, autoload) VALUES …”
    5) Go into phpMyAdmin of the NEW database, go to SQL, and copy/paste that SQL query with all of the values, hit GO.
    6) The new values should be loaded into the DB and show up when you log into WordPress in your new Options page.

    Repeat for each field you have in an Options page.

    I hope this helps someone.

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