Peter Murray

Oh, nuts. It was iThemes Security. I had set it to block all access to XML-RPC. The “Known Issues” page that was linked off the Jetpack Debug page provided the clue.

Sorry for the bother.

Same symptoms: Error Details: The Jetpack server encountered the following client error: Verification took too long I cycled through the “Flush Cache” and “Connect to WordPress.com” sequence three times.

The server is hosted on Amazon EC2, and I have quite a number of plugins installed. Would a list of plugins help diagnose the issue?

All is well — the tweet and wall post happened as scheduled this morning. Thanks, Alex!

So far, so good. I just queued up a post to go out tomorrow morning, and the notification to Twitter did not go out as it has in the past. Hopefully the Twitter notification will go out tomorrow at the scheduled time.

Oh, good — thanks for confirming the bug and noting that it will be fixed in the next release. I’m looking forward to it.

I, too, just stumbled into this issue. I wrote a post that I scheduled to go out tomorrow morning. When I hit the “Schedule” button on the post edit screen, I saw the page where I was prompted to post the entry to Twitter. When I submitted that page, though, the tweet was immediately sent and I had to go in to make the post publish immediately.

I think this is a bug, or at best a side effect that should be prominently noted in the documentation.

I don’t have an answer, but I see something similar under the same circumstances. In my case, the number of files “Processed” exceeds the “Total media library attachments” number, as in this screenshot: https://twitpic.com/3u0c84/full. In addition, I know there are files (from the last few postings, as near as I can tell) that are not uploaded to the CDN (even after 116% processing, as showing the screenshot). While I love the fact that it seems like W3TC is improving my efficiency by uploading content I haven’t created yet (116%!), I think there is something wrong.

Turning on the CDN debug mode doesn’t show anything helpful in the output of HTML pages. I do have a long list of files in the “Unsuccessful file transfer queue” to the CDN with the error of “Object already exists”. If I delete all of the entries in this queue, they eventually come back.

I’m using W3 Total Cache version 0.9.1.3 under WordPress version 3.0.4.

[Posting this here as well because I noticed the other forum entry was marked as “Resolved”.]

Another data point — the same thing happens to me. WordPress 3.0.4 with W3TC 0.9.1.3 and Amazon CloudFront. I don’t have to reinstall the plugin; simply disabling/re-enabling gets W3TC to rewrite URLs to the CDN. Then at some point it stops rewriting URLs.

Another data point — the same thing happens to me. WordPress 3.0.4 with W3TC 0.9.1.3 and Amazon CloudFront. I don’t have to reinstall the plugin; simply disabling/re-enabling gets W3TC to rewrite URLs to the CDN. Then at some point it stops rewriting URLs.

Bump. Any help here? I can’t find any useful discussion on this topic here on the WP Support forums, on the author’s website, or elsewhere on the web.