Skip to content
This repository was archived by the owner on Sep 24, 2018. It is now read-only.
This repository was archived by the owner on Sep 24, 2018. It is now read-only.

Adding a trackback endpoint #2749

Description

@websupporter

Adding a trackback endpoint

As discussed (#2012), we want to seperate trackbacks and pingbacks from the comments and create own endpoints. This issue aims to collect information and critical points for the trackback/ endpoint.

Specs:

The data schema of a trackback

  • title (string|optional) The title of the entry.
  • excerpt (string|optional) An excerpt of the entry.
  • url (url|required) The permalink for the entry. Like any permalink, this should point as closely as possible to the actual entry on the HTML page, as it will be used when linking to the entry in question.
  • blog_name (string|optional) The name of the weblog to which the entry was posted.

Usual way to send a trackback to WordPress

POST http://example.com/url-to-post/trackback/

url:http://example.com
charset:utf8
title:test
excerpt:Excerpt text.
blog_name:Blogs Name

Files of interest in WordPress

wp-trackback.php - receives and saves the Trackbacks. In the end, its saved via wp_new_comment()

How should we expose the trackbacks

Follwing the /comments endpoint

/trackbacks

Collection of all trackbacks

Collection params

  • after
  • author (searchs for the ID of the user, not given, we just save the blogs name in author_name)
  • author_exclude
  • author_email (not given)
  • before
  • exclude
  • include
  • karma
  • offset
  • order
  • orderby (without the parent enum)
  • parent (Trackbacks do not have parents)
  • parent_exclude (Trackbacks do not have parents)
  • post
  • status
  • type since we seperate types by endpoint, no use

/trackbacks/?P<id>[\d]+)

Returns a single trackback object

Item schema properties

  • id
  • blog_name (equals author_name in comments)
  • url ( The referencing article URL, equals author_url in comments)
  • user_agent
  • title (The trackback title, see below)
  • excerpt (The trackback excerpt, see below)
  • date
  • date_gmt
  • karma
  • link
  • post
  • status

title and excerpt is part of the spec, but we do not have a seperate DB column for the title. Instead we save them together in comment_content:

$comment_content = "<strong>$title</strong>\n\n$excerpt";

(see https://core.trac.wordpress.org/browser/trunk/src/wp-trackback.php#L106)

My proposal would be to follow the spec here and seperate both.

Trackback creation

If we allow trackback creation via the REST API, we will violate the spec since we are responding with JSON:

In the event of a succesful ping, the server MUST return a response in the following format

<?xml version="1.0" encoding="utf-8"?>
   <response>
      <error>0</error>
   </response>

Is this a problem?

Options

  1. We could say, a JSON REST API is per definition not able to create trackbacks.
  2. We could say, this is not a problem (since for example we say, its not a trackback in the specs definition but an createable "trackback"-object. Trackback clients can go the trackback-spec conform way anyway).

If we create

Do we allow to create trackbacks not attached to a post? We do so for comments. But trackback uses a REST model, so in my view the spec defines the trackback as being attached to an object:

TrackBack uses a REST model [...] In the TrackBack system, the URL that receives TrackBack pings is the TrackBack Ping URL. A typical TrackBack Ping URL looks like http://www.example.com/trackback/5, where 5 is the TrackBack ID.

If current_user_can( 'moderate_comments' ), do we mind ! pings_open()? In the /comments-endpoint, ! comments_open() beats the cap in create_item_permissions_check()

On successful creation, do we return the created object or something similar to the specs? I mean { response : {error : 0 } } or something similar.

If the creation fails do we return the errors like we are doing all the time or more similar to the specs. {response : {error : 1, message : "error message." } }

Since we would already violating the specs, I think we could continue with our standard behavior?

The charset is part of the specs definition. I am not quite sure, how we handle this in the API.

Aside

The error messages in wp-trackback.php are not translateable yet. I think I will open a trac ticket for this, but I thought its worth mentioning.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions