Breaks comment box and cron job

I’m aware of the bug with the ‘add manual’ setting. Thank you for notifying me. As a temporary workaround, you can temporarily enable the ‘track logged in administrators’-option and save the settings. This will show the snippet. After you’ve copied the snippet to where you want, you can disable the setting and save again. I’ll release bugfix-update soon…

As for the cronjob error, this has to be related to your server’s configuration. Are you on a windows server? Read this: https://social.msdn.microsoft.com/Forums/azure/en-US/6edfaf6b-da99-4a45-97bc-dfbeef67cb98/request-size-is-too-large-exception-in-document-db?forum=azurecosmosdb

If you’re on a regular Linux server, this might help you out: https://www.keycdn.com/support/413-request-entity-too-large/

If you’ve removed CAOS and the comment box is still broken, then obviously CAOS isn’t the problem. So I can’t help you there. Try disabling other plugins one by one to see which one is causing the issue. It might also be your theme, try switching to a default theme (e.g. Twenty Seventeen), or re-install it. If you’re using any caching plugins, such as W3 Total Cache or WP Fastest Cache, make sure to empty the cache after you disable a plugin.

Quickly checked your site’s console and noticed the following error:

ReferenceError: jQuery is not defined

So, that basically means your javascript isn’t loading properly, which I’m sure is the reason that JetPack isn’t working, because that plugin uses A LOT of jQuery.

@daanvandenbergh

Thank you for a quick response.

Perhaps, the issue may not have been properly isolated and the occurrences of simultaneous installation/removal of CAOS and the subsequent failure/success of cron job might just be coincidental. We will verify the status of jQuery (jquery-migrate might have been disabled temporarily for troubleshooting) and cron jobs and if things look stable, reinstall CAOS plugin.

Really appreciate your support.

Kind regards,

@backpackingseries,

It just occurred to me: what you could try to fix the request size too large-error.

Try disabling the WP-cron that CAOS adds. And add it to your crontab manually.

Thank you very much for the tip.

We tried this config option before removing the CAOS plugin, but without success. The site uses a web service to ping cron.php. Do you mean this file cron.php needs to be modified? If so, with what kind of code?

Appreciate your support.

Kind regards,

PS: Comment box breakdown does not seem to be linked with CAOS. We continue to troubleshoot it and have raised a support ticket with Jetpack.

It’s a bit too complex to explain here in the support forum. I’ll write up a tutorial for it soon and link it here, okay?

Thank you @daanvandenbergh

We have re-installed CAOS (with recommended config –

disabling the WP-cron that CAOS adds

) and can verify that one cron job fails every hour or so – the error msg is not the same however (last evening, it said something like request too large and today it says bad gateway!). However, the subsequent / all other scheduled jobs are successful. Of course, it cuts down the GA requests like a charm.

Curious: How often does the plugin check for updates? If it’s hourly, can it set to a frequency of daily?

Yes, will keep the plugin for now and monitor performance of crons and look forward to the tutorial.

PS: Host does not provide support with cron scripting. Just hope that (technically) it is something we can accomplish on a shared server using file edits with FTP:)

Really appreciate your support.

Kind regards,

You cannot edit your crontab using FTP. You need to connect to your server through SSH and use the command crontab -e.

Yes, the plugin checks for updates hourly. But if you’ve disabled the integrated cronjob using the option Disable WP-Cron, this job shouldn’t run anymore. If it still runs try disabling the plugin and enabling it again.

At the moment there is no option to set the frequency of the update, simply because it shouldn’t fail and it isn’t a resource intensive script — it usually finishes in 3 seconds.

Thank you very much for your advice.

Hmm. 3 seconds is within the timeout specified for the cron. Not sure why it should fail every now and then and we will continue to monitor the performance.

Yes, we have disabled the default wp-cron and the query was inspired by how one backup plugin we use integrated seamlessly (with cron.php) without the need to run crontab -e command.

For now, we note the SSH requirement (of crontab command) as a constraint for our site. Will retry the host to seek support on this and look forward to your tutorial.

Grateful for your support.

Kind regards,

Hello,

Thank you for the recent update. We can now download the latest ga.js manually.

As we continue to test your helpful plugin, there’s been a drop in traffic stats. Wonder if it might be caused by an outdated ga.js on our site. Also, is there a way to verify the timestamp or last version of this file?

Kind regards,

This is definitely because of an outdated version of local-ga.js (the loca version of ga.js).

I don’t know how I would implement a version or timestamp, because I’m not sure of Google publishes it with their files. It’s something I could look into, but for now I suggest you get the cron working.

@daanvandenbergh

Thank you for the helpful confirmation.

Relying on default wp-cron daemon has given us unreliable performance and thus will continue to use cron.php via a web cron service. Unfortunately, CAOS does not work with such a setup at the moment.

We have switched back to CloudFlare GA app for now and will look forward to your guide to leverage the cron web service with CAOS.

Kind regards,

Hmmm… So you’re using a cron.php-file to trigger your crons?

Could you send me the content of this file? Perhaps I could figure out how you’d add CAOS’ cron to this.

Thank you very much for your support. Really appreciate it.

We have not made any changes to the default cron.php in WordPress and simply fed it’s url to a cron web service (after disabling the default wp-cron in wp-config.php). However few plugins may have added their own job schedules to it (e.g. backup works flawlessly). Is it okay to post the cron.php contents here or better to email?

Kind regards,

So you’re triggering the wp-cron.php through a webservice? That’s interesting. You could copy the update_local_ga.php file to your webroot, and make some modifications to trigger it with the same webservice.

You’d have to remove line 9: if (!defined) ...
And change the $localFile-variable to the absolute path to your local-ga.js file.

• This reply was modified 6 years, 3 months ago by DaanvandenBergh.