Support

Account

Register Login

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

Search Results for 'Wysiwyg'

reply

  • I just tested this on a site with only ACF installed and running a bare 2015 theme and there does not appear to be any problem with the wysiwyg editor or TinyMCE.

    Try deactivating other plugins and see if you can determine were the incompatibility is.

  • I just found this, maybe you should give the author of this plugin some input https://github.com/lukechapman/acf-inline-wysiwyg

  • Actually now I see that the soution doesn’t reallt work for me. I’m trying to apply this validation on a wysiwyg field and the strlen always returns 0 characters.

    Itamar

  • Hi guys

    Issue update:

    I’ve logged into a few users websites, but am unable to replicate the issue!
    – The WYSIWYG editors load just fine

    The only time I’ve been able to replicate the issue is when I screen-shared with another user to view his wp-admin. He was running windows and the wp-admin page took quite a while to load.

    I’m starting to think the issue may be due to the computer / browser load times.
    Maybe my mac is loading the page too quickly and the issue never triggers.

    Can you please be sure to note your details:
    ACF version:
    WP version:
    OS:
    Browser inc version:

    Thanks
    Elliot

  • Hi guys

    Thanks for all the comments.
    I’ve just had some luck replicating the issue and will most likely have a fix out today.

    Yes, the issue is triggered from the acf.fields.wysiwyg.add_events function

  • @jannej

    I’m currently searching for a solution to a similar issue. My problem is specifically the <br> and <br /> tags. They are still in my WYSIWYG editor on the admin side, but do not render on the page 100% of the time. I’ll post up here if I find something that helps.

  • Hi @pshahwpcodal-com

    The value in the database is correct. The paragraph tags you saw on the backend are generated by the content editor, but the real data doesn’t have it.

    The WYSIWYG field has a feature that will convert a new line into a paragraph tag automatically, but it seems not working on your site. Maybe there’s a function that prevents it. Could you please try to reproduce the issue on one of the WordPress’ stock themes (like Twenty Sixteen) with other plugins deactivated? If it disappears, then you can activate the theme and plugins one by one to see which one causes the issue.

    As a workaround, you can add the paragraph tags like this:

    echo wpautop(get_field('short_description_2'));

    I hope this helps 🙂

  • Hi @pshahwpcodal-com

    Could you please share the example of the text you’ve entered in the WYSIWYG field and the result in the database? Don’t forget to use the code wrapper if you want to share it here.

    Also, could you please share the URL to the page where you show the field?

    Thanks 🙂

  • Hi @wyclef

    First, you need to copy the “tinymce.code.min.js” to anywhere you see fit. For example, you can put it in your child theme: “wp-content/themes/your-child-theme/js/tinymce.code.min.js”.

    After that, you need to register this file to tinyMCE like this:

    add_filter( 'mce_external_plugins', 'my_acf_mce_external_plugins', 20, 1 );
function my_acf_mce_external_plugins($plugins){
    // global
    global $wp_version;
    
    // WP 3.9 an above
    if( version_compare($wp_version, '3.9', '>=' ) ) {
        
        // add code
        $plugins['code'] = get_stylesheet_directory_uri() . '/js/tinymce.code.min.js';

    }
    
    // return
    return $plugins;
}

    Then, you need to add the button to the toolbar like this:

    add_action('acf/input/admin_footer', 'my_acf_enable_code_plugin');
function my_acf_enable_code_plugin() {

    ?>
    <script type="text/javascript">
    (function($) {
        
        $(document).ready(function(){
            acf.add_filter('wysiwyg_tinymce_settings', function( mceInit, id ){
                
                // Add code to toolbar
                mceInit.toolbar2 = mceInit.toolbar2 + ",code";

                // return
                return mceInit;
                
            });
        });
        
    })(jQuery);    
    </script>
    <?php    
    
}

    I hope this helps 🙂

  • Hi @silverdarling

    You should be able to do it like this:

    add_action('acf/input/admin_head', 'my_acf_modify_wysiwyg_height');

function my_acf_modify_wysiwyg_height() {
    
    ?>
    <style type="text/css">
        .acf-field-1234567890abc iframe{
            height: 600px !important;
        }
    </style>
    <?php    
    
}

    Where acf-field-1234567890abc is the element ID of your WYSIWYG field.

    Thanks 🙂

  • Hi @magicstick

    Thanks for the reply.
    There is still too much ambiguity around this issue.

    Can you please create a support ticket with a more details description of the issue:
    http://support.advancedcustomfields.com/new-ticket/

    – does the issue occur editing a post?
    – does the issue occur editing a user?
    – does the issue occur editing a acf_form()?
    – What is needed to replicate the issue? A simple wysiwyg field? Or within a repeater?
    – have you disabled all other plugins / themes to test conflict?

    Thanks
    Elliot

  • Hi Elliot. My issue with tinymce seems to have persisted unfortunately. See my above post.

    Just to confirm my scenario for debugging:

    • If visual editor is default tab it’s not working (switching to text tab works)
    • If text tab is default, I can switch to visual tab and it works.
    • It’s a form in a user Add/Edit form. However I am pulling the acf_form to a front end template page and behavior is the same.
    • I’ve tried deactivating all my plugins apart from ACF. No change.
    • I’ve tried removing all other jQuery based fields from my field group. No change.
    • WYSIWYG working fine on pages flexible fields. (don’t get that at all)

    Let me know if there is anything else I can do to help debug from my end. I’m out of ideas here.

  • Can I just add more fuel to the fire here, maybe my info will help identify any issues.

    What I am experiencing is on acf_forms frontend. If The user is defaulted to the ‘visual tab’ on the WYSIWYG editor when the page loads the WYSIWYG fails to fully instantiate. However if the user is defaulted to the ‘text’ tab and then clicks on the ‘visual’ it loads fine.

    See attached screen grab of my console error when you click on the ‘visual’ tab when the WYSIWYG when you the page load brings in the ‘visual’ tab as default

    Screen-Shot-....jpg

  • Height of wysiwg is hardcoded in wysiwyg.php

    Path\wp-content\plugins\advanced-custom-fields-pro\fields\wysiwyg.php:
  255  		
  256  		// get height
  257: 		$height = acf_get_user_setting('wysiwyg_height', 300);
  258: 		$height = max( $height, 300 ); // minimum height is 300

    You can’t easily change that with css because it produces inline css , viz –

    <textarea id="acf-editor-gtg6gtg6gtg62" class="wp-editor-area" name="acf[field_gtg6gtg6gtg62]" style="height:300px;">wysiwyg content here</textarea>

    Good thing is that wysiwyg.php looks like its primed to go for adding wysiwyg height via admin interface.

  • Bump!

    My captions for images added into wysiwyg fields have suddenly stopped appearing. A few days ago they were fine, I think, but today they are suddenly gone. In fact, WordPress is no longer wrapping the captioned images in a <figure> tag so the whole layout has gone awry. It is basically treating captioned images as uncaptioned images. I am not 100% sure it is not due to something I have done, but if anyone can give advice would be v grateful. All my plugins and theme etc are up to date. THe site is not live, it is on mamp, still being built.

    If I add an image in the standard (non acf) wysiwyg, captions do appear.

    UPDATE

    I think I may have found the cause. Plugin called wp typography, if I deactivate it, the captions reappear. Not sure yet, maybe there is a compatibility issue.

  • I deactivated all plugin’s except ACF and now it works. Then I activated all my plugins one by one and every time I checked if the WYSIWYG fields where back to normal and after checking all one at a time it now (looks) like its working again.

    Maybe this will fix your issues as well?

  • I am getting one JS error with ACF 4

    Error: Syntax error, unrecognized expression: #wp-wysiwyg-acf-field-wysiwyg_(copy)-57bf4a104c01f-wrap

    and this error is cause by the way I created the test group I used, but it doesn’t seem to be breaking anything.

  • Thanks for your help,

    I am trying to make it work with qtranslate (I have qtranslate-X and acf qtranslate). So I disabled qtranslate and the ACF WYSIWYG field works well even if the error still appears in js console. But when I reactivate qtranslate, all the WYSIWYG fields are missing the toolbar.

  • I just tested this on a site with only ACF and WP, I tested with both ACF4 and ACF5. I’m not getting this error. Have you tried deactivating plugins or changing themes?

    Are the WYSIWYG fields at the top level or are they in a repeater or something? What are the settings for the fields. If you give me some more information I’ll try more testing if I am able to. I don’t have the flex field for ACF 4 though so I can only go so far with that.

  • I just tested this on a site with only ACF and WP, I tested with both ACF4 and ACF5. I’m not getting this error. Have you tried deactivating plugins or changing themes?

    Are the WYSIWYG fields at the top level or are they in a repeater or something? What are the settings for the fields. If you give me some more information I’ll try more testing if I am able to. I don’t have the flex field for ACF 4 though so I can only go so far with that.

  • Witt the optimization built into MySQL and the WP tables (all having proper indexes) for performing the queries that are done, there really should be little effect on the speed of a site based on the database size. I’m not sure where you heard that it would. I have some sites with huge databases and as many as 100 fields on some post types using flexible content fields and repeaters with no performance issues on the front end. On one site there is a repeater field and each of these repeaters can have up to 7 WYSIWYG editors and associated fields for a total of about 70 fields per repeater and there is not limit to the repeaters. There are as many as 20 of these repeaters on some posts for a possible total of over 1000 fields. Like I said, I don’t see any performance issues on the front end. If there is any performance loss then it is undetectable.

    On the other hand, a search using the standard WP search that does a %LIKE% query for every word in a search request on 100K+ posts…. that’s going to die, and this has nothing to do with ACF. There is no index on “Content” fields in the database. I would suggest that you look for a different way to do site searches on a site this size.

    If you do a searches and do some research on it you will find that MySQL does not see performance issues on large databases when the tables are indexed properly.

    The back end is a different story entirely, and this really doesn’t have anything to do with ACF, but with the way that WP handles updating the post meta values…. one at a time. ACF simply uses what WP makes available. You would see the same problem whether you use ACF or custom build the custom fields yourself. Because of this, too many fields being submitted on a single admin page will likely cause you issues. That site I mentioned above with the more than 1000 fields on a post, those posts time out when hitting update, why, because WP does more than 3000 queries to update those fields (agian, WP, not ACF), and that does not include the field_key queries. Like I said, nothing to do with ACF. If I had built all these fields myself the result would be the same. That site was built a while ago and since that one I am extremely careful about how many fields I build into a single admin page. When I see that the number will be high I find an alternate way to do so, for example, creating multiple edit pages. I could have, for example, instead of using a repeater field in this case I could have created a hierarchical post type where the “Repeaters” were actually child pages. Although this would have more of an effect on front end performance because it would mean querying for those child pages.

    Hope that helps.

  • +1

    I am also having this issue. The first WYSIWYG area displays correctly, but the the ones following after that do not display because of the JS error.

    Error: Uncaught TypeError: Cannot read property ‘body’ of undefined
    Line: wp-tinymce.php?c=1&ver=4401-20160726:12

    Stack Trace

    getBody @ wp-tinymce.php?c=1&ver=4401-20160726:12
    add_events @ input.min.js?ver=4.4.8:2
    init @ input.min.js?ver=4.4.8:2
    (anonymous function) @ input.min.js?ver=4.4.8:2
    each @ load-scripts.php?c=1&load[]=jquery-core,jquery-migrate,utils,jquery-ui-core,jquery-ui-widget,wp-a11…:2
    each @ load-scripts.php?c=1&load[]=jquery-core,jquery-migrate,utils,jquery-ui-core,jquery-ui-widget,wp-a11…:2
    (anonymous function) @ input.min.js?ver=4.4.8:2

  • Having the same Issues. Just pitched the client to move away from Visual Composer for speed issues and now ACF Flexible Content with repeating WYSIWYG is causing 502 on post update hook.

  • Thanks John – however, a detailed solution came through (which I think you were pointing me towards) from James on [email protected] which does exactly what I want. Code is (to put in [theme]/functions.php) :

    function my_acf_load_value( $value, $post_id, $field ) {

 $content = apply_filters('the_content',$value);
 $content = force_balance_tags( $content );
 $content = preg_replace( '#<p>\s*+(<br\s*/*>)?\s*</p>#i', '', $content );
 $content = preg_replace( '~\s?<p>(\s| )+</p>\s?~', '', $content );

 return $content;
}

add_filter('acf/load_value/type=wysiwyg', 'my_acf_load_value', 10, 3);

    No more empty <p> tags in ACF Wysisyg fields!

  • You could add a filter to remove them, there is an example here for WP and this could easily be adapted to ACf using an acf/format_value filter for wysiwyg fields https://www.advancedcustomfields.com/resources/acfformat_value/

Viewing 25 results - 601 through 625 (of 1,298 total)
1 2 3 … 24 25 26 … 50 51 52