Handling PubSubHubbub Subscriber POST notifications into Custom Post Type WordPress

0 Views

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).

Read More

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)?

Post Views: 0

Related posts

Leave a Reply

1 comment

  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.