?doing_wp_cron in all URLs after update to JetPack 4.2.x

Thanks for the report. It does seem to be a problem with sites running cron outside of WordPress, as you’ve mentioned. We’re still looking into, but could you try to paste the following in your theme’s functions.php file, or in a functionality plugin, and let me know if it helps?

add_filter( 'jetpack_sync_listener_should_load', 'return_true' );
add_filter( 'jetpack_sync_sender_should_load', 'return_true' );

After looking into this a bit more, It seems that adding the doing_wp_cron query parameter is expected when that constant is set. It’s done by WordPress itself, here:
https://github.com/WordPress/WordPress/blob/master/wp-includes/cron.php#L341-L364

You may not have noticed it before, as Cron wasn’t running that often. However, Jetpack now runs jetpack_sync_cron every minute.

You will consequently see the event coming back every minute, but that’s expected.

Hi Jeremy,
Thanks for your quick action. Good to know that everything is working as expected and that there are no bugs.
In a nutshell, what is the main advantage of having jetpack_sync_cron running so frequently in the new plugin?
I am sure there will be good reasons for this, also considering that in most cases the background task goes unnoticed. In my particular case, I find the URL suffix quite annoying and I am a little bit worried of the impact that this will have on SEO. I hope that in one of the future updates of JetPack the issue will be addressed!
Thanks again

what is the main advantage of having jetpack_sync_cron running so frequently in the new plugin?

As you know, Jetpack relies on a constant communication between your site and WordPress.com. Most of the Jetpack modules rely on that communication to trigger actions, run analysis on your site’s content, and return data for your site readers or yourself:

• You posts and their content are synchronized with WordPress.com, where we index and analyse the content, to return Related Posts for each one of your posts.
• Your post titles and IDs are used to return Stats.
• Your post title, content, and other meta data are used to deliver subscription emails as well as updates on the Social Networks you may have linked to your site with the Publicize module.

Since all these features rely on that back and forth communication, we wanted to make that communication channel even more efficient. We chose to schedule a synchronization more often, to make sure the data on WordPress.com is always up to date. That also allows us to improve your experience on WordPress.com, where you can reliably interact with your site.

We could see about adding a filter to reduce the frequency of the synchronization, but that would also make the synchronization less reliable. I’m not sure that’s the best way to approach your site.

Another alternative would be to redirect all pages including ?doing_wp_cron to the canonical URL, without the query string:
https://wordpress.stackexchange.com/a/70574

I am a little bit worried of the impact that this will have on SEO

I wouldn’t worry about that, as your site most likely includes a link to the canonical post URLs in the head of each post; that’s a default WordPress feature, and it allows search engines like Google to know the URL of the page they should be indexing.
Other things (like Facebook, or Google’s Ad campaigns) can add query strings to the URLs on your site, but the canonical link is there to let search engines know about the posts’ URL.

I hope this helps.

Hello again Jeremy,
Many thanks again for your extensive description of the benefits of a deeper and more frequent integration to wordpress.com through JetPack.
As for what concerns SEO issue, it’s true that canonical URLs are declared in each page so that search engines will disregard query strings.
So it looks like this can be eventually considered a minor issue of “aesthetics”, to be mainly blamed on the necessity to implement ALTERNATE_WP_CRON on, which depends on settings set by the hosting provider, and not on JetPack.
Thanks again for your clarifications,
Best Regards.

I’m running two blogs on one shared hosting account, and after installing Jetpack my CPU consumption jumped 3 times. A big portion of the requests (according to access logs) comes from the site itself, to wp-cron. The interval should be increased or something optimized.

A big portion of the requests (according to access logs) comes from the site itself, to wp-cron.

This may indeed happen, depending on your site settings and the frequency of visits and updates to your site. Can you please use Jetpack’s Debugger module to send us some more information about your site, so we can take a closer look?

1) Go to the Jetpack page in your dashboard.
2) Click on the Debug link appearing at the bottom of the page.
3) Click the link that says “click here to contact Jetpack support.”
4) Fill in the description box and your name and email address. Do not hesitate to add as many details about your site as possible. If you use an alternative to the default Cron system, let us know there. You can also let us know what’s your hosting provider.
5) Click the “Contact Support” button to send us the debug results privately. It’s best not to post this information on public forums, as it contains private details about your site.

Thanks!