Some blog owners make photos an important part of blog content.
When sharing a post to FaceBook, problems are seen with photo content. In some cases, this is because of how the photos were added into the post, when using Post Editor.
We've known about problems with photos installed using drag and drop, and post editor, for a few years. Drag and Drop photos, in some cases, are stored as "Base64" content - with the photo content hosted in the post, instead of Google Photos (or Picasa).
Photos added to posts in post editor, using "drag and drop", have been a problem for many years.
Base64 hosted photos make posts abnormally large.
Posts containing "Base64" encoded photos are abnormally large - and will cause problems with the index pages, and auto pagination. That is a nuisance - but just that.
With posts shared to social media, such as FaceBook and Twitter, photos hosted using Base64 become more than a nuisance. When normal posts are shared to FaceBook, OpenGraph code is used to identify key post content - such as a photo to accompany the shared post.
Open Graph code uses URLs to reference photos.
OG code uses HTML / XML tags, in template code - with a URL identifying a shared photo. A post that contains Base64 hosted photos won't have URLs identifying the photos - it will have the actual photo content.
When shared to FaceBook, the photo must be converted to normal Google Photo hosted content, so it can be shared using a URL - as normal photos are shared, using OG code. If shared using Base64 content (if OG were to support Base64), the post, again, becomes abnormally large.
Base64 hosted photos simply present one more complication, when sharing posts to FaceBook, Twitter, and other social services.
Some blog owners publish posts that contain photos added using drag and drop. Some drag and drop installs result in Base64 hosted photos - which must be converted to Google Photos hosted content, when shared to FaceBook or Twitter.
When sharing a post to FaceBook, problems are seen with photo content. In some cases, this is because of how the photos were added into the post, when using Post Editor.
We've known about problems with photos installed using drag and drop, and post editor, for a few years. Drag and Drop photos, in some cases, are stored as "Base64" content - with the photo content hosted in the post, instead of Google Photos (or Picasa).
Photos added to posts in post editor, using "drag and drop", have been a problem for many years.
Base64 hosted photos make posts abnormally large.
Posts containing "Base64" encoded photos are abnormally large - and will cause problems with the index pages, and auto pagination. That is a nuisance - but just that.
With posts shared to social media, such as FaceBook and Twitter, photos hosted using Base64 become more than a nuisance. When normal posts are shared to FaceBook, OpenGraph code is used to identify key post content - such as a photo to accompany the shared post.
Open Graph code uses URLs to reference photos.
OG code uses HTML / XML tags, in template code - with a URL identifying a shared photo. A post that contains Base64 hosted photos won't have URLs identifying the photos - it will have the actual photo content.
|
| This photo was installed, using drag and drop. Interestingly enough, it is not Base64. It is possible that Blogger no longer uses Base64 encoding - which would explain why the problem with OG code is rather irregular. |
When shared to FaceBook, the photo must be converted to normal Google Photo hosted content, so it can be shared using a URL - as normal photos are shared, using OG code. If shared using Base64 content (if OG were to support Base64), the post, again, becomes abnormally large.
Base64 hosted photos simply present one more complication, when sharing posts to FaceBook, Twitter, and other social services.
Some blog owners publish posts that contain photos added using drag and drop. Some drag and drop installs result in Base64 hosted photos - which must be converted to Google Photos hosted content, when shared to FaceBook or Twitter.
Comments