One other note: Today I was upgrading things and started using SSL on my server. This might be another reason why the plugin stopped working.
Hi,
thanks for your question, and sorry for the trouble.
TablePress 1.7 does not include changes that should have an effect on this, so that I assume that something else is going on.
At first, we should try to find out if the Cron Job is not being executed, or if the code that is supposed to run causes an error.
Can you therefore maybe investigate some more with plugins like https://wordpress.org/plugins/core-control/ and https://de.wordpress.org/plugins/wp-cron-control/ ? Also, please save the configuration again, to refresh it (if you haven’t done so yet).
About the SSL: That could indeed factor in here, if you are trying to import files via the URL method from the same server. You’d then have to adjust the URLs for https:// (which you have probably done). Additionally, it’s necessary that the server can make SSL requests to itself, which however can sometimes fail due to outdated libraries on the server and stuff like that :-/
Regards,
Tobias
So by saving the configuration and then forcefully running the cron via wp-cron.php?doing_wp_cron I was able to get the auto import to fire, but it is definitely not firing on its own (12 hours now even though I set it to 15 minutes). Saving the configuration by itself is not enough, the auto import will not fire until I run the cron manually.
As for the SSL I’m using the “file on server” option, so it shouldn’t be using the web server at all to pull the data.
Hi,
thanks for the further details!
If you are using the “File on server” method, the SSL change does indeed not affect us. So, that’s good š
If the auto-import works when manually running the cron, I can only assume that the automatic spawning is not working. Is your site maybe using caching? That could explain why nothing is triggering the cron (as WordPress uses pseudo-system, where regular site visitors trigger the cron).
Now, as you were successful triggering the cron job manually, do you have the option to use regular server cron jobs (can be configured through a software like cPanel, if available, or via the SSH terminal/command line)?
Regards,
Tobias
The site is using caching. I should also add that manually running the cron does not work unless I save the configuration too!
I do have admin access to the server and can run my own cron jobs, but I’m not sure how I’d go about saving the configuration each time beforehand.
Hi,
ok, if you have to save the configuration every time as well, that’s most likely what’s running the import and not that manually spawned cron job.
Unfortunately, I’m not really sure how we can debug this in the best way at the moment, as I’m very busy these last days before Christmas š
For now, I can only suggest that you look into this more deeply with the Cron plugins that I mentioned, and maybe with WP_DEBUG enabled in your wp-config.php, and also by checking the server error log file for hints.
I might then be able to take a deeper look in mid-January. Sorry for not having better news here š
Regards,
Tobias
So some more bits of info for you:
– Turned off caching entirely, problem still exists.
– Saving the configuration alone does not import the table, need the combo of saving + manually loading wp-cron.php.
– Nothing in the log files with WP_DEBUG enabled.
I suspect this might still have to do with SSL in some way (since that’s the only thing that’s changed, aside from moving to 1.7). But I am not sure what exactly is breaking.
I will tool around a bit with the cron plugins to see if I can learn more. Thanks for your hard work on this great platform!
OK, with core control I manually ran the auto import cron, and it worked. However, the “due time” was not updated! So it seems like the due time is not properly being updated, that’s why it’s only running manually. Saving the configuration resets the due time.
One more thing: No matter what I set the auto-update recurrence time to be, the “due time” is always 1 hour in the future (even for the 15 minutes setting).
Hi,
hhm, all very strange. Maybe there’s something off with the time or time zone settings on the server? That could explain that one hour difference (from daylight savings time or something).
Regards,
Tobias
I’m pretty sure this is related to SSL, *all* of the tablepress plugin cron tasks do not run anymore (such as the update checkers for tablepress-responsive-tables, etc.). I’ve also noticed that all of the hooked functions are arrays for the tablepress plugins; whereas the other cron tasks, which are still working, use a function name instead.
Hi,
hhm, but that would be very strange. I can’t see how enabling SSL would affect outgoing connections…
But the constellation could indeed be that another cron job is actually failing so that the other/remaining ones (including the auto importer) are not run then.
As for the array vs. function name: I think that’s just a glitch in how Core Control displays those callbacks, I remember having seen that before. TablePress and the Extension use a class method here, which is given in array notation, instead of just a callback string. It’s not a functional issue though.
Regards,
Tobias
So I installed Crontrol, and at the top of the list of cron events is the following:
“There was a problem spawning a call to the WP-Cron system on your site. This means WP-Cron events on your site may not work. The problem was:
SSL connect error”.
So it’s definitely related to SSL. I have no idea how to resolve it though, I have a valid SSL certificate. But It’s not TablePress specific I don’t think.
Hi,
aahhh!! Of course! The cron job system works by calling itself (i.e. by making an HTTP request to its own URL in the background). Due to the usage of SSL, it somehow can’t connect, most likely due to a server issue with certain versions of OpenSSL. Something very similar is being worked on in https://core.trac.wordpress.org/ticket/34935 for WordPress itself. One possibility for this issue on your site could be that your certificate was signed by such a 1024 bit certificate, I assume. Otherwise, there must be something else going on with the SSL connection.
Besides working on fixing the SSL issue, you could also try setting up a server cron job, i.e. with something like https://www.siteground.com/tutorials/wordpress/setup-cron-job.htm That way, the cron job would not be called via the SSL URL, but via a local file path.
Regards,
Tobias
Hi Tobias, that seems to be a reasonable work-around, it also has the advantage of always executing whereas the normal cron only executes on a page load. Thanks very much for your assistance, and sorry for making you solve a problem that seems to be WordPress-wide!
My guess would be that this has cropped up suddenly because “Let’s Encrypt” is finally in an open beta, so a lot of websites have started adding SSL certificates (such as mine).
