Pass WordPress post_ids as custom metadata to Parse.ly

[mehmoodak]

As of now on Parse.ly we only have canonical urls to uniquely identify post and since Prod and Non-Prod environment can configure differently so its better to have post_ids also which can help us to uniquely identify posts.

[danielabloch]

We need to be careful with this, since Parse.ly uses canonical intentionally, instead of post_id

Note that it is possible to specify an ID value in your metadata rather than a canonical URL. When provided, a post ID will take precedence over the canonical URL value, and we will group your articles by that ID instead. We do discourage including page ID values when possible as grouping articles by canonical URL is a simpler and more reliable implementation. (https://docs.parse.ly/the-parsely-canonical-url/)

[acicovic]

@mehmoodak, in regard to what @danielabloch posted, we should see what the implications of this are.

I think we should have a list of the main reasons we want to implement this, what will be the gains and the possible disadvantages. We should not rush this until we have all the data.

If we decide to go forward with this, we should also probably add it as an option (under Requires Recrawl) that will be off by default.

[arhine]

If we are talking about sending this as extra_data that would be available via the API, that's fine. We've got customers who do that, and I'm more than happy to walk you through how that works.

If we are talking about sending this as a post ID in metadata to be used in place of a URL, we're going to push back hard against that. We definitely do not want to go that route for many reasons.

[abelsonlive]

@acicovic @arhine This is on me. I advised the plugin pod to go this route and didn't realize the issues with it.

[acicovic]

@abelsonlive, don't worry about it. I'm very happy that we realized it that soon.

[acicovic]

So if the suggestion was to use the second option (which we do not want), we should see if the first one can help.

[arhine]

While we do allow customers to specify a post ID in lieu of a canonical URL, there are parts of our system that still rely on a canonical URL. So what ends up happening is that we take the first URL we receive for a given post ID and we use that as the canonical value, displaying that in dash, etc. This often causes a lot of problems.

We also do not support post IDs at a network level. Not as relevant for you as we don't have network-level API data available, but yet another reason why we prefer URLs.

The /analytics/post/detail parameter also does not support a post ID as a query value: https://docs.parse.ly/api-analytics-endpoint/#2-get-analytics-post-detail. So even if you send a post ID as the canonical value, you can't query the API and get data back based on that.

[mehmoodak]

If we are talking about sending this as extra_data that would be available via the API, that's fine.

So should we implement this just in case if we ever need it in future ... OR .... should we close the issue?

[acicovic]

From what is said here, it seems to me that the Post ID is not that useful from an API standpoint, unless there are plans to change this in the future. So if there are no plans, we can close this issue. Does anybody know if there are such plans?

[danielabloch]

I'd recommend keeping this issue open but moving it out of any milestones. If we want to revisit this at a later date, having this visible for background will be helpful.

[abelsonlive]

@acicovic The work to add the post_id to the API (both as a query parameter and in the response body) has been completed if we should still want to go that route. But I'm guessing it was never included because we encourage people to avoid using it?

[danielabloch]

Yeah, I'll bring this to Sal and Keith once we know

1. Why we want to implement this
2. What we hope to gain (advantages)
3. What we may lose (disadvantages)

[acicovic]

@abelsonlive, thank you for that work!

I think that this work would be useful in the context of this thread if we are able to send the WordPress Post ID as extra_data, without any undesired side effects to the Parse.ly side of things.

My understanding is that In this case, we would be able to send WP Post IDs and filter by them as well when querying the API.

[arhine]

@acicovic At this time, I don't think it's possible to use the custom metadata as a query parameter. If you look at the /analytics/post/detail documentation, URL is the only param that can be passed: https://docs.parse.ly/api-analytics-endpoint/#2-get-analytics-post-detail

The resulting record will include the custom metadata, which would include the post ID if sent, and I can give you an example of how that JSON would look. But that field does not appear to be queryable.

Based on my experience and reading of our documentation, there isn't any means to specify an ID value and get data back for a single post. That may be something that needs to be explored with the product team if that's desired.

[acicovic]

@mehmoodak, @danielabloch, I think we can close this due to staleness and complexity of implementation, because it would need work from the Parse.ly side as well. We can reopen this if needed in the future. Let me know if you think otherwise.

Thanks!

[danielabloch]

I would suggest we keep it open but deprioritize it. If we close it we might think we did this work, when we did not. Maybe we can add a tag / label for issues that Need Backend Support