1

I've implemented TinyMCE as my comment form on both the front- and back-end, using the below code (sourced from some questions here):

// Enable TinyMCE as frontend comment editor for new comments
function wpse_64243_comment_editor( $field ) {

    if (!is_single()) return $field; //only on single post pages.

    global $post;
    ob_start();

    wp_editor( '', 'comment', array(
        'textarea_rows' => 15
    ) );

    $editor = ob_get_contents();
    ob_end_clean();

    //make sure comment media is attached to parent post
    $editor = str_replace( 'post_id=0', 'post_id='.get_the_ID(), $editor );
    return $editor;
}

add_filter( 'comment_form_field_comment', 'wpse_64243_comment_editor' );

// Enable TinyMCE as the backend comments editor
function cort_remove_editor_quicktags( $settings, $id ){
    global $pagenow; 
    if ( $id == 'content' && $pagenow === 'comment.php' ){
        $settings['tinymce'] = true;
    }
    return $settings;
}

add_filter( 'wp_editor_settings', 'cort_remove_editor_quicktags', 10, 2 );

But the comment encoding gets a little weird any time I go to edit it. While any formatting displays correctly in the admin view, and on the page all the tags are bolding/italicizing as they should, any time I try to edit the text with TinyMCE, I get this:

<!--On TinyMCE, in visual mode-->
<strong>asdfjkasld;f</strong>

<em>hjkdlhfaskdjfas</em>

<!--On TinyMCE, in text mode-->
&lt;strong&gt;asdfjkasld;f&lt;/strong&gt;

&lt;em&gt;hjkdlhfaskdjfas&lt;/em&gt;

If I "repair" the styles by removing the encoded tags and reformatting through TinyMCE, the next time I hit Edit on that comment, I get the same results as the above.

As far as I can tell, this has more to do with TinyMCE not decoding encoded text, since I have it set up outside its normal environment. I've tried changing the encoded entities in tiny_mce_before_init, but that hasn't worked. Are there any hooks for filtering the actual content of a post before it hits TinyMCE? Or is this a dead-end?

1 Answer 1

1

It's still unclear to me why this is happening, because all the encoding of < and > for comments looks the same as posts do in the database view, so I'm still unsure why TinyMCE is treating post_content vs comment_content differently. But ultimately, all that needs to happen is for the existing escaped HTML tags to get decoded when editing on the backend.

jQuery( document ).on( 'tinymce-editor-init', function( event, editor ) {
    function htmlDecode(input) {
        var doc = new DOMParser().parseFromString(input, "text/html");
        return doc.documentElement.textContent;
    }

    function fixTinyMCEComments() {
        var parent = document.querySelector("#content_ifr").contentDocument.children[0].querySelector("#tinymce");
        Array.from(parent.children).forEach(function(p) {
            p.innerHTML = htmlDecode(p.innerHTML);
        });
    }

    fixTinyMCEComments();
});

Register it wherever your admin_enqueue_scripts is called in functions.php - I enqueue it only on comment.php:

// Enable TinyMCE as the backend comments editor
function load_backend_comments_editor( $settings, $id ){
    global $pagenow; 
    if ( $id == 'content' && $pagenow === 'comment.php' ){
        $settings['tinymce'] = true;
        wp_enqueue_script( 'mytheme-admin' );
    }
    return $settings;
}
add_filter( 'wp_editor_settings', 'load_backend_comments_editor', 10, 2 );

This is a bit of a hack, because the implementation depends on TinyMCE maintaining its current node tree, but since this is on the backend for something that likely won't continue to be edited after a month or so, I'm okay with it. Any improvements are welcome, though!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.