Should I rename the new column to sharing_image_id instead then? But also keeping this as sharing_image_id might make it look weird as compared to uploaded_logo_id etc. Also this is more of back-end naming since user anyway sees the translated value - Category Sharing Image.
Isn’t this used for oEmbed as well?
I’m not sure which model you’re referring to here 
My concern is if this image is used for “sharing” in any context outside of opengraph, then the name falls down.
I guess we do not?
Honestly this is such an edge case of a feature it makes me uneasy even to have it. I would much prefer if we just re-thought a lot of this just did, long/square/tall/background category images vs dictate usage upfront. Then themes that want to make use of a tall category image can, and so on.
Anyway … the current name uploaded_meta_id can not stand, that just is mega confusing… I also find uploaded_sharing_id somewhat confusing, and opengraph_upload_id not too confusing but long term limiting.
I just don’t know what the “right” thing is to do here, maybe just redo all image management on categories longer term, I don’t know.
Maybe you missed this part from the first post @sam?
The issue is right now category URLs, when shared, have no image metadata apparently. Which is odd because there are two images per category already:
- Category logo image
- Category background image
As to why one of these existing images could not be used for the social sharing metadata, and why we needed a third image here, I’m not really sure.
Our default behaviour when sharing topics is just to fall back to one of the global images:
Which is a fine default IMO.
If we unconditionally fell back to category stuff would start looking like this:
This onebox:
Would unconditionally look like:
Maybe we just thought about this whole feature completely wrong.
Maybe we simply allow people to opt in to using a category image as default sharing image. When sharing topics in this category use category image as default
Then we get rid of this extra image and confusing category setting.
-
Upside far less confusing to name and explain
-
Downside less flexible
I think offering fidelity here is important, cause it is legitimate to prefer to promote a forum image vs category image.
Also in all this mess we did not think through how “parent” categories would work in this case. Maybe you want all the subcategories to inherit this behaviour.
Honestly I think we should just revert this all for now and re-think what flexibility we want to offer here.
No no no, you misunderstand. This is about one thing and one thing only: sharing the category URL directly. Scroll up and see:
So I think we should cancel all of this third category image stuff, I honestly didn’t pay much attention to this topic because it seemed so trivial, but now that I have I see what I was originally thinking:
Re-scope this request to simply add proper metadata for the EXISTING category image when sharing a category URL. That’s it. That’s all. That is why it is a starter task!
This whole third image thing was never meant to happen, the first post kinda got us off track.
1 Like
Yeah the OP is asking for something different:
Which to me reads like David wanted ALL topics from that category to fallback to using the category image as the first fallback.
I agree, revert all of this stuff.
https://forums.gearboxsoftware.com/c/battleborn-open-beta
Can I guess look like:
And this is the ONLY scope of the change.
1 Like
This was my thinking, the first post is rather muddied in what it is proposing.
Right now category links show the site-level logo (and possibly other metadata?) which isn’t good. Category links should show category metadata.
It is not a terrible idea to have topics with no images, when shared via opengraph etc fall back to the category image rather than the site image as well…
It’s not a terrible idea but it complicates things and presents lots of questions:
-
Is this configurable? What if you prefer promoting your site logo vs a category logo which may, for example, just be a picture of a bug or something else generic.
-
What about subcategories, is this behaviour inherited to all child categories, eg: Forums has a gazzilion child categories (and a generic problem image imo, so it highlights multiple issues)
-
What about resolution, what if you want a square image vs a very wide image you use for your categories.
So even though I don’t think it is a bad idea… I do think it is a very very complicated idea.
1 Like
Just to add, the third image was added because the request mentioned this:
I know that the projects would love to be able to control this branding themselves possibly. Perhaps as another image option on the category settings? Maybe as a “Category Metadata Image”?
I agree with this and I think this was the purpose of this request and pull request.
As @sam indicated we don’t want any new images at this time. Use the existing category image.
I can change it to use category image and metadata. No issues 
But I think customers wanted ability to customize the image that is shared to social platforms. For example:
Should we ignore this for now then? Because it can happen category image might look good at top of category but when shared via other platforms, it doesn’t work well.
For now, yes we should ignore it. All we want is “better than what we have” and right now categories don’t even use their own images in the opengraph / oembed meta tags.
1 Like
I’m terribly sorry for any confusion! (I failed at effectively describing a feature request and am shamed ).
This was literally all I was looking for.
I really only meant that when linking a category directly, such as: https://discuss.pixls.us/c/software/rawtherapee
that the category logo would be used, or the background image (or possibly a third option specifically for this use).
This wasn’t about topics in the categories (the current behavior is great - using the image from the first topic post). This is only for links directly to categories (or subcategories).
[edit] - The only other possibility I was considering was if a topic in a category doesn’t have an image in the first post, it might be possible to use the same category logo/image, but this wasn’t necessary - just a nice to have.
It could even have been a single checkbox to allow use of the existing logo for this purpose.
I’m super sorry for any confusion. 
6 Likes
No worries! I wasn’t blaming you at all. We at Discourse should have been more clear what the actual starter task was!
6 Likes
Final question hopefully 
- should we use a category background image or category logo image? Or some sort of priority that if logo not present than background image?
I have made the change to use the logo image. I will make the change in code if we need to use other image.
Why in the world would we use the background image???
1 Like
I don’t know 
I m not sure where people share the category link.
Noted - to use logo image.
1 Like
This topic can be closed. PR is merged. 
3 Likes