iamthedan

To be clear, the requests we were getting from Googlebot were the POST requests. We know this because we don’t have the block on the frontend of the site and don’t use AJAX to display results (they’re displayed from the PHP backend using the Popular_Posts_Data class). Additionally our logging allows us to filter by type of request.

Our WPP debug page does report that External object cache is “Yes” and that WPP_CACHE_VIEWS is also “Yes”. Unfortunately we have not been able to see WPP hit memcached using W3TC. Running memdump | grep wpp did not return any results while looking through our output, though there’s a decent chance we’re just missing it when it comes through. We’ve “resolved” our issue in other ways, seen below, so we’re done pursuing it for now.

I did want to pass along though that the reason we were pursuing view caching is because the Google spider was triggering calls to the /wp-json/wordpress-popular-posts/v1/popular-posts endpoint (we’re running 6.3.4, you may have fully depreciated that endpoint for the /wp-json/wordpress-popular-posts/v2/views/* ones by now) and we were taking a performance hit. I had not expected Googlebot to trigger that since it lived in JS. Adding the endpoint to robots.txt solved the issue, but maybe that’s something you’d consider adding with the robots_txt filter as part of the plugin?

Thanks again for your speedy help!

Such a quick response! Thank you!

I’ll look deeper into it and try to report back here with any updates in case anyone else has questions in the future.

Interested in solving this too.

The line in question causing problems is init.php line 61:
add_action('widgets_init', create_function('', 'return register_widget("MCI_Footnotes_Widget_ReferenceContainer");'));

My favored solution is to make the add_action callable a function definition:

add_action('widgets_init', function() {
	return register_widget("MCI_Footnotes_Widget_ReferenceContainer");
});

This requires support for PHP 5.3+ (the plugin shows compatibility currently with WP 3.9+, which claims to run on PHP 5.2.4+. Don’t know if that makes a difference; I’m betting the plugin already uses some features for later versions of PHP). @markcheret is this something you can put in place on a release to make compatibility with PHP 7.2+ better?

~Dan

@NWTD This seems to be working on our site now, though I am wildly unsure as to the reason. As far as I know the only thing that has changed is that we disabled and then reenabled the object cache on W3 Total Cache.

In the settings for the object cache you may want to try adding “wprss_feed” and “wprss_feed_item” to the Non-persistent items listed on the Object Cache settings. I have zero guarantee that this does anything, but might be worth a shot.

It doesn’t work. To get this plugin to work we have to shut off W3 Total Cache.

We were going to try to make it work, but for every thread we found on both the WP RSS Aggregator and W3 Total Cache forums trying to address this issue there was no interest from the developers in trying to actually fix the problem. More often then not it devolved into a blame game, each saying it was the other’s fault.

Honestly if there is a developer reading this that can explain why W3 Total Cache should affect WP RSS Aggregator at all in this way, I would take the problem on myself. But I don’t have time to sift through thousands of lines of code trying to identify the (hopefully) edge case that is causing this.

Looks like this was an issue with W3 Total Cache settings. Not sure why that caused a count up, but the posts are coming in now.

Tried exporting the settings and feed sources from the test site and then importing them into the production site. No change in behavior except that now the feeds are showing “Last Updated” and “Last Update Imported” statistics. “Next Update” is still counting up, not down.

Tried updating the plugin to 4.6.2, no change in behavior.