[wp-trac] [WordPress Trac] #6698: Editing a published post causes excessive pings / closing comments on old posts causes trackbacks

[WordPress Trac]

#6698: Editing a published post causes excessive pings / closing comments on old
posts causes trackbacks
-------------------------------------+--------------------------------------
 Reporter:  lapcat                   |        Owner:  Denis-de-Bernardy
     Type:  defect (bug)             |       Status:  reopened         
 Priority:  high                     |    Milestone:  2.8.3            
Component:  Pings/Trackbacks         |      Version:  2.8.1            
 Severity:  major                    |   Resolution:                   
 Keywords:  has-patch needs-testing  |  
-------------------------------------+--------------------------------------
Changes (by VoxPelli):

  * keywords:  has-patch tested commit => has-patch needs-testing


Comment:

 Replying to [comment:39 Denis-de-Bernardy]:
 > So it's a timestamp that is needed, and your patch isn't working because
 of this -- it always returns false.
 Did you actually try my patch? It's true that it checks for a timestamp -
 but at line 731 in functions.php it adds the current timestamp to the
 expiration time, which leaves your options expiring sometime in februari
 2049:

 add_option($transient_timeout, time() + $expiration, '', 'no');

 > Your other two points you raise are equally invalid. The value I put in
 the transient could be 1, or "about to do a ping", or whatever -- it
 doesn't matter, its time() value is only there in the event a plugin might
 want to know when it was set.
 Yes - I realize now that that point is invalid because of my first point -
 my bad

 > Re the second point, it's just a different approach. With the patch I
 suggested we ping once per hour at most (and based on my testing since
 yesterday, it's working exactly as documented).
 I'm not arguing that your patch doesn't fix that a ping is made at most
 once an hour - I'm saying that I think it's wrong that it doesn't queue a
 ping for changes made during that hour since that leaves ping services
 with outdated information.

 Let me give you an example:

 At 10.00 AM: I'm posting a new post and my blog pings with both our
 patches.

 At 10.10 AM: I discover a serious error in that post and changes it - with
 my patch a ping is queued to take place at 10.30 AM since I don't want to
 ping services more than once every 30 minutes - but with your patch this
 change will not be communicated to the ping services at all.

 At 10.20 AM: I'm really creative this hour so I'm posting yet another post
 - with my patch since a ping is queued already nothing further happens -
 with your patch this post will also not be communicated to ping services
 at all.

 At 10.25 AM: I'm moving away from the computer for some hours to do some
 administrative work.

 At 10.30 AM: It was 30 minutes since the ping services was notified of
 changes from my blog and we can feel safe to send a new ping. With my
 patch, since changes that should be pinged has already happened during
 that time, the system will now immediately ping them to alert them that
 they should check my blog for updates - with your patch nothing happens.

 At 12.00 AM: Since nothing has changed on the blog - I'm doing
 administrative work - the ping services will believe they are up to date
 on my blog. With my patch they will be - with your patch they won't be
 until I'm done with my administrative work and returning to do some more
 blogging.

 Ping services want to be up to date - ping services don't want to be
 spammed. By limiting a ping to once every half an hour but also making
 sure that every change is actually followed by a ping we can ensure to
 have as up to date ping services as we possibly can. A maximum of two
 pings per hour and a maximum delay of 30 minutes for a ping service to be
 notified of a change.


 Btw - how can you say that your patch is tested and committed? I have
 reviewed it and I find it broken. Don't you need a third party review to
 label your patch as tested?

 I'm btw obviously still suggesting my patch as the solution here.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/6698#comment:41>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software