Multiple instances of wysiwyg

[EvanHerman]

Thanks for this awesome set of examples.

I am trying to implement multiple instances of the WYSIWYG editor in the customizer.

When adding more than one, only one of them actually works. The others get initialized in a very strange fashion:

You can see in the second instance, it looks like the editors are stacked. It comes along with a JS error that states: Uncaught TypeError: Cannot read property 'settings' of null.

Do you know what may be causing this, and how to work around it?

Thanks,
Evan

[EvanHerman]

After a bit of tinkering, I've come to the conclusion that:

do_action('admin_print_footer_scripts');

is firing on each instance of wp_editor, which is causing conflicts.

To work around this issue, on the last instance (and only on the last instance) of my wp_editor I fire off do_action('admin_print_footer_scripts');. This seems to work well, now each of my editors are displaying properly without anything strange happening.

I was forced to add a conditional inside of text-editor-custom-control.php, which will work for my project but is not ideal for public consumption.

<?php
if ( ! class_exists( 'WP_Customize_Control' ) )
    return NULL;
/**
 * Class to create a custom tags control
 */
class Textarea_Custom_Control extends WP_Customize_Control
{
      /**
       * Render the content on the theme customizer page
       */
      public function render_content()
       {
            static $i = 1;
            ?>
                <label>
                  <span class="customize-text_editor customize-control-title"><?php echo esc_html( $this->label ); ?></span>
                  <span class="description customize-control-description"><?php echo esc_html( $this->description ); ?></span>
                  <input type="hidden" <?php $this->link(); ?> value="<?php echo esc_textarea( $this->value() ); ?>">
                      <?php
                            $settings = array(
                                'textarea_name' => $this->id,
                                'media_buttons' => false,
                                'drag_drop_upload' => false,
                                'teeny' => true,
                            );
                            wp_editor( $this->value(), sanitize_title( $this->label ), $settings );

                            if( $i == 2 ) {
                                do_action('admin_print_footer_scripts');
                            }
                            $i++;
                      ?>
                </label>
            <?php
       }
}

Where $i == 2 is the number of editors you are using in your customizer instance. Obviously this number will need to be increased as I add more wp_editor instances to the customizer.

I'm not sure of the best way to fire off do_action on the last instance, hopefully someone has a better idea.

[stuartstarrs]

@EvanHerman I've just arrived at the same roadblock you have.

We know how to count how many instances of the control we've created with a static variable. What we don't know programmatically is the total number of instances there are/will be. We don't know which is the last.

As you say, it's clearly something happening when the admin_print_footer_scripts is fired. And it's definately something happening twice instead of once. And I think it's something to do with the TinyMCE initialization on _.wp-textarea-editor_s - one of the textareas is having TinyMCE applied twice.

My idea was to place that hook somewhere else admin_print_footer_scripts where I could control it, still within the general area of the Customizer stuff, just after it and just once (rather than multiple times for every instance).

customize_controls_enqueue_scripts happens way up at the header so is useless as a hook, 'admin_print_scripts' seems to output everything right at the end but doesn't help.

I can't think of another way to make admin_print_footer_scripts fire just once after all the editor instances without taking the do_action out of the class and placing it elsewhere. But I'm stuck as to where.