Context and steps to reproduce
Inconsistency between the way WordPress reports the guid for posts in the feed and in the wpcom API.
- In the feed, guids is reported as an http url.
- The API reports the guid as an https url.
Look at the feed
I have a site at https://comments31.wordpress.com/ that illustrates.
Here's the feed --https://comments31.wordpress.com/feed/
Look at the <guid> elements. They are http:// urls.
Look at the API
Here's the result of a call to the API. Look for the guid value. It's https.
https://gist.github.com/scripting/f30827d884f2c67ba987baab16615e94#file-thepost-json
I've also included the code that makes the API call in the gist, linked to above.
Not a bug, but an inconsistency
This isn't a bug, but the inconsistency makes it impossible to find a database record that came from the feed if you use the API to find it.
This might be an edge case no one else sees, but it is something worth looking at.
I also understand why the feed can't be changed, because it predates the switch to https. I have the same issue with my blog http://scripting.com/ which was started long before there was an https, and changing it would break all the archive. As with WordPress, I feel the web must be backward compatible, and the move to https should not have broken older sites.
Resolution
I have to resolve this in my app, so I'm going to switch the result of the API to be consistent with the feed, knowing that the feed precedes the API. Also because we've built far more stuff on the feed than the API. ;-)
Context and steps to reproduce
Inconsistency between the way WordPress reports the guid for posts in the feed and in the wpcom API.
Look at the feed
I have a site at https://comments31.wordpress.com/ that illustrates.
Here's the feed --https://comments31.wordpress.com/feed/
Look at the <guid> elements. They are http:// urls.
Look at the API
Here's the result of a call to the API. Look for the guid value. It's https.
https://gist.github.com/scripting/f30827d884f2c67ba987baab16615e94#file-thepost-json
I've also included the code that makes the API call in the gist, linked to above.
Not a bug, but an inconsistency
This isn't a bug, but the inconsistency makes it impossible to find a database record that came from the feed if you use the API to find it.
This might be an edge case no one else sees, but it is something worth looking at.
I also understand why the feed can't be changed, because it predates the switch to https. I have the same issue with my blog http://scripting.com/ which was started long before there was an https, and changing it would break all the archive. As with WordPress, I feel the web must be backward compatible, and the move to https should not have broken older sites.
Resolution
I have to resolve this in my app, so I'm going to switch the result of the API to be consistent with the feed, knowing that the feed precedes the API. Also because we've built far more stuff on the feed than the API. ;-)