[wp-trac] [WordPress Trac] #20226: Don't advertise pingback URL on resources that don't support pingbacks

[WordPress Trac]

#20226: Don't advertise pingback URL on resources that don't support pingbacks
------------------------------+-----------------------------
 Reporter:  solarissmoke      |       Owner:  wonderboymusic
     Type:  enhancement       |      Status:  closed
 Priority:  normal            |   Milestone:  4.4
Component:  Pings/Trackbacks  |     Version:  3.3
 Severity:  minor             |  Resolution:  fixed
 Keywords:  has-patch         |     Focuses:  template
------------------------------+-----------------------------

Comment (by mark-k):

 @nacin, I was actually about to reopen that ticket to argue with the
 reasoning filosofo gave to closing it, but decided that following my
 reasoning to the end will require changing how wordpress behaves as a
 pingback client which is most likely just a waste of time for everybody.

 But if we don't want to fight filosofo's reasoning we have to get to the
 conclusion that this change is wrong in the way it is done. The pingback
 standard AFAIK do not have a facility to communicate in the HTTP header
 that you do not support pingbacks, therefor what will happen based on
 wordpress core code (and with 25% of known CMS market I think it is just
 safe to ignore all other pingback implementations) is that in post that
 linking to the home page of a site there will be an attempt to send
 pingback to the site. The first request sent will be an HTTP HEAD which
 will result in no X-pingback header. Since there is no header wordpress
 will issue a full GET to get the whole page and try to parse it to get the
 rel="pingback" link. All themes that followed core theme development style
 have the rel="pingback" link on all pages including the home page. Now
 wordpress have the URL of the XML-RPC end point and issues a pingback to
 it.

 So with the current change there will be 3 HTTP request to the site for
 like 99% of the wordpress sites instead of the two that were up to 4.4.

 The only possible way forward is probably to add the pingback generation
 into a wp_head hook and then core will be able to control both aspects,
 but it will take years for themes to change to use it, although I think it
 will be faster then assuming that all themes will implement the change as
 it was done in 2016.

 And then there is the plugin override issue. The way the http header code
 works it is very hard to override a header (but maybe I am wrong here,
 corrections are welcome) therefor this code and the change in 2016 will
 prevent me implementing pingback for my home page if I wanted this
 functionality.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/20226#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform