• Resolved bjoerne

    (@bjoerne)


    The following implementation seems wrong to me regarding the handling of the filters. The output of the filters is added to the $output variable which seems to be correct. But in the end this variable is not used, but ob_get_clean() is returned. Instead ob_end_clean() should be called and $output should be returned. Current workaround: Use echo in the filter methods, but that’s not how filters should be used.

    	protected function add_template_part( $ic_posts, $singles = false ) {
    		if ( $singles ) {
    			setup_postdata( $ic_posts );
    		} else {
    			$ic_posts->the_post();
    		}
    		$output = '';
    		ob_start();
    		$output .= apply_filters( 'posts_in_page_pre_loop', '' );
    		require ( $file_path = self::has_theme_template() )
    			? $file_path // use template file in theme
    			: POSTSPAGE_DIR . '/posts_loop_template.php'; // use default plugin template file
    		$output .= ob_get_contents();
    		$output .= apply_filters( 'posts_in_page_post_loop', '' );
    		return ob_get_clean();
    	}
    
Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author ivycat

    (@ivycat)

    Howdy @bjoerne,

    Thanks so much for reporting this. You’re exactly right.

    We’re discussing the best options for fixing and plan to release an update very soon.

    Cheers!

    Plugin Author ivycat

    (@ivycat)

    Howdy @bjoerne,

    We’ve just created a patch for this issue and will be testing it out and releasing soon.

    Our implementation will work as it should, but won’t break backward-compatibility in cases where a user is echoing or printing to the filters, rather than just returning a value.

    Thanks again for your ping and I’ll update you when this is released.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Wrong add_template_part implementation and handling of filters’ is closed to new replies.