• Hi, great plugin but there is a problem with filtering the frontend output through ‘the_content’.

    I use yarpp and it add the read also links by hooking into this filter. Now every widget I add using your plugin, is followed by the read-also links.

    Please correct this.

    Regards, Hans

Viewing 6 replies - 1 through 6 (of 6 total)
  • This is a serious issue that needs to be addressed.

    Currently modifying the plugin:
    Remove the filter on line 402 reusable-blocks-extended.php
    echo reblex_get_block( $block_id );

    Seebz

    (@seebz)

    Same issue with Jetpack Related Posts and Sharing features who also use the_content filter.

    These plugins are checking the current post type (with get_post_type()) but reblex does not update the global post before calling the filter.

    I suggest to add/use the following function instead of apply_filters( 'the_content', ... ) :

    
    /**
     * reblex_get_filtered_block_content function.
     *
     * @param mixed $id The ID of the reusable block.
     * @return $content The filtered content of the block.
     */
    function reblex_get_filtered_block_content( $id ) {
    	global $post;
    	// backup $post
    	$prev_post = $post;
    	// update $post
    	$post = get_post( $id );
    	setup_postdata( $post );
    	// retrieve content
    	$content = apply_filters( 'the_content', $post->post_content );
    	// restore $post
    	wp_reset_postdata();
    	$post = $prev_post;
    	// return content
    	return $content;
    }
    

    A patched version of the file is available in this gist.
    Hope it will help, sorry for my bad english

    Thread Starter Hans Schuijff

    (@hanswitteprins)

    Hi @seebz ,

    thanks for the addition. I think this plugin isn’t maintained anymore, or at least not frequently anymore. So we seem to be on our own, solving this. This bug hasn’t been addressed, although it was reported a long time ago, and the last update is already 3 months ago.

    I have tested today what is going on and found that when plugins follow the advice of the dev docs about the_content hook, that it still doesn’t work. So there is no problem in the other plugins, it is just something that needs to be solved in this plugin.

    Both the shortcode and the widget fail when there are other plugins that use filtering with the_content hook both in the main content and in sidebars. I tested with the genesis framework and a single blog post and there I added a simple reusable block, both in the content and in several sidebars both as block, widget and shortcode.

    When using the shortcode, even in the main content of the post the related posts-links of yarpp where added, as well as at the end of the post. All widgets got the related posts links too, both the reusable block widget as the shortcode widget. They all added the yarpp links after it.

    The reason that yarpp and other plugins can’t determine correctly when to not to add their content block, is because of the WordPress conditionals.

    The codex says to use is_main_query() and in_the_loop() and is_singular(), but all three will return true, both in the actual post content, as in every sidebar on that single post.

    I have an “after content” widget area and a sidebar, and both had all three conditionals set to true. That means that every widget I added had it’s own related posts links added to it.

    Completely removing the apply_filters() would also not work correctly, since than shortcodes in the reusable block wouldn’t be processed correctly and also the gutenberg comments in the source are not removed. WordPress adds a lot more corrective functions in that hook, that all could be relevant depending on the content of the reusable block and the options in WordPress, so it is practical to use the hook instead of wrapping 10 wordpress functions around the reblex_get_block() call.

    convert_smilies(
      do_shortcode(
        capital_P_dangit(
          wp_replace_insecure_home_url(
            wp_filter_content_tags (
              prepend_attachment(
                shortcode_unautop (
                  wpautop ( 
                    wptexturize( 
                      do_blocks( 
                        reblex_get_block( 150 )
                      ) 
                    ) 
                  )
                )
              )
            )
          )
        )
      )
    );

    But we just don’t want other plugins adding content and need to do something so the adviced conditions will fail for the added blocks and widgets.

    Your function solves that, since it sets the in_the_loop() conditional to false (helas will the is_main_query() and the in_the_loop() conditional still return true, but it is enough for well written plugins).

    I found that to solve the shortcode the apply_filters needs to be replaced by your function call in reblex_shortcode().

    function reblex_shortcode( $atts ){
    	extract( shortcode_atts( array( 'id' => '' ), $atts));
    	$content = reblex_get_filtered_block_content( $id );
    	return $content;
    }

    To solve the widget, the widget method needs to use your function instead of calling apply_filters…

    public function widget( $args, $instance ) {
    	echo $args['before_widget'];
    	if ( ! empty( $instance['title'] ) ) {
    		echo '<h3>' . esc_html( $instance['title'] ) . '</h3>';
    	}
    	$block_id = '';
    	if ( isset( $instance['block_id'] ) ) {
    		$block_id = $instance['block_id'];
    	}
    	echo reblex_get_filtered_block_content( $block_id );
    	echo $args['after_widget'];
    }

    The apply_filters(‘the_content’ call in reblex_display_modal() doesn’t seem a problem, as far as my test showed.

    the same seems for reblex_display_block().

    So only two statements need to be changed and your function added.

    I hope the plugin author will solve this now. On the other hand, when this plugin is no longer maintained, the changes I made in my copy will not be overwritten by updates anyway.

    Well, that seems to be it than. Thanks again.

    regards,

    Hans

    Thread Starter Hans Schuijff

    (@hanswitteprins)

    This issue was already reported 1.5 years ago too, and I like the solution that was proposed in the first report there more.

    The problem with the_content filter is that it is both used to prepend en append content to the content as it is used to sanitize and preprocess the content itself. One wants the preprocess steps to be executed, but not everywhere the prepending an appending of content should be done.

    To prevent any problems like this, it would probably be the best to make a custom the_content filter for the plugin and just hook the core functions in that. Doing it like that would mean that it doesn’t matter if it is used to process a block, a widget or the content as a whole. That would prevent problems.

    I’m not sure why this issue isn’t acknowledged at all by the plugin dev. Why are users forced to change parts of the source code to solve a problem that has been known for so long and can be fixed? Bill Erickson seems to have the correct structural answer here.

    https://www.billerickson.net/code/duplicate-the_content-filters/

    In the end it just means prepending the the_content filtername and adding an init function that hooks the needed core filters on it. It doesn’t seem that difficult to implement.

    Thread Starter Hans Schuijff

    (@hanswitteprins)

    I added this this to my core-functionality plugin and will rename the_content in this plugin for now, so it will use this hook. It’s a drag to have to do that for every update, but it’s the least impact. In that way all core callbacks are fired and no extra’s.

    /**
     * Adds a clone 'the_content' filter hook that will only fire the WordPress core callback functions.
     *
     * This hook is used so that plugins that prepend or append content to the_content will not add them.
     *
     * @return void
     */
    function setup_custom_the_content_filter() {
    	global $wp_embed;
    	add_filter( __NAMESPACE__ . '\the_content', array( $wp_embed, 'run_shortcode' ), 8 );
    	add_filter( __NAMESPACE__ . '\the_content', array( $wp_embed, 'autoembed' ), 8 );
    	add_filter( __NAMESPACE__ . '\the_content', 'do_blocks', 9 );
    	add_filter( __NAMESPACE__ . '\the_content', 'wptexturize' );
    	add_filter( __NAMESPACE__ . '\the_content', 'convert_smilies', 20 );
    	add_filter( __NAMESPACE__ . '\the_content', 'wpautop' );
    	add_filter( __NAMESPACE__ . '\the_content', 'shortcode_unautop' );
    	add_filter( __NAMESPACE__ . '\the_content', 'prepend_attachment' );
    	add_filter( __NAMESPACE__ . '\the_content', 'wp_filter_content_tags' );
    	add_filter( __NAMESPACE__ . '\the_content', 'wp_replace_insecure_home_url' );
    	add_filter( __NAMESPACE__ . '\the_content', 'do_shortcode', 11 );
    	add_filter( __NAMESPACE__ . '\the_content', 'capital_P_dangit', 11 );
    }
    add_action( 'init', __NAMESPACE__ . '\setup_custom_the_content_filter' );

    @hanswitteprins I read through this post, I see you added a work around for this plugin. I am having an issue of the very recent post of each category not showing in the shortcode on a page. Any idea if this is a related issue with the above that needs corrected? Are you interested in looking at our site to troubleshoot? https://www.floods.org the home page shows the most recent posts. On other topic (category) pages they are not showing those most recent post on each. What setting will show all and not skip the very most recent post?)

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Problems with the_content filter’ is closed to new replies.