Separate Supported Status for Trackbacks and Pingbacks

[dshanske]

In #31168, get_default_comment_status was introduced, with the intent to set default pingback and comment status for new comments.

With the current design, it isn't possible to address these items separately.

get_default_comment_status treats the 'supports' => 'trackbacks' statement as intent to open pings. While I see the rationale for why this was done, it is not consistent.

Supporting trackbacks is not actually clear to someone calling it what it is supposed to do. According to the code, excluding allowing pings by default as amended in this function and a few other places, it adds the 'Send Trackbacks' metabox.

What I am proposing here is therefore a change that might confuse backward compatibility. I can't see another easy way to separate these two.

Let's say, for the sake of fairness as a default, that if you want to be able to send pings or trackbacks, you should also support receiving them.

So, my proposal would be to separate post_type_support into two features:

'trackbacks' - which will add the trackback metabox and govern the default desire to accept trackbacks for that post type

'pingbacks' - which will set whether the default for pingbacks for a given post type is set to send/receive by default.

That handles the intent of the post type default. Then we move to the individual post issue.

So, the logic I'm proposing is that if pings are open for the post(ping_status set to open), it means it will support whatever protocols the post type supports. While it would be nice to get more granular, it would create too much of a strain on backward compatibility.

Conversely, suggesting that someone might want to turn pingbacks or trackbacks on or off for an entire post type makes sense. I can't see a scenario where someone would want support on or off for a specific post. If they decide to turn pings off, they are turning off whatever type of linkback the post chooses to support.

A plugin or theme could change this behavior using the get_default_comment_status filter that already exists.

Relate: #38207 discusses the idea of disabling trackbacks by default, but retaining pingbacks for the foreseeable future. The first step is allowing for these sensible defaults by post type, and then making the decision about default support for the 'post' post type.

I'd like to get some feedback on the proposed solution or alternatives.

[joyously]

In Slack, you said

Maybe the solution is saying that you support Pingbacks only supports them and saying that you support trackbacks supports both. That would be backward compatible

I would like to see this done. Since I've been doing theme review since that conversation, I've seen that supporting that core option is left up to the theme for adding the pingback <link> in the header.
Would this need to be modified with your new way? I'm all for making another add_theme_support() call so the theme doesn't have to know the details, and the existing themes can update to that or keep on generating the pingback <link>.

[dshanske]

The issue of generating the pingback link was referenced in #10094 and was closed as WONTFIX, but that was 7 years ago. I think, if we implement this, then there might be reconsideration on the issue of automatically generating the link header.

Link headers really shouldn't be generated by the theme...supporting a protocol isn't really a theme issue.

[dshanske]

This is a minor change that adds a post_type_supports setting for pingbacks separate from trackbacks. Therefore for a pingback or a trackback to be accepted, the post type has to declare support. This also shows or hides the interface.

Ping_status then becomes the setting that determines if a specific post accepts whichever protocol is permitted for that post type.

It means that, should we wish to disable trackbacks in the future, it can be done separately from pingbacks.

I'm not sure if this needs to wait for 5.0 or if it can go into a minor release. On one hand, it sets the defaults identically to what they are now, just using two settings instead of one.

[ocean90]

4.9.7 has been released, moving to next milestone.

[pento]

4.9.8 has hit RC, moving to 4.9.9.