Support

Account

Register Login

Home › Forums › Search › Search Results for 'Wysiwyg'

Search Results for 'Wysiwyg'

topic

  • Unread

    Issue with WYSIWYG fields switching between visual and text modes

    In a site with ACF custom fields in various templates, we experience a strange limitation only with certain WYSIWYG fields when editing, between visual mode and text mode on the field.

    The admin can select a certain part of the visual mode content in the WYSIWYG field and switch to text mode to see that same content highlighted, in most cases.

    But in only certain fields, this does not work. Unfortunately it is an issue on the ones with lengthy content in them, so if the admin needs to select a sentence and work on the div code or insert some corrections via text mode, they cannot do this easily. Each time they try to select the text tab, it just scrolls back up to the top of the content and without any highlighted section she was working with. So she has to manually scroll down and hunt for the content she wanted to edit again.

    I would have normally dismissed this assuming it was not a supported feature, but it works just fine in the convenient way (sort of bookmarking where you were editing within the field) on all other fields except for a few of them.

    What could the cause be? Is there any known issue that prevents the switch from visual to text mode from working consistently to highlight where you were editing inside that field?

  • Helping

    Wysiwyg Editor prints tags #$%&

    Shouldn’t this field just work?? It’s suppose to be a WordPress Visual/Text editor that just works allowing for formatting and even adding media… but it doesn’t.

    Solutions seem to be some arcane code that needs to be added to functions.php which can be confusing and difficult to implement. Help!!!!

    Completely Frustrated and Stuck!

  • Solved

    Migrate from Custom Field Suite

    I’m trying to migrate some custom WYSIWYG fields from the Custom Field Suite plugin into ACF. I’ve generated some new WYSIWYG ACF fields with the same name as the CFS fields.

    All of information seems to appear in both CFS and ACF fields ok, but when I view the ACF content on the front of the site, the content is not rendered with any html, and the shortcodes don’t work.

    I’ve managed to get the shortcodes to work using
    echo do_shortcode($extra_product);
    …but the text content is just displaying as unstyled content (no html).

    If I open and resave any of the pages, then the problem is solved, but I really don’t want to go through hundreds of pages resaving them – does anyone know of a way to somehow refresh this field content, and resave multiple pages all in one go?

    Any ideas much appreciated.
    Many thanks

  • Solving

    Custom field type where I can use Gutenberg Blocks

    Hi,

    I am using a field type “Wysiwyg Editor”. But I would like to have a textarea with Gutenberg Blocks. Is this possible with this plugin?

    Thanks,
    Francisco

  • Solving

    ACF Fields not working properly after updating to 5.5

    It seems as if nearly all of my ACF fields are broken after updating to WordPress 5.5. Issues I’ve noticed so far:
    Wysiwyg editor: Add media button doesn’t work. Visual and Text tabs do not work. Nothing happens when I click these buttons. I can edit text in the field, and the formatting buttons(center, bold, etc) seem to be working
    Link Field: can not add a link to empty field. Can not edit field with existing link. Can not remove link from field. Nothing happens when I click these buttons.
    Image field: same issues as link field
    Button group field: Clicking on the buttons does nothing.

    EDIT: After some more testing, it appears that this issue is coming from the SEO Ultimate Plus plugin that I’m using on my sites. When I disable this plugin, everything works as normal. I’m assuming the SEO plugin is preventing the ACF scripts from running.

  • Solving

    WP 5.5.0 and ACF Pro, depricated function

    I upgraded to Wp 5.5.0 and now i see there is a depricated function in ACF PRO

    plugins/advanced-custom-fields-pro/includes/fields/class-acf-field-wysiwyg.php
    #87
    if( function_exists(‘wp_make_content_images_responsive’) ) {
    add_filter( ‘acf_the_content’, ‘wp_make_content_images_responsive’ );
    }

    I now get the notification
    Deprecated: wp_make_content_images_responsive is verouderd sinds versie 5.5.0. Gebruik in plaats daarvan wp_filter_content_tags().

    when is there a fix?

  • Unread

    Filtering through multiselect options in a repeater field

    Hi, I’m integrating a form of $_POST method with ajax filtering, to filter through repeater filed in all posts. so i’m not filtering posts (always all posts are displayed), just filtering inside each post.

    the repeater field contain two sub fields – multiselect and Wysiwyg Editor.
    Now, according to what the user selected in the front-end form, if it’s equal to a post multiselect values, it should display the Wysiwyg Editor field of the matching multiselect.

    I have this working without multiselect. but with the multiselect, i can’t get a conditional to be ALL selected filters values, to be the exact match of ALL multiselect values.
    So the result i get, as it is in a foreach loop, is multiple Wysiwyg Editor fields.

    I tried a lot of things, this is an example code of one of them:
    (‘cond_options’ – multiselect
    ‘description’ – Wysiwyg Editor’
    ‘ weather/sky/night’ – filters values)

    
