When 'the_content' filter applied and bbpress shortcode added to Admin Editor of Wordpress post, bbPress un-registers (or prevents WP from registering) the dashicons, and the editor.min.css stylesheet

[undergroundnetwork]

When 'the_content' filter is applied to the Admin Editor of a Wordpress page or post, bbPress un-registers (or prevents WP from registering) the dashicons, and the editor.min.css stylesheet. This occurs when you put a bbpress SHORTCODE in a post.

This results in a messed up Editing screen as can be seen in the bellow image:

[jsmoriss]

The problem is with the "Post Formatting" option. I hooked 'bbp_use_wp_editor' before applying the_content filter to return false, and this fixed the problem. For example:

$content = get_post_field( 'post_content', $post->ID );

add_filter( 'bbp_use_wp_editor', '__return_false', 1100 );

$content = apply_filters( 'the_content', $content );

remove_filter( 'bbp_use_wp_editor', '__return_false', 1100 );

I think a better option would be for bbPress to test for ​https://codex.wordpress.org/Function_Reference/doing_filter (for example) and skip the use of wp editor in that case.

js.

[johnjamesjacoby]

I'm not able to duplicate this in vanilla WordPress using bbPress trunk.

Applying the the_content filter to the admin editor content sounds like it will break all kinds of things, not just bbPress. Can you provide more context into what you're trying to do, or what plugin is causing the conflict that you've identified?

I'm going to add the "close" keyword to this ticket. I have a hunch this isn't something we can safeguard against very easily.

[jsmoriss]

title, content, excerpt, etc. filters in WP are made to be applied to resolve shortcodes etc. There's nothing "dangerous" about them at all - it's quite normal, actually. If you need to expand the $post->post_content for example, you apply 'the_content' filter. The problem is that when you do this on the admin side, *and* bbPress is configured to include the editor, it screws up WP dashicons and the editor.min.css enqueue. I suspect the reason why you couldn't duplicate the problem is that you weren't applying the filter on from an admin post editing page. Try hooking 'admin_init' for your test.

js.

[johnjamesjacoby]

Replying to jsmoriss:

title, content, excerpt, etc. filters in WP are made to be applied to resolve shortcodes etc. There's nothing "dangerous" about them at all - it's quite normal, actually. If you need to expand the $post->post_content for example, you apply 'the_content' filter. The problem is that when you do this on the admin side, *and* bbPress is configured to include the editor, it screws up WP dashicons and the editor.min.css enqueue. I suspect the reason why you couldn't duplicate the problem is that you weren't applying the filter on from an admin post editing page. Try hooking 'admin_init' for your test.

I think you are misunderstanding my question, and it's not really fair to assume/suggest that we don't understand how filters work and are applied. I never said filters were dangerous (though they certainly can be) – I said (paraphrasing now) that using the incorrect ones in the incorrect places can produce undesirable results in an unpredictable filter stack.

I understand the end result you've come to. I need to better understand how and why you're getting to this point.

WordPress does not use the the_content filter inside of the post editor, and it's arguably the wrong filter to use in that context, which is why you're experiencing this problem. For example: If all you need to do is process shortcodes, use do_shortcodes.

If you can include a snippet of code to reproduce the problem, maybe we can help you use the correct filters, or better identify how bbPress can better predict what seems to me to be a somewhat unorthodox approach to formatting editable content.

[jsmoriss]

Well, so be it -- at least we reported the issue -- do with it what you will. The work-around for this bug is listed above, if anyone else needs it.

js.

[johnjamesjacoby]

Replying to jsmoriss:

Well, so be it -- at least we reported the issue -- do with it what you will. The work-around for this bug is listed above, if anyone else needs it.

A work-around is less helpful than example code to reproduce the situation you're experiencing, which is the only way to confirm whether this is a bbPress bug, or something else.

[jsmoriss]

add_action( 'current_screen', 'bbpress_editor_bug_example' );

function bbpress_editor_bug_example( $screen ) {
        if ( ! isset( $screen->id ) ||
                ! isset( $_GET['post'] ) )
                        return;
        switch ( $screen->id ) {
                case 'post':
                case 'page':
                        $post_id = sanitize_key( $_GET['post'] );
                        $content = get_post_field( 'post_content', $post_id );
                        $content = do_shortcode( $content );
                        break;
        }
}

[thebrandonallen]

@jsmoriss I've tried your bbpress_editor_bug_example function, and everything worked as it should. Is this still an issue you're experiencing.

Current WP Trunk (4.7-alpha-38178-src)
bbPress Trunk (2.6-alpha-6091)

[netweb]

Closing this as works for me, if the issue still persists please reopen and include detailed steps to reproduce the issue