Tyrosh

Think I figured it out, by adding a function to my child theme, it appears fixed:

function mysite_customize_lazy_images( $blocked_classes ) {
    $blocked_classes[] = 'attachment-inhype-blog-thumb size-inhype-blog-thumb wp-post-image';
    return $blocked_classes;
}

add_filter( 'jetpack_lazy_images_blocked_classes', 'mysite_customize_lazy_images' );

Can someone sanity check my usage of the element in blocked_classes? I think I got the right one.

I completely bypassed Ezoic (and it shouldn’t even run when I’ve logged in anyway) so that means no JS minification or caching from their end should be interfering. After clearing all caches on the server and turning on CF dev mode, the issue persists.

Could this be a mixed content SSL issue or something else? I really can’t seem to get the related posts to display anymore when bypassing anything to do with JS being messed with, which if that was the issue, it seems like I could see them at some point. It’s just weird because it worked fine when I first installed the feature.

Just for clarity to help nail down potential culprits, I’m using both Autoptimize (no JS minification) and WP Super-cache.

I’ve already set the setting to not cache get parameters in WP Super-cache.

Here’s the code in my functions.php relating

function defer_parsing_of_js( $url ) {
    if ( is_user_logged_in() ) return $url; //don't break WP Admin
    if ( FALSE === strpos( $url, '.js' ) ) return $url;
    if ( strpos( $url, 'jquery.js' ) ) return $url;
    return str_replace( ' src', ' defer src', $url );
}
add_filter( 'script_loader_tag', 'defer_parsing_of_js', 10 );

// remove related posts from default position
function jetpackme_remove_rp() {
    if ( class_exists( 'Jetpack_RelatedPosts' ) ) {
        $jprp = Jetpack_RelatedPosts::init();
        $callback = array( $jprp, 'filter_add_target_to_dom' );
        remove_filter( 'the_content', $callback, 40 );
    }
} add_filter( 'wp', 'jetpackme_remove_rp', 20 );

//Change number of Jetpack RP posts
function jetpackme_more_related_posts( $options ) {
    $options['size'] = 18;
    return $options;
}
add_filter( 'jetpack_relatedposts_filter_options', 'jetpackme_more_related_posts' );
?>

I’m also calling the shortcode to insert the jetpack posts via this:

      <?php     if ( class_exists( 'Jetpack_RelatedPosts' ) ) {
    echo do_shortcode( '[jetpack-related-posts]' ); } ?>

I had Jetpack with these settings before and the related posts showed up fine, only to randomly stop showing up a couple days later.

• This reply was modified 5 years, 5 months ago by Tyrosh.

I was able to get the dashboard to show up in incognito with that plugin disabled. However it still doesn’t work in normal browsing. Also when trying to reset site kit and reset permissions, I get “You don’t have permissions to authenticate with Site Kit.” after allowing permissions on Google.

Edit: was able to get it working in incognito mode via disabling security and caching plugins. already had the site kit directory disabled in caching, will look into adding exceptions in the security plugin as well if I can.

Are there any files that could exempted via .htaccess or other methods to allow the far future expiry plugin to no longer cause this issue?

And it still appears to be broken in normal browsing. At least the core is reporting properly to Google though.

• This reply was modified 5 years, 12 months ago by Tyrosh.
• This reply was modified 5 years, 12 months ago by Tyrosh.

No change, just get an infinite loading bar on the plugins page and the dashboard under site kit is the only thing showing up, all blank.

And also, I disabled Cloudflare and Ezoic services when doing what you recommended, as they had caching as well. The setup worked fine prior to 1.10.0

• This reply was modified 5 years, 12 months ago by Tyrosh.

I’m dumb, found the solution minutes after making this. I hadn’t enabled OPCache in my PHP config.