if ( have_rows('cond-repeater') ):
   while (have_rows('cond-repeater') ) : the_row();

        $select_options = get_sub_field('cond_options');
        $selectdesc = get_sub_field('description');

            if( $select_options ):
               foreach( $select_options as $select ):
                    if( isset( $_POST['weather'] ) && $_POST['weather'] && isset( $_POST['sky'] ) && $_POST['sky'] && isset( $_POST['night'] ) && $_POST['night'] == $select  ){
                        echo $selectdesc;
                    }  
            echo $select; //just to see the output of selected options
                 endforeach; 

            endif; 

    endwhile;
endif;

reply

  • We experience the same issue on WP 6.8.2, ACF Pro 6.5.0.1 and Firefox 142.0.1.

    We tried to activate the checkbox to delay the initialization of TinyMCE (setting in the presentation tab of the WYSIWYG-editor-field). So now the editor is only loaded when you actually click on it, which seems to solve the issue in our case.

  • The issue appeared with WordPress 6.7.x and is still present in WordPress 6.8.x. With WordPress 6.6.x, there were no problems.

    The workaround suggested by benalia – check “Delay Initialization” for WYSIWYG fields – only provides a temporary fix, because as soon as TinyMCE is loaded in a WYSIWYG field, the issue comes back.

    Is there anything planned to fix this ? In WordPress core ? In ACF ?

  • 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.

  • I’m experiencing exactly the same bug on several WordPress sites. When updating from version 6.6.2 to 6.7, on Firefox, the ACF (PRO) WYSIWYG fields randomly (or at least I haven’t identified the exact trigger) display no content in visual mode. In text mode, the content is there, but when switching back to visual mode, it disappears, and the well-known JS console error appears.

    I’ve updated both WordPress and ACF PRO, but the issue is still present.

  • Dear all,
    I get the same issue, i agree that it is particularly annoying for pages with a lot of content

    # solution :
    On each WYSIWYG field, in the “Presentation tab”
    check the option : “Delay Initialization, TinyMCE”

  • @benplum I believe I also experienced this when the next blocks are below the ACF blocks with a WYSIWYG field. I was on a video call adding stuff at the bottom of a page, when the cursor jumped to my accordion ten feet above the current position 🙂 .

  • It seems to occur when starting the insert block process above an existing ACF block that contains a WYSIWYG in Visual mode, focus is dropped down to the next TINYMCE instance. Starting the insert block process below all ACF WYSIWYGs (or if the WYSIWYGs are in Text mode) does not shift focus.

  • When creating the WYSIWYG field, I activated ‘Delay Initialization, TinyMCE will not be initialized until field is clicked’ in the Presentation tab. This fixed it for me.

  • We also have this problem recently and the cursor always jumps to the last WYSIWYG field in our custom ACF blocks. This is particularly annoying for pages with a lot of content

  • @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.

  • I use the WYSIWYG field inside a repeater for an ACF block, so naturally, I also have multiple instances of the WYSIWYG field on a page. I suffer from the same issue. As soon as I hit Enter anywhere in Gutenberg, my cursor jumps to the last WYSIWYG field in my ACF block. There is also a GitHub issue describing the same issue.

  • This is still an issue with WP 6.7+. ACF blocks that have WYSIWYG fields within them will throw a JS error if the initial view state for that block is Edit mode. Setting SCRIPT_DEBUG to false fixes the issue.

    I’ve done a bit of debugging and it looks like the textarea field IDs for the WYSIWYG fields do not update on page load with SCRIPT_DEBUG enabled. The field IDs are still set to something like “acf-editor-677c024e3e39b” instead of “acf-editor-179”. Disabling SCRIPT_DEBUG or swapping between the Preview and Edit modes will fix the broken field.

  • Apologies for resurrecting an old thread, but I am still seeing this error on:
    – WordPress 6.7
    – ACF Pro 6.3.11
    – Firefox 132.0.2 (both Windows 10 and macOS)

    I am testing on a fresh install of WordPress using the stock Twenty Twenty-five theme with only ACF Pro enabled. I created a single field group with a single WYSIWYG field.

    When opening the editor, the field appears to load normally, but after refreshing the field does not show any content and becomes unresponsive to any input in the main editor area, although I am able to click on the buttons in the TinyMCE toolbar as well as the Visual/Test toggle.

    There are no errors in the Firefox console, only the following which appear to be warnings:

    Layout was forced before the page was fully loaded. If stylesheets are not yet loaded this may cause a flash of unstyled content. markup.js:250:53
