WYISWG editor do not work inside nested group on some instances

Support General WYISWG editor do not work inside nested group on some instancesResolved

Viewing 15 posts - 1 through 15 (of 17 total)
  • Author
    Posts
  • #46600
    Kulcsár PeterKulcsár Peter
    Participant

    In nested groups the WYISWG editor does not load correctly.

    I am facing this issue for couple of days now.
    I have tried other topics where similar problem was reported.
    But none of the methods helped.
    I have also tried Firefox instead of Chrome, the same WYISWG fields are not loading.

    Please see the attached screencast:
    https://www.berrycast.com/conversations/a39b743d-92a3-54b5-9d14-b3f46c1103a3

    #46601
    PeterPeter
    Moderator

    Hello Peter,

    Please enable cloneable for the WYSIWYG field and enable the option "Clone empty start" then check the issue again. Let me know how it goes.

    #46605
    Kulcsár PeterKulcsár Peter
    Participant

    Hi,

    I have already tried that.
    It's not working.

    https://komododecks.com/recordings/0tOUy2qUSIV7iMcGvvoY

    And I don't want to always click Add More... it's annyoing that I don't see the content right away.

    #46613
    PeterPeter
    Moderator

    Hello,

    I've escalated this issue to the development team for fixing. It will be included in the next update of our plugin.

    Thank you.

    #46652
    Kulcsár PeterKulcsár Peter
    Participant

    Hi,

    Thanks. There are issues with the Post field too.

    Also the Post - Select Advanced / Multiple field is not working. So we can't change the selected post.
    And there are performance issues too, the load of the editor when there are more WYSIWYG editors loaded increases significally.
    https://snipboard.io/joRpuX.jpg

    #46662
    PeterPeter
    Moderator

    Hello,

    Can you please export the field group to a JSON file and share it here? I will check the post field on my demo site. Following the documentation https://docs.metabox.io/extensions/meta-box-builder/#export--import

    #46667
    FEDFED
    Participant

    +1 this. We're seeing the same thing.

    #46684
    Kulcsár PeterKulcsár Peter
    Participant

    Hi Peter,

    Sure.

    Pls check also this screencast. This site loads for nearly 50 seconds because of the WYISWG fields.
    The same files are loaded for every WYISWG field, the initiator is the wp-tinymce.js
    /wp-includes/js/tinymce/skins/lightgray/content.min.css?wp-mce-49110-20201110
    /wp-includes/css/dashicons.min.css?ver=6.6.2&wp-mce-49110-20201110
    /wp-includes/js/tinymce/skins/wordpress/wp-content.css?ver=6.6.2&wp-mce-49110-20201110

    https://www.berrycast.com/conversations/21528261-e71d-5911-a286-0dbe1698df40

    Custom Field JSON file

    #46700
    Cecil AshiteyCecil Ashitey
    Participant

    Hi

    We are seeing instances of the plugin affecting the "Visual" tab when attempting to add content to a page.

    I understand that an update to the plugin will resolve the current issues. However, because it's critical that this issue is resolved, are you able to share a timeline for when the update will be made live, please?

    Thanks in advance.

    #46704
    PeterPeter
    Moderator

    Hello Peter,

    I see the slowdown issue of the field group when having more custom fields on the editing page. I will forward the issue to the development team to check it and improve the performance of the WYSIWYG field in the cloneable group.

    #46711
    pzapza
    Participant

    I'm also experiencing this. I worked around the white text issue with some custom CSS on admin side.

    Still have the issue switching between text/visual.

    Notably, and at least for me, the first WYSIWYG I expand (within a double nested, collapsed group) works fine. Any subsequent editors have the switching issue.

    #46713
    Grzegorz SidorGrzegorz Sidor
    Participant

    I found a temporary solution, but it slows down the editing page. It turns out that the ids for texarea for wysiwig are not created correctly.

    <textarea class="rwmb-wysiwyg wp-editor-area valid" rows="20" autocomplete="off" cols="40" name="sw_c_row[6][sw_c_col][1][sw_c_content]" id="sw_c_col_sw_c_content" aria-invalid="false"><div class="h-4 h-lg-1">34 lata wyzwań nauczyły nas, jak być lepszą organizacją, budować silną markę i wspierać naszych partnerów. Poznaj nasza historię.</div></textarea>

    In this case I have a clonable group in a clonable group. The textarea gets an id without the name of the parent group and without its sequence number. This creates multiple textarea with the same id, from which wysiwyg is called. Since multiple textarea have the same id, wysiwyg does not start fully for them.

    I solved this problem by modifying the wysiwyg.js script for the meta-box.
    /meta-box/js/wysiwyg.js
    In the file for the transform() function I added a line so that the isInBlock variable always has the value true, which changes the id to unique.

    function transform() {
    		var $this = $( this ),
    			$wrapper = $this.closest( '.wp-editor-wrap' ),
    			id = $this.attr( 'id' ),
    			isInBlock = $this.closest( '.wp-block, .components-panel' ).length > 0;
    			
            isInBlock=true;
    		// Update the ID attribute if the editor is in a new block.
    		if ( isInBlock ) {
    			id = id + '_' + rwmb.uniqid();
    			$this.attr( 'id', id );
    		}
    ...

    and in the load function I changed the re-render condition to fire not only for Gutenberg

    	// Force re-render editors in Gutenberg. Use setTimeOut to run after all other code. Bug occurs in WP 5.6.
    		if ( rwmb.isGutenberg ) {
    			setTimeout( () => $editors.each( transform ), 200 );
    		}else{
    			setTimeout( () => $editors.each( transform ), 20 );
    		}

    unfortunately this forces a re-render for each wysiwyg, which increases the time it takes to load them. But at least it works until a better solution is found.

    #46715
    Grzegorz SidorGrzegorz Sidor
    Participant

    I found a much better solution. In the file /meta-box-aio/vendor/meta-box/meta-box-group/group-field.php just add uniqid() to the return of the static function child_field_id().

    This will give each field a unique id even before the wysiwyg is called.

    	/**
    	 * Change child field attribute id to from 'id' to 'parent_id'.
    	 *
    	 * @param array $parent      Parent field.
    	 * @param array $child       Child field.
    	 *
    	 * @return string
    	 */
    	protected static function child_field_id( $parent, $child ) {
    		if ( isset( $child['attributes']['id'] ) && false === $child['attributes']['id'] ) {
    			return false;
    		}
    		$parent = isset( $parent['attributes']['id'] ) ? $parent['attributes']['id'] : $parent['id'];
    		$child  = isset( $child['attributes']['id'] ) ? $child['attributes']['id'] : $child['id'];
    
    		return "{$parent}_{$child}_".uniqid();
    	}

    And there are no such delays by re-rendering wysiwyg.

    This should also solve the problem with other field types.

    #46722
    Cecil AshiteyCecil Ashitey
    Participant

    Sorry to push this, but is there any ETA on when the update will be pushed out?

    #46766
    Grzegorz SidorGrzegorz Sidor
    Participant

    No one will even reply to this unique ID name solution? When can we expect an update? This is a critical bug for me and more and more customers are reporting this issue to me.

Viewing 15 posts - 1 through 15 (of 17 total)
  • You must be logged in to reply to this topic.