Return to Answer

Post ID's are not necessarily unique. Ref. my answer on the post you linked to: http://wordpress.stackexchange.com/a/209832/71131

Within a Wordpress Multisite Network, id's are not unique. A blog post on one site can have the same id as a blog post on another site. Probably since each site has a separate database/table. (This just happened to me.) This is problematic if you in your code (in a plugin, or in a third party service communicating with the Wordpress installation) are using the Wordpress id's to refer to a specific unique blog post on the Wordpress Multisite Network.

Therefore, I recommend using $post->guid instead, which is what Wordpress has dedicated as the Global Unique IDentifier. Thanks to @Mark Kaplun for making me aware of this. NB: The guid must be in lowercaps for it to work.

@guidod mentioned the risk that "[the guid can] inadvertently be replaced with new URLs when the website gets migrated", because someone might do a find/replace on all URI's, and/or want to update the URI part of the GUID as well, even though they shouldn't ever change anything in the GUID. To mitigate this risk, you can also store the $post->ID as a backup. If your third party service accessing and referring to blog posts in your Wordpress installation cannot find a post based on the guid, then the post's ID can be attempted (but remember to contextualize it based on the appropriate blog/site, if you're doing it on a multisite installation).

Post ID's are not necessarily unique. Ref. my answer on the post you linked to: https://wordpress.stackexchange.com/a/209832/71131

Within a Wordpress Multisite Network, id's are not unique. A blog post on one site can have the same id as a blog post on another site. Probably since each site has a separate database/table. (This just happened to me.) This is problematic if you in your code (in a plugin, or in a third party service communicating with the Wordpress installation) are using the Wordpress id's to refer to a specific unique blog post on the Wordpress Multisite Network.

Therefore, I recommend using $post->guid instead, which is what Wordpress has dedicated as the Global Unique IDentifier. Thanks to @Mark Kaplun for making me aware of this. NB: The guid must be in lowercaps for it to work.

@guidod mentioned the risk that "[the guid can] inadvertently be replaced with new URLs when the website gets migrated", because someone might do a find/replace on all URI's, and/or want to update the URI part of the GUID as well, even though they shouldn't ever change anything in the GUID. To mitigate this risk, you can also store the $post->ID as a backup. If your third party service accessing and referring to blog posts in your Wordpress installation cannot find a post based on the guid, then the post's ID can be attempted (but remember to contextualize it based on the appropriate blog/site, if you're doing it on a multisite installation).

Post ID's are not necessarily unique. Ref. my answer on the post you linked to: http://wordpress.stackexchange.com/a/209832/71131

Within a Wordpress Multisite Network, id's are not unique. A blog post on one site can have the same id as a blog post on another site. Probably since each site has a separate database/table. (This just happened to me.) This is problematic if you in your code (in a plugin, or in a third party service communicating with the Wordpress installation) are using the Wordpress id's to refer to a specific unique blog post on the Wordpress Multisite Network.

Therefore, I recommend using $post->GUID instead, which is what Wordpress has dedicated as the Global Unique IDentifier. Thanks to @Mark Kaplun for making me aware of this.

@guidod mentioned the risk that "[the GUID can] inadvertently be replaced with new URLs when the website gets migrated", because someone might do a find/replace on all URI's, and/or want to update the URI part of the GUID as well, even though they shouldn't ever change anything in the GUID. To mitigate this risk, you can also store the $post->ID as a backup. If your third party service accessing and referring to blog posts in your Wordpress installation cannot find a post based on the GUID, then the post's ID can be attempted (but remember to contextualize it based on the appropriate blog/site, if you're doing it on a multisite installation).

Post ID's are not necessarily unique. Ref. my answer on the post you linked to: http://wordpress.stackexchange.com/a/209832/71131

Within a Wordpress Multisite Network, id's are not unique. A blog post on one site can have the same id as a blog post on another site. Probably since each site has a separate database/table. (This just happened to me.) This is problematic if you in your code (in a plugin, or in a third party service communicating with the Wordpress installation) are using the Wordpress id's to refer to a specific unique blog post on the Wordpress Multisite Network.

Therefore, I recommend using $post->guid instead, which is what Wordpress has dedicated as the Global Unique IDentifier. Thanks to @Mark Kaplun for making me aware of this. NB: The guid must be in lowercaps for it to work.

@guidod mentioned the risk that "[the guid can] inadvertently be replaced with new URLs when the website gets migrated", because someone might do a find/replace on all URI's, and/or want to update the URI part of the GUID as well, even though they shouldn't ever change anything in the GUID. To mitigate this risk, you can also store the $post->ID as a backup. If your third party service accessing and referring to blog posts in your Wordpress installation cannot find a post based on the guid, then the post's ID can be attempted (but remember to contextualize it based on the appropriate blog/site, if you're doing it on a multisite installation).

Post ID's are not necessarily unique. Ref. my answer on the post you linked to: http://wordpress.stackexchange.com/a/209832/71131

Within a Wordpress Multisite Network, id's are not unique. A blog post on one site can have the same id as a blog post on another site. Probably since each site has a separate database/table. (This just happened to me.) This is problematic if you in your third party service are using the Wordpress id's to refer to a specific unique blog post on the Wordpress Multisite Network.

Therefore, I recommend using $post->GUID instead, which is what Wordpress has dedicated as the Global Unique IDentifier. Thanks to @Mark Kaplun for making me aware of this.

@guidod mentioned the risk that "[the GUID can] inadvertently be replaced with new URLs when the website gets migrated", because someone might do a find/replace on all URI's, and/or want to update the URI part of the GUID as well, even though they shouldn't ever change anything in the GUID. To mitigate this risk, you can also store the $post->ID as a backup. If your third party service accessing and referring to blog posts in your Wordpress installation cannot find a post based on the GUID, then the post's ID can be attempted (but remember to contextualize it based on the appropriate blog/site, if you're doing it on a multisite installation).

Post ID's are not necessarily unique. Ref. my answer on the post you linked to: http://wordpress.stackexchange.com/a/209832/71131

Within a Wordpress Multisite Network, id's are not unique. A blog post on one site can have the same id as a blog post on another site. Probably since each site has a separate database/table. (This just happened to me.) This is problematic if you in your code (in a plugin, or in a third party service communicating with the Wordpress installation) are using the Wordpress id's to refer to a specific unique blog post on the Wordpress Multisite Network.

Therefore, I recommend using $post->GUID instead, which is what Wordpress has dedicated as the Global Unique IDentifier. Thanks to @Mark Kaplun for making me aware of this.

@guidod mentioned the risk that "[the GUID can] inadvertently be replaced with new URLs when the website gets migrated", because someone might do a find/replace on all URI's, and/or want to update the URI part of the GUID as well, even though they shouldn't ever change anything in the GUID. To mitigate this risk, you can also store the $post->ID as a backup. If your third party service accessing and referring to blog posts in your Wordpress installation cannot find a post based on the GUID, then the post's ID can be attempted (but remember to contextualize it based on the appropriate blog/site, if you're doing it on a multisite installation).