andersheie

I was able to trigger this under more controlled circumstances, and I’m trying to reproduce it. At this time I was down to just 16 scheduled posts, so much less than before and it STILL happened.

How to reproduce (I am NOT sure ALL these steps are necessary, but this is what I did):

1) Add a new post 3 days in the future using rest API, in draft. – No WP Cron job is scheduled (Which is expected, as in draft mode)
2) Edit the post. Change the date one day backwards BUT DO NOT PRESS OK. Press “Schedule” instead. The post date changes, and the page reloads, but no WP cron job was added (FAIL).

This has now failed for me TWICE in a row. If I continue to edit the scheduled day back and forth, this does not seem to happen again.

It was my understanding that the cron jobs in WP are not actually “cron” jobs, but rather they are executed only when a user loads a page, or some action happens. And if so, there really shouldn’t be a limit.. And since I only have 60, that’s probably not the problem.

Also I am running on a Windows Server that I have full control over in AWS, so there is no ISP imposed limits here. I don’t think that’s the issue, or am I wrong on these points?

My problem with that plugin is that is is run in the header on each page, and seems to significantly slow the site down since it checks all the posts on each load.

• This reply was modified 7 years, 5 months ago by andersheie.
• This reply was modified 7 years, 5 months ago by andersheie.

My problem was the same, and I did find a solution that may help others.

First, I was able to successfully and repeatedly GET a list of posts, and also GET a specific post in VIEW and EMBED context mode while debugging. I was NOT able to get the very same post in EDIT more, but as pointed out here I got a rest_cannot_edit error. This led me to believe there was a problem, since obviously the authentication code worked for the other calls.

As it turns out, once I refreshed my authentication code, it worked. I know the original authentication code was expired, but it still worked for the VIEW and EMBED, just not for the EDIT context. Maybe that is the real problem here as I would have expected it to not work at all. Or perhaps because I’m using Cloudflare, those calls were cached from earlier tests. I’m not sure. But IF you see this problem while testing, it’s worth trying to get a new authentication code and just try again.

(And of course make sure the user that got the authorization has the correct rights)

• This reply was modified 7 years, 6 months ago by andersheie.

P.S. obviously the {{type}} is the name of the dropdown option attribute ??