This page uses the non standard property “zoom”. Consider using calc() in the relevant property values, or using “transform” along with “transform-origin: 0 0”. post.php
JQMIGRATE: Migrate is installed, version 3.4.1 load-scripts.php:5:981
downloadable font: Glyph bbox was incorrect (glyph ids 11 19 20 21 55 58 79 96 101 115 116 120) (font-family: "tinymce" style:normal weight:400 stretch:100 src index:1) source: http://acf-wysiwyg-issue-test.local/wp-includes/js/tinymce/skins/lightgray/fonts/tinymce.woff
Layout was forced before the page was fully loaded. If stylesheets are not yet loaded this may cause a flash of unstyled content. ce917c4a-18c0-4680-a2b9-2d1ec833f72d
MouseEvent.mozPressure is deprecated. Use PointerEvent.pressure instead. block-editor.min.js:21:494336
MouseEvent.mozInputSource is deprecated. Use PointerEvent.pointerType instead. block-editor.min.js:21:494336
MouseEvent.mozPressure is deprecated. Use PointerEvent.pressure instead. tinymce.min.js:2:8857
MouseEvent.mozInputSource is deprecated. Use PointerEvent.pointerType instead. tinymce.min.js:2:8857

  • So it turns out I was calling the text as follows:
    <p><?php echo $text; ?></p>
    But because the WYSIWYG already includes p-tags, for some reason WordPress/ACF then decides to add empty p-tags before AND after the paragraph.
    Anyway, I removed the p-tags from my code and now it’s working as intended 🙂

  • I’ve had the same problem but fixed it with wpautop(). I had to run the data I got from the REST API through another function anyway and as I knew when to expect a return from a WYSIWYG field, I could return it with wpautop().

    Like so:

    
function format_wysiwyg($value, $sType = 'default')
{
  if ($sType === 'wysiwyg') :
    return wpautop($value);
  else :
    return $Value;
  endif;
}

    I called it with format_wysiwyg($Value_from_rest, 'wysiwyg') if I knew it was WYSIWYG and just format_wysiwyg($Value_from_rest) if it wasn’t.

    Not very smart, but it worked for my case.

  • You can target the field type:

    acf.addAction('load_field/type=wysiwyg', function(field) {

///.. the code from above
})

  • That seems pretty heavy handed, and also has to be implemented on a field-by-field basis.

    I was kind of hoping for something that would turn off that bit of javascript that converts a pasted URL into the embedded video before it ever happens, rather than letting it exist and then re-filtering to remove it on every keystroke or value change.

    Was also hoping for a way to target all WYSIWYG Basic fields instead of individual field keys.

    But maybe that’s just not possible.

  • Thank you @hube2. I noticed this indeed makes my forms work. Also, if I have a wysiwyg field and I get it like the_sub_field it will work without errors but only if I don’t have any formatting. As soon as I actively align the text left, right or justify i get errors like below. If I call the field with echo get_sub_field these errors don’t show up:

    Detected Potentially Unsafe HTML Modification
#0 /home/client1/web/client1website.nl/public_html/wp-includes/class-wp-hook.php(324): print_backtrace_for_unsafe_html_removal('...', '...', Array, false)
#1 /home/client1/web/client1website.nl/public_html/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters(NULL, Array)
#2 /home/client1/web/client1website.nl/public_html/wp-includes/plugin.php(517): WP_Hook->do_action(Array)
#3 /home/client1/web/client1website.nl/public_html/wp-content/plugins/advanced-custom-fields-pro/includes/api/api-template.php(942): do_action('...', '...', '...', Array, false)
#4 /home/client1/web/client1website.nl/public_html/wp-content/themes/client1/page.php(108): the_sub_field('...')
#5 /home/client1/web/client1website.nl/public_html/wp-includes/template-loader.php(106): include('...')
#6 /home/client1/web/client1website.nl/public_html/wp-blog-header.php(19): require_once('...')
#7 /home/client1/web/client1website.nl/public_html/index.php(17): require('...')

    Can I expect any impact on performance when calling all fields with echo get_field / echo get_sub_field?

Viewing 25 results - 176 through 200 (of 1,299 total)
1 2 3 … 7 8 9 … 50 51 52