-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pass WordPress post_ids as custom metadata to Parse.ly #1329
Comments
We need to be careful with this, since Parse.ly uses canonical intentionally, instead of
|
@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. |
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, don't worry about it. I'm very happy that we realized it that soon. |
So if the suggestion was to use the second option (which we do not want), we should see if the first one can help. |
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. |
So should we implement this just in case if we ever need it in future ... OR .... should we close the issue? |
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? |
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. |
@acicovic The work to add the |
Yeah, I'll bring this to Sal and Keith once we know
|
@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 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. |
@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. |
@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! |
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 |
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.The text was updated successfully, but these errors were encountered: