Ticket #2469 (closed defect: fixed)

Opened 3 years ago

Last modified 2 years ago

Multiple #2440 Issues

Reported by: masquerade Assigned to: ryan
Priority: normal Milestone: 2.1
Component: Administration Version: 2.0.1
Severity: major Keywords: has-patch
Cc:

Description (Last modified by masquerade)

1. This causes a filter regression, plugins can no longer disable pinging at their will without clearing the option. I personally suggest adding a hook, execute_pings, to which generic_ping is added in default-filters.php as it was before.

2. This does no checks to see if the site has been pinged already, which could lead to blacklisting upon repeated saves to the post.

3. Generic sites will not be pinged unless a trackback or pingback is waiting, potentially delaying the pings until the next post is published.

There's something else I had that I'm forgetting, I'll update again later if I can remember.

Attachments

future-pings-final.diff (3.3 kB) - added by masquerade on 03/19/06 07:11:49.
future-pings-final2.diff (5.0 kB) - added by masquerade on 03/21/06 04:54:26.

Change History

02/17/06 03:32:08 changed by masquerade

  • description changed.

02/18/06 00:27:07 changed by ryan

  • owner changed from anonymous to ryan.
  • status changed from new to assigned.

03/01/06 20:08:40 changed by masquerade

On second look, item 2 could use a bit of redefining. Somebody could use this to call execute-pings.php over and over, causing stress problems for ping-o-matic (which has enough problems right now as it is) or gain blacklisting from other generic services.

Item 3 is invalid though, on second peek at the code, I realized the pinger is spawned on every post, not just when there are waiting pings.

03/19/06 07:11:27 changed by masquerade

  • keywords changed from needs-patch to has-patch.

Here's a patch to fix the problems listed above, and once and for all finish of future pinging for posts.

03/19/06 07:11:49 changed by masquerade

  • attachment future-pings-final.diff added.

03/20/06 20:18:26 changed by ryan

Take a look in admin-footer.php where we call spawn_pinger() and conditionally load execute-pings.php inside an iframe. This is a workaround for some cgi environments where spawning doesn't work. We probably need a similar workaround for cron. We also need a more refined blacklist of spawn unfriendly environments.

Anyway, if we can get cron to fire off reliably in all environments, I like having pings goinging through cron. All of our asynchronous events can go through cron where we can take care of spawning and working around uncooperative environments in one place.

03/20/06 20:32:37 changed by masquerade

I've developed and tested cron solely in CGI environments, with no issues whatsoever. If someone actually has an issue, I'd be more than happy to work on the same workaround, but I currently see no issue for it. If someone wants to send me server setup details (webserver, version, php version, etc.) for me to setup my own test environment of, I will, however, its looking rather unnecessary at the current time.

03/21/06 00:19:06 changed by ryan

Okay. Let's do this. Clean out admin-header to get rid of the spawn_pinger() and execute-pings stuff. Get rid of spawn_pinger and any other leftover bits. See what breaks. If we get complaints, we might need to add the iframe workaround back in somehow.

03/21/06 03:49:52 changed by tnn25

Hiya,

I'm sorry if this is a dumb question. I'm not a programmer so it's a bit confusing to me when I read "future-pings-final.diff", what am I supposed to do with that code?

Sorry to bug you. Tony.

03/21/06 04:54:08 changed by masquerade

As requsted, this should clear out all the spawn_ping related code.

03/21/06 04:54:26 changed by masquerade

  • attachment future-pings-final2.diff added.

03/30/06 07:36:59 changed by ryan

  • status changed from assigned to closed.
  • resolution set to fixed.

(In [3663]) Future post pinging and cron fixups from masquerade. fixes #2469