Automattic
Publicize to Bluesky: post images are not pulled into Bluesky post
Impacted plugin
Jetpack, Social
Quick summary
When publicizing a post to Bluesky, an image can be attached to the post, but right now we only do so if the post includes a featured image. It would be nice if we could also pick images from the post content as well.
Steps to reproduce
- Start with a site that's connected to WordPress.com.
- Go to Jetpack > Settings > Sharing
- Connect your site to your Bluesky account
- Go to Posts > Add New
- Write a new post with a title, some content, and insert an image block. Add an image there.
- Hit Publish
A clear and concise description of what you expected to happen.
I would expect the post that gets publicized to Bluesky to display that image in the post preview.
What actually happened
Instead, only a link is displayed.
Impact
Most (> 50%)
Available workarounds?
No but the platform is still usable
If the above answer is "Yes...", outline the workaround.
No response
Platform (Simple and/or Atomic)
Simple, Atomic, Self-hosted
Logs or notes
Here is a screenshot of 3 different scenarios:
- A post with no image in the post content, but a featured image -> That featured image is picked in the post preview.
- A post with an image in the post content, and that same image as a featured image -> That featured image is picked in the post preview.
- A post with an image in the post content but no featured image -> That is the bug we're talking about here
OpenAI suggested the following labels for this issue:
- [Feature Group] User Interaction & Engagement: The issue relates to how users share and promote their posts on social media platforms, specifically Bluesky.
- [Feature] Publicize: This feature is directly relevant as the issue pertains to the functionality of publicizing posts to Bluesky through Jetpack.
- [Feature] Social Media Integration: The issue involves integrating with a specific social media platform, Bluesky, which is a key aspect of this problem.
- [Feature] Sharing: The feature relates to sharing content across different platforms, which is what users are trying to achieve with this functionality.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
We've shied away from doing this as it's hard for someone to know which image is going to be used. We've had people contact us before as we've ended up sharing an image which they didn't want shared in the social post. The Jetpack OpenGraph code tries to pull in images from the post, including the gallery block (which has led to other problems).
With the paid plan, you can attach an image or video to your social post, so that gives you a way of explicitly choosing which image is shared.
As in the past, we have selected images from the post, I'm not sure if the behaviour is consistent. It might be that Facebook, Tumblr etc do this, whereas the newly supported networks don't.
+1 for what Paul said.
It's not a good idea to pull images from post content. It can be problematic in many ways.
If you scan the post content for images, you will, of course, try to get the final content of the post passed via the_content filter. It's possible that there are images in the content which are never meant to be shared. For example, it's possible that there are sharing buttons added to the post content that have icons of social media platforms as images. Likewise, there can be any other icons rendered as images. We don't want to share those.
Likewise, there are many other cases where the images in the content are never meant to be shared elsewhere. Thus, being super explicit is better.
There has been an attempt to do it for Instagram when there is no featured image.
- #38759
It's not a good idea to pull images from post content. It can be problematic in many ways.
If we do not want to pull images from post content, then I think we should be consistent about it. Right now, we do pull images from post content for Open Graph Meta tags for example, as well as for Related Posts' previews, Twitter cards, Pinterest sharing, and the Top Posts widget / block. We also use images from post content when publicizing to Tumblr.
Given that we've been pulling images from post content for a while for other features, maybe being consistent would mean doing the same for newer features like Bluesky?
it's possible that there are sharing buttons added to the post content that have icons of social media platforms as images. Likewise, there can be any other icons rendered as images. We don't want to share those.
I don't think those would be caught by our existing logic, since such images would not be big enough to be included in the list of post images.
If we do not want to pull images from post content, then I think we should be consistent about it. Right now, we do pull images from post content for Open Graph Meta tags for example, as well as for Related Posts' previews, Twitter cards, Pinterest sharing, and the Top Posts widget / block. We also use images from post content when publicizing to Tumblr.
We discussed it in today's team call and reached to the conclusion that we should be consistent and should probably not use images from the content for any feature at all.
So, the plan is to deprecate using content from images for OG tags etc. for all the new posts to avoid breaking the old posts and probably show a notice or something somewhere to let the users know about the new behavior.
Yes, we also said that perhaps we could offer a pre-publish prompt to select a featured image, offering options from the post content.
What do you think about this @jeherve?
While picking the Featured Image makes sense, I don't know that it would be enough to satisfy the needs of all our customers.
- Some themes do not display featured images so folks aren't used to defining one, it's not part of their publishing flow.
- Some CPTs do not offer support for featured images so you do not get the option to define one for your posts.
- Some interfaces / editors do not offer the option to define a featured image.
- In some editors, like in the WordPress / Jetpack mobile apps, it's an extra hurdle to define a featured image before to hit Publish. When you're on the go and want to publish quickly, you may not be interested in anything more than uploading an image and hitting publish.
- Over many years we've used more than featured images in OG tags. In some scenarios, we even include multiple images from the post content (like when you post a gallery), allowing for better post previews on Facebook for example. I worry folks have gotten used to this, this is their expectation now.
I do understand that we do always want the Featured Image to be the most important image, but I still think we should offer a fallback when that's not available.
perhaps we could offer a pre-publish prompt to select a featured image, offering options from the post content.
Wouldn't this be close to our Social Image Generator?
I still think we should offer a fallback when that's not available.
Thanks. I understand this, but we have had reports from customers that find it surprising when an image is picked for them, and it's not something that can be easily turned off - without filters etc. It's not obvious what's going to happen and what the post will look like when it's shared. I feel like it needs to be a conscious decision.
Wouldn't this be close to our Social Image Generator?
No I mean more that there would be prompt saying something like "You haven't selected a featured image, why not use one of these we've picked from your post?"
We have a couple of problems. One is consistency. All the newer networks we've added won't use the Jetpack Post Images, so either way we make it consistent it's going to be a change in behaviour not just for Bluesky. The other is that Social Previews doesn't know which image Jetpack Post Images will choose (and I don't think will support multiple images). This is obviously already a problem with some networks, but we'd probably need to fix that. I feel like we'd need to create an enpoint to query which image(s) would be used, otherwise we would need to replicate the logic in the browser extension and keep them in sync. I think ensuring the Social Previews are accurate is important, as we have had a lot of confusion with people not realising what the social post will look like, and the experience is far from WYSIWYG.
If we feel like making it consistent by having images used from the post content for all networks, then we can go that way, but I think we would want to make sure it can be turned off at various levels (globally, by post type, by category, for individual posts etc), probably by a filter for now.
Would that be your preference @jeherve?
No I mean more that there would be prompt saying something like "You haven't selected a featured image, why not use one of these we've picked from your post?"
Ah, I see. This would be nice. It may even be something interesting in Core, an invitation for folks to set a Featured Image before to hit Publish.
Consistency is definitely key imo. I think it would be fine to only use the Featured Image, but:
- It should happen everywhere.
- There should be a filter that folks can use to switch to pulling any image from Jetpack Post Images, so folks can revert to the old behavior.
- Implementing the prompt you mentioned would go a long way towards making the new behavior less of a breaking change.
I agree that consistency is key, but as there has been this inconsistency across the networks for some time, is this still a high priority bug in your opinion?
There should be a filter that folks can use to switch to pulling any image from Jetpack Post Images, so folks can revert to the old behavior.
I think there's an additional piece of work we need to do with Social Previews. As this logic is server side, and other plugins could have an effect on which image is used as the og:image, we probably need to have an API call, which renders the head of the document and parses out the meta tags.
We were thinking that we would keep the old behaviour on old posts, but do you think it would be ok to switch to this new way of doing it for all?
as there has been this inconsistency across the networks for some time, is this still a high priority bug in your opinion?
We can probably lower it down to "Normal". 👍
As this logic is server side, and other plugins could have an effect on which image is used as the og:image, we probably need to have an API call, which renders the head of the document and parses out the meta tags.
Yes, I think that would make sense. The good news is, with your recent work in #40213, this is becoming more possible today!
Related issue: #16876
We were thinking that we would keep the old behaviour on old posts, but do you think it would be ok to switch to this new way of doing it for all?
I think so, as long as we document it and let HEs know.
Got it, thanks @jeherve! I think we have a way forward, but maybe we should wait until #40213 (or an alternative solution) is merged, to make this simpler.
This issue has been marked as stale. This happened because:
- It has been inactive for the past 6 months.
- It hasn’t been labeled `[Pri] BLOCKER`, `[Pri] High`, `[Type] Feature Request`, `[Type] Enhancement`, `[Type] Janitorial`, `Good For Community`, `[Type] Good First Bug`, etc.
No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.