Skip Navigation

[Resolved] Custom cell and WYSIWYG

This support ticket is created 6 years, 11 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 - -
13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 - -

Supporter timezone: America/New_York (GMT-04:00)

This topic contains 18 replies, has 3 voices.

Last updated by Christian Cox 6 years, 6 months ago.

Assisted by: Christian Cox.

Author
Posts
#600312

Ah, okay I see that now. I have escalated this to my 2nd tier support team for some additional clarification. I'll let you know what I find out.

#607799

Hi Chris, I still need assistance. It is one month ago and still no reply. How does it look like with WYSIWYG in custom cells?
Thanks in advance.

#607804

I haven't received any feedback on this from the Layouts team, so I'm afraid I don't have any good news to share. I will update you as soon as I hear anything.

#872970

I received some feedback from my developers:

The thing is that in dialog context php initialisation is not enough - if complete and done properly with all is needed (it seems the user did) - but some additional help from javascript is needed to render it properly inside the dialog.

Specifically the content of the textarea needs to be initialised manually through JS when dialog opens, this is our dialog_open event callback for post_content cell (which uses tinyMCE in Front End editor only):

self._dialog_open = function( event, object, dialog ){

        if( null === self.dialog_defaults ){
            self.dialog_defaults = dialog._dialog_defaults['cell-post-content']['post-content'];
        }

        _.defer( self.set_content_init );
    };

this is the self.set_content_init method that's in charge of doing the tinyMCE trick:

self.set_content_init = function( ){

        window.wpcfActiveEditor = editor_selector;

        jQuery('#'+editor_selector+'-tmce').trigger('click');

        if( editor_selector in tinyMCE.editors ) {
            var tinymce_editor = tinyMCE.get( editor_selector );
            if( tinymce_editor.isHidden() ) {
                jQuery( '#'+editor_selector ).val( content );
            } else {
                try{
                    tinymce_editor.setContent( window.switchEditors.wpautop( window.switchEditors.pre_wpautop( self.dialog_defaults ) ) );
                } catch( e ){
                    console.log( e.message );
                }
            }
        }

        content_cached = self.dialog_defaults;
    };

I see the user has probably reversed engineered our Visual Editor php file to get that code, he should do the same with either: inc/gui/editor/js/text-cell.js (too big and messy) or wp-content/plugins/layouts/inc/gui/editor/js/post-content-cell.js (suggested since the editor usage is simpler and the file cleaner).