Opened 4 years ago
Last modified 2 years ago
#38197 assigned enhancement
Update Pingback function To Add Return
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | |
Component: | Pings/Trackbacks | Keywords: | good-first-bug has-patch needs-refresh |
Focuses: | performance | Cc: |
Description (last modified by )
Related to #36824.
Updated to reflect focus on the return issue.
In #36824, the proposal was to improve performance of the do_all_pings function. Part of this involves the fact that if a pending trackback URL is sent a pingback successfully, it should not also send a trackback.
The function should also optionally return which URLs were successfully pinged or a WP_Error object in the event the sending fails, etc.
This would change the signature of the function but would allow for debugging, response to errors, as well as assist in optimizing the do_all_pings function.
The original proposal was to deprecate pingback because it includes $content, a parameter better retrieved from the post itself for purposes of integrity. However, that can be addressed in other ways.
Attachments (2)
Change History (29)
#1
@
4 years ago
- Description modified (diff)
- Summary changed from Deprecate and Replace Pingback() Function to Update Pingback function To Add Return
#3
@
4 years ago
#4
@
4 years ago
You are right, handling this is difficult.
My suggestion is to start by splitting the code that sends a single ping based on a URL into a new function with a return. This will get a single true/false to build an array. We can also add split the function to find the content in a content block.
That would allow the existing function to call them but future changes in do_all_pings to call each piece independently.
In the meantime, pingback can return true if all successful, which should shutdown Trackbacks for the post_id.
#5
@
3 years ago
The patch attached returns an array with the $pagelinkedto
as the key and the result of WP_HTTP_IXR_Client::query()
as the key. Not sure if this is a sufficient solution for your needs.
#6
@
3 years ago
- Keywords has-patch added; needs-patch removed
- Milestone changed from Awaiting Review to 4.9
Needs a second opinion, but I think this is acceptable.
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
3 years ago
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
3 years ago
#10
@
3 years ago
- Milestone changed from 4.9 to Future Release
Punting this to Future Release per the 4.9 bug scrub earlier today.
#12
@
3 years ago
- Owner set to nathanatmoz
- Status changed from new to assigned
Assigning to mark the good-first-bug
as "claimed".
@dshanske Can you please have a look a the patch and provide any feedback @NathanAtmoz might need to keep this ticket moving?
#13
@
3 years ago
@DrewAPicture I do not see anything wrong with the patch. I asked for a second opinion at the time. It returns an array of statuses, so someone can evaluate whether there was an issue with any of them.
This ticket was mentioned in Slack in #core by danieltj. View the logs.
3 years ago
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
3 years ago
#18
@
3 years ago
- Keywords needs-refresh added
The change needs to be documented in the function's DocBlock.
This ticket was mentioned in Slack in #core by desrosj. View the logs.
3 years ago
#23
@
3 years ago
@desrosj I don't think the signature has changed. The arguments passed are the same. There was no return, now there is.
I think if functionality changes in a non-backward compatible way, that is a signature change. If you add a parameter or return one, the original signature is still maintained.
#24
@
3 years ago
It used to return null which is falsey, now it returns an array which truthy. I'd err on the safe side as well.
#25
@
3 years ago
- Milestone changed from 4.9.6 to 5.0
I am going to move this to 5.0 because of the potential for issues with the change in returned values. If a committer is confident in this, it can be moved back in.
#27
@
2 years ago
- Keywords needs-refresh added; dev-feedback removed
- Milestone changed from 5.1 to Future Release
It seems like it would be more useful for the array elements to be true
or a WP_Error
, with the error extracted from $client->error
.
Also, $ping_status
doesn't contain an error if discover_pingback_server_uri()
is unable to discover the URI.
Hello !
I'm actually trying to make a patch for that ticket, but can't find a clean way to handle this. The
pingback
function can ping multiple URLs in one call, how the return value can be consistent with that :WP_Error
if URL was pinged successfully or not ?WP_Error
if at leat one failed ?