Custom Fields
Re-Envisioned
Support General WYSIWYG Editor Not Working Correctly

  • Creator
    Topic
  • #23716
    Resolved SLG Marketing
    Participant

    I’ve registered a WYSIWYG metabox on a page post type but the visual editor isn’t working. If I swap to the “text” tab, I can type in there and the details are saved, but nothing is shown in the visual editor section.

    Screenshot showing issue

    Here is the code I’m using to register the metaboxes.

    
    $meta_boxes[] = array(
                'title' => 'Pedestal Details',
                'id'=>'pedestal_details',
                'post_types' => 'page',
                'fields' => array(
                    array(
                        'name'=>'Select Image Map',
                        'id'=>'image_map',
                        'type'=>'select',
                        'options'=>array(
                            'test'=> 'Test'
                        )
                    ),
                    array(
                        'name'=>'Hotspot Details',
                        'id'=>'hotspots',
                        'type'=>'group',
                        'clone'=>true,
                        'sort_clone'=>true,
                        'add_button'=>'Add a Hotspot',
                        'fields'=>array(
                            array(
                                'name'=>'Hotspot Title',
                                'id'=>'hotspot_title',
                                'type'=>'text'
                            ),
                            array(
                                'name'=>'Hotspot Content',
                                'id'=>'hotspot_content',
                                'type'=>'wysiwyg'
                            ),
                            array(
                                'name'=>'Hotspot Image',
                                'id'=>'hotspot_image',
                                'type'=>'image_advanced',
                                'multiple'=>false
                            ),
                            array(
                                'name'=>'Hotspot Products',
                                'id'=>'hotspot_products',
                                'type'=>'post',
                                'post_type'=>'product',
                                'clone' => true,
                                'add_button'=>'Add a product'
                            )
                        )
                    ),
                    array(
                        'name'=>'Select a download',
                        'id'=>'pedestal_downloads',
                        'type'=>'post',
                        'post_type'=>'download',
                        'clone' => true
                    )
                )
            );
    

    What have I missed?

Viewing 10 replies - 21 through 30 (of 44 total)
  • Author
    Replies
  • #23920
    stijlXpres
    Participant

    Hi,

    Yes! Just tested in on local installation. This seems to fix the bug!

    #23921
    Teia Local Studio
    Participant

    Hello Ahn!

    No, it is not working for me (although I have not tested on a clean default themed WordPress). Behavior:

    If I open a post with already WYSIWYG content on it, the VISUAL tab do not load at all, just the CODE tab.

    If I create a brand new post and add content, in VISUAL all is OK, I can write and yes, I can switch between CODE and VISUAL again. But in the moment I do save the post and screen reloads, the VISUAL is completely gone (I mean the textarea editor field too), but code is there.

    On this very recent post, if I SHIFT+Refresh, the VISUAL field is back on track, however the content on it is rendered all in white color (can’t see anything unless I select with mouse) and it is formatted in HTML, I can see the <p> tags, etc etc, exactly as the same on CODE tab.

    Note: the meta-data IS saved correctly to the database.

    But my theme situation could be interfering perhaps… I do register the metabox based on a IF/ELSE who looks what $POST_ID is being edited. It’s something I needed to do in my theme for other reasons:

    
    $post_id = null;
    if ( isset( $_GET['post'] ) ) {
        $post_id = intval( $_GET['post'] );
    } elseif ( isset( $_POST['post_ID'] ) ) {
        $post_id = intval( $_POST['post_ID'] );
    }
    
    if ($post_id == 111) {
        $meta_boxes[] = array(
            'id' => 'mb-for-post-111',
            (...)
        );  
    } else {
        $meta_boxes[] = array(
            'id' => 'mb-for-other-posts',
            (...)
        );  
    }
    

    ALSO: I do erradicate anything related to GutenBerg on my themes. Using the plagued new editor is absolutely no option for me. I run this code to remove it:

    
    // Begone, GutenBerg!
    add_filter('use_block_editor_for_post_type', '__return_false', 10);
    // Don't load GutenBerg-related stylesheets.
    add_action( 'wp_enqueue_scripts', 'remove_block_css', 100 );
    function remove_block_css() {
        wp_dequeue_style( 'wp-block-library' ); // WordPress core
        wp_dequeue_style( 'wp-block-library-theme' ); // WordPress core
        wp_dequeue_style( 'wc-block-style' ); // WooCommerce
        wp_dequeue_style( 'storefront-gutenberg-blocks' ); // Storefront theme
    }
    

    I will try in a matter of minutes your new JS including the metabox on a standard way (yet on my theme) and also on a regular clean WordPress install, with the default theme.

    See you soon.
    Thanks so far.

    #23923
    Gunvor
    Participant

    My problem from post 23787 was not solved too

    #23924
    Teia Local Studio
    Participant

    Ouch.

    I think I found out the problem.

    I have a snippet of code in my functions to FORCE REMOVE of EMPTY <p>’s. It seems this is what is causing me trouble. If so —-> YES, your current new WYSIWYG.JS is fixing the problem.

    
    function remove_empty_p( $content ){
        // clean up p tags around block elements
        $content = preg_replace( array(
            '#<p>\s*<(div|aside|section|article|header|footer)#',
            '#</(div|aside|section|article|header|footer)>\s*</p>#',
            '#</(div|aside|section|article|header|footer)>\s*<br ?/?>#',
            '#<(div|aside|section|article|header|footer)(.*?)>\s*</p>#',
            '#<p>\s*</(div|aside|section|article|header|footer)#',
        ), array(
            '<$1',
            '</$1>',
            '</$1>',
            '<$1$2>',
            '</$1',
        ), $content );
    
        return preg_replace('#<p>(\s|&nbsp;)*+(<br\s*/*>)*(\s|&nbsp;)*</p>#i', '', $content);
    }       
    add_filter( 'the_content', 'remove_empty_p', 20, 1 );
    

    I will test a bit more and will return soon.
    Need to leave the house for a moment.

    #23927
    JC
    Participant

    The new js is working fine for me (#23854). Thank you!

    #23928
    Teia Local Studio
    Participant

    Update:

    I tried including the WYSIWYG metabox in my theme using both ways, the regular method and with a IF/ELSE/$post_id condition (as mentioned above):

    — Removed my custom snippet for blank <p>’s, it was not it the culprit, problem still there
    — Emptied the cache, nothing
    — When screen reloads, after saving, I see the visual editor on the VISUAL tab for a millisecond, then it disappears, like if it was a refresh applied on the element

    So, tried to inspect the new WYSISYG.JS file you shared this morning and solved my problem by commenting/removing the following:

    // Force re-render editors. Use setTimeOut to run after all other code. Bug occurs in WP 5.6.
    $( function() {
        setTimeout( function() {
            $( '.rwmb-wysiwyg' ).each( transform );
        }, 0 );
    } );
    

    But of course, this is not a ideal solution.
    I tried also changing the number param of the setTimeout function… Anything higher than 12, 13, solves the problem. Putting like 20 or even 999 works too.

    But again, not ideal.
    Oh my…
    =(

    IN TIME: No JS errors show up in the console.

    #23930
    Anh Tran
    Keymaster

    Hi Teia,

    The code you commented is used to re-initialize the editors. In Gutenberg, editors are moved around the DOM, which makes them broken.

    The number is just the delay in milliseconds to make the code run after editors are moved by Gutenberg. It’s fine to increase to 100-200 😉

    Are you using the classic editor?

    I’ll try to invest more in that tomorrow. If I found nothing, maybe increasing the delay to 100 is the solution.

    #23931
    Anh Tran
    Keymaster

    Hi Gunvor, I’ll fix your bug tomorrow. I don’t think it’s hard. Please wait.

    #23934
    Teia Local Studio
    Participant

    Ahn,

    I use only — and solely — the classic editor, everywhere. The GutenBerg Block Editor is not an option to me. I turn it off completely on my themes.

    So, as for now, I will change the value to 100 and I will wait for your final word on this.

    For curiosity — Do you think is it possible to modify the delay value using a external JS file loaded on admin using add_action(‘admin_enqueue_scripts’, …);??

    Thanks so much for your always prompt help!
    G.

    #23945
    Anh Tran
    Keymaster

    Hey guys, I’ve complete the fix for the editor. Now you can try it here – just download it and overwrite the js/wysiwyg.js file in the plugin.

    What I’ve done:

    • Disable re-rendering for classic editors to avoid extra work as Teia reported.
    • Fix the default editor settings as JC reported.
    • Apply re-render after reorder editors, or groups that contain editors.
    • Remove the extra CSS of the editors to speedup rendering. It’ll be a huge benefit if you have many editors on the page (such in cloneable groups). This fix requires updating the wysiwyg.php file as well.

    I also update the fix for validation, e.g. required rule now working for editors as well.

    I’ve tested with single field, inside cloneable groups and in blocks. Please help me to test with your cases and let me know if you find any bug.

    Thanks,
    Anh

Viewing 10 replies - 21 through 30 (of 44 total)
  • You must be logged in to reply to this topic.