leorwalker

As an FYI and for closure, I added some instrumentation to cron.php and option.php (which is called from cron.php to set the schedules) to figure out what is actually happening.

In the majority of cases, _set_cron_array is throwing a WP_Error when update_option returns false due to the schedule already being present. There is no actual db error, no db rows affected, and there was a well-formed UPDATE query. The data was just already there.

In a small number of cases, there were concurrent attempts to update the db. In all the cases I saw, the correct data was ultimately written, but a could_not_set error was thrown along the way.

Bottomline: everything appears to be functioning properly, other than accurate diagnosis and logging of the result. Perhaps a small change in cron.php to rule out the false positives before logging a could_not_set error would be helpful.

If anyone is in a position to do anything about this, if anything is in fact warranted, feel free to reach out to me as needed.

Thank you.

well, did you actually resolve it? It’s a 2 minute php correction. I patched mine so I wouldn’t get my error log filled up but I haven’t seen an updated version come out since I reported the issue.

Thanks for responding. I had worked around the problem in the obvious way – adding the CSS manually to my page.

So I went back and removed it…. And the table is displaying correctly anyway. I’m not sure why it wasn’t working earlier. It had been fine for a year, then stopped working, and now is okay again.

Either way, you can close this issue. Thanks for your response.