Handling PubSubHubbub Subscriber POST notifications into Custom Post Type WordPress

Question

I am trying to implement the PubSubHubbub Subscriber protocol with WordPress where each of the feed Atom entries will be saved into a Custom Post Type for the client and many of the XML fields saved into Custom Fields.

The problem that has been raised by the client and I am unsure of is: When the HTTP POST noitification from the Hub with new content comes in, the subscriber client (WordPress) will notify that it successfully received the notification and will only try to send the request again until the client sends a notification success message (http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.4.html#contentdistribution).

However how would you go about handling this if for some reason the Script stopped in the middle? How could you make sure it got that feed again? Also because there could be like 50 articles posted consecutively.

Hope someone can help me with this.

EDIT:

Sorry I expressed myself not too well. I am mainly concerned about on how can someone be able to protect themselves against their script stopping in the middle of processing the XML in WordPress (maybe queueing in WordPress which I don't know how to do, or save a temporary XML file and discarding at the end)?

Answer 1

First of all, PubSubHubbub is an open protocol. Even though it was initially designed for RSS/Atom feeds, it's now completely agnostic. It also does not matter whether it's with a Wordpress feed or any type of RSS feed that supports it (Medium, Blogger... etc).

Now, upon notification, the subscriber should respond a 2XX status code:

The successful response from the subscriber's callback URL MUST be an HTTP [RFC2616] success (2xx) code. The hub MUST consider all other subscriber response codes as failures; that means subscribers MUST NOT use HTTP redirects for moving subscriptions. The response body from the subscriber MUST be ignored by the hub. Hubs SHOULD retry notifications repeatedly until successful (up to some reasonable maximum over a reasonable time period). Subscribers SHOULD respond to notifications as quickly as possible; their success response code SHOULD only indicate receipt of the message, not acknowledgment that it was successfully processed by the subscriber.

As you can see, the hub may retry in case of failure. So, you have at least some margin for very emporary and sporadic problems... That said, you should make sure your script will not be stopped in the middle.