DavidFB

Ah – obvious now that you point it out. Thanks!

In my case, I deactivated the plugin as it wasn’t working. It was unclear what to do about it as the Twitter interface had changed and I couldn’t find the API section (probably now a paid feature). Then @jh20001 mentioned it working again, so I reactivated the plugin and its now working again.

When I posted my last article, the New Post interface displayed an error message, I think due to this Plugins section in the interface. But it didn’t affect anything.

Ah, thanks. I reactivated the plugin and it’s working fine now. Guess they decided some were OK after all.

Same issue here – Twitter sent this message:
“This is a notice that your app – RevivesOldPost – has been suspended from accessing the Twitter API.”
Turns out they have a new developer tier system and this apparently doesn’t fit the model?? And tips on how to address this would be appreciated. Seems it will be happening to all your customers.

I ran into this editing an older post. No Revisions window and no option to turn it on. Saved the post after some further edits and there it was. Checked the Screen options panel and it had been re-added in first position. Odd.

You may be fighting with WordPress. It will automatically remove some code.

I’ve been having the same issue. Only in my case, the height=”589″. It doesn’t do this until the post is first saved.

If anyone discovers the cause, I’d like to know.

Thanks, Uriahs. Sorry to be grumpy but this has been an odd problem. I value ROP as it effectively resurfaces a large catalogue of articles. But none of the solutions has been reliable or possible.

I’ll loop back and talk to my host.

I have to say this has been a bizarre experience.
– my host doesn’t allow cron jobs (it’s running on Plesk)
– EasyCron stopped working after the trial period.
– cron-job worked but threw a 302 error message.
– after a week working, I rechecked and discovered cron-job had cancelled the job due to the 302 error messages even though set not to. It turned out EasyCron had turned back on and was driving it. But I’d closed that account first, before realizing it was the one actually working.
– I cancelled both and turned WP-cron back on and it worked fine for over a week! Until the ROP plugin announced it may not be working. Are you sure it’s not the plugin check that is causing it to stop working?

Agreed, Uriahs
The authentication has made it reliable. But with or without, it throws a 302 error. I suspect this is a server security setting so the cron appears moved. Essentially, this has been a dance to get it working with my current host. I appreciate your patience.

And yes, I did review some years ago.

With authentication added, the Cron job is triggering ROP and other WP-cron events properly.
However, cron-job is still recording a 302 error. As it’s a minor error, I’m not concerned. I wouldn’t call it a perfect resolution but it’s working.
Thanks again!

Well – it’s still throwing the 302 error.
Curiously, the cron triggers ROP the first time but doesn’t thereafter.

Found a Stackoverflow post that suggests the issue is likely a modSecurity firewall block. That wouldn’t surprise me.

I’m going to try adding HTTP authentication…

Thats a major update to the article – thanks. I had left off the ?doing suffix on the URL. We’ll see how it behaves today.

Ah, thanks Uriahs.
EasyCron deactivated already so I’m giving cron-job a try. It would be useful to know how to code for it as it’s just got a URL box. It did successfully trigger ROP with just the WP-cron URL but the cron-job log shows a 302 error.

I’m letting it run overnight with a higher posting frequency. We’ll see how it’s doing.

Hi Uriahs

My host uses Plesk and was not prepared to add a cron job (or equivalent).
Method 1 requires a monthly renewal or yearly fee which seems lame for a workaround.
A third fix I ran into was for sites that use http authentication. (like pop-up login boxes) wp-cron doesn’t have authentication so the ‘WP Cron HTTP auth’ plugin adds that. Alas, my hosts server didn’t like that one.

Back to Method 1, EasyCron seems to be doing the job running events when the cron cycle comes around again. That reduces server load too.

Thanks for your help. I would not consider this ideal but your updated plugin feature did alert me to an issue lurking behind the scenes. Thanks for that too.