I think I discovered a bug on @Mastodon. With #opengraph tags correctly set (image, title, description, site-name, url), the post shows up with: image, site-name, title (of post), description on Mastodon desktop browser.
But after adding the meta tag `fediverse:creator`, the description disappears and shows a banner at the bottom of the card "More from username". Is that on purpose? Can the og:description remain despite adding the fediverse:creator tag?
Thanks!
📢 Woo Open Graph v2.0.0 is out now!
A complete overhaul with a modern UI, faster load times, advanced share buttons, product-level SEO controls, and full Pinterest, LinkedIn & Twitter meta support.
👉 Check the full changelog : https://wbcomdesigns.com/changelog/woo-open-graph-v2-0-0/
✅ Optimized for performance, accessibility & mobile.
#WooCommerce #Plugin #Update #OpenGraph #WordPress #SEO #Social #Sharing #Pinterest #eCommerce
@joel Thanks Joel, yeah #hugo has served me really well. I don't know what will happen to my websites but I'll definitely be posting about it if something big happens like consolidation! P.S. I just updated my #opengraph tags on this deploy and they're working! Yay🎉
5/
P.S. re: the Open Graph and Twitter Cards plugin. I can't predict what plugins you may have on a WordPress site, but sometimes multiple plugins will vie to set OpenGraph tags. So you have to disable the one(s) you don't want to set the tags. For instance Yoast a popular SEO plugin has settings to disable OpenGraph...
#WordPress #Mastodon #OpenGraph
4/
Note #Bluesky has some image sharing issues, but does a much better job than #Mastodon.
Users don't want to play around. People want to toss in a link, and have it display optimally. Without measuring images, without downloading and uploading, without scaling or converting image types...
I go to some extra trouble, because I know an image massively increases engagement. But most people don't want to fuck around with the stuff...
Hopefully Mastodon will improve this some day...
#OpenGraph
3/
If anyone is running WordPress I would recommend this plugin, I've been using it for years.
Let's see if this image shares or if WordPress has an alternate image set.
Yep they do.
#WordPress #Mastodon #OpenGraph
https://wordpress.org/plugins/wonderm00ns-simple-facebook-open-graph-tags/
2/
For this reason, on a website I do not control, if the image is not roughly 2:1 aspect ratio or the #OpenGraph tags are not set, I will upload the image on #Mastodon.
On websites I do control, I have an OpenGraph plugin that allows me to specify what happens. Generally I set it to show a specified image that may or may not be the same image or the same size as the header image. I also have a default image for the whole site as a fallback.
It's not perfect but it improves shares a lot.
1/
One thing I wish #Mastodon would improve would be link preview image display. Generally sharing a link from a website that uses #OpenGraph with an image that is roughly a 2:1 aspect ratio (and sufficient size) will display the image on Mastodon. If the image is not roughly a 2:1 aspect ratio (or smaller size), you'll get nothing or maybe a thumbnail.
Example, a 1200x675 image will display as Large Image Preview, but a 1200x1200 or 1200x800 will display as a Small Image Preview or thumbnail.
New version of 🧪 OGPlayground is here with the feature of building open graph images.
Give it a try 💫.
Am I correct that Open Graph has no ability to address things at finer granularity than a page? So if you have multiple articles (either in the html <article> sense, or the common english sense), you’re just sort of out of luck?
#OpenGraph
👀 Deine Linkvorschau entscheidet, ob jemand klickt.
Mit Open Graph Tags steuerst Du Bild, Titel & Text.👇
https://www.blog2social.com/de/blog/open-graphs-so-steigerst-du-dein-social-media-engagement/
Giải thích về Open Graph là gì và tác dụng của nó trong SEO
> Xem thêm: https://tcc-agency.com/open-graph-la-gi/
> Website: https://tcc-agency.com/
#tccagency #opengraph #seo
Xem thêm:
https://www.pinterest.com/pin/1023513452830143695
https://flipboard.social/@tccpartnersagency/114662993260355531
https://myspace.com/tccpartnersagency/mixes/streammix-737358/photo/374737791
De esos bugs difíciles de encontrar ...
#whatsapp #opengraph
https://linuxmanr4.com/2025/05/30/whatsapp-open-graph-comillas/
Here’s my suggestion. When the user specifies a featured image for a post, set the og:image element in the head section of the page. When they don’t specify such an image, omit that element.
@davew We’ve gone back and forth on this over the years. It can be a bit tricky.
Our first implementation worked just like your suggestion, and like on your site right now. It worked reasonably well, but some social networks (namely Facebook) look for images in the page’s HTML whenever no og:image tag is found. And at that point, you have no control over what Facebook picks up ; it may be a image in the footer of the page, a still from an embed, or any other image it would pick up from the post, your sidebar, or your footer.
Folks were understandably not happy to see Facebook pick up random images from their site, so we decided to add that fallback ; when no image is found in the post, we try to find a representative image from the site to offer instead. We look for a site logo, a site icon, a blank image, or a custom fallback image that can be provided.
Pretty happy with how I’m generating OG images for quotes on ArmitagesArchive.com.
I designed an SVG in Inkscape, swapped the text for HEEx vars, and used Elixir to render one SVG per highlight.
Then I convert them to PNGs using resvg (fast, handles fonts well), and rsync them to prod.
It’s not fully automated yet — still thinking through how to make that part safe and clean. But overall, it works, and it looks the way I want: clean, no fluff, author credited.
PR: https://github.com/NeuroWinter/armitagesarchive/pull/21/files
#ElixirLang #OpenGraph #IndieWeb #SVG #WebDev #SelfHosted #Typography #Inkscape
My #opengraph social previews are failing to be parsed on #mastodon but not on other sites. Must be an issue in my #hugo setup. Have to troubleshoot this later.
I was installing #Anubis to my #reverseproxy, and found out that it handles #opengraph requests weirdly, even though the request isn't it. Basically it will ditch the forwarding and manually fetch the content to cache for later.
The short story is that it completely removes the proxy part and replaces it with its own request/client.
"Understanding Mastodon Preview Card Display Logic"
https://box464.com/posts/mastodon-preview-cards/
by @box464
#DeSo #Fediverse #Mastodon #OEmbed #OpenGraph #Twitter #TwitterPlayer
WishList: A proposed extension of OpenGraph
I’d like to propose an extension of the OpenGraph protocol for easy wishlist creation. A select few might be aware that I maintain a wishlist. Currently, I manually enter each gift idea into a database. It would be dead helpful, if I could just provide a link to a page that represents an item that can be given.
This post contains some marked-up HTML and I don’t know how it will look on federated sites. You may need to open the original page for best results.
Existing art that might work
OpenGraph pretty much has what I need already.
<meta property="og:type" content="product.book" />
As far as I can tell, the list of types in the product space is as follows – album, book, drink, food, game, movie, product, song, and tv_show. Some of this maps well to gift listing.
However, there are some giftable things that do not fit well within the defined product types.
I considered adding one more product value
To the product types, I would like to add something that indicates the thing that can be given. The simplest version of that is probably “gift” or “giftidea”. It would set the page as a thing that a person can gift to another. Which would make it ideal for wishlists. Something like this:
<meta property="og:type" content="product.gift" />
This is not entirely a good fit. “Product” as a gift is conceptually a little narrow and is a bit too abstract for my tastes. Plus, it could break existing validators that are unaware of the new gift product type.
The other option would be a new base type with its own subtypes. This is problematic as it would create the possibility for duplicate potential types for a given page. Fortunately, there is a better way.
A namespace for OpenGraph gift ideas and wishlists
That better way uses good old namespaces.
If the type is not the right place to insert metadata for giftables, perhaps a new schema might be called for to cover instances when the current OpenGraph types are not a good fit. This gives us, I think, three new objects – gift idea, the wishlist, and an entry in a wishlist. Maybe it would look something like this:
<head prefix="wishlist: https://example.com/ns#"><meta property="og:type" content="wishlist:gift" />
This type would provide a catchall for wishlist gift ideas that don’t fit well into the wider graph. It would also avoid breaking validators. The same namespace could be used for all wishlist, gift, and wish object data.
wishlist:gift object data
The namespace could provide other wishlist item data points – estimated price(s), and known retailers, for example.
<head prefix="wishlist: https://example.com/ns#"><meta property="og:wishlist:gift:price" content="£32.99" /><meta property="og:wishlist:gift:price" content="$99.99" /><meta property="og:wishlist:gift:retailer" content="amazon.co.uk" /><meta property="og:wishlist:gift:retailer" content="CEX" /><meta property="og:wishlist:gift:retailer" content="Harry's Local Trade Shop" />
There is a lot more data that could be added here but I’m not sure it is strictly necessary. Maybe there is something that should be here but I’ve not thought of. I think that the rest of the data – product information, could be covered by the existing OpenGraph namespace. If there are any obvious gaps, please comment, reply, or mention with your thoughts.
wishlist:list object data
If we’re going to have a custom namespace, why not also include the wishlist itself? This can be where each wish in the list could go (technical limits may apply).
<head prefix="wishlist: https://example.com/ns#"><meta property="og:type" content="wishlist:list" /><meta property="og:wishlist:list" content="https://example.com/lists/matt/birthday/" /><meta property="og:wishlist:list:user" content="Matt" /><meta property="og:wishlist:list:wish" content="https://example.com/lists/matt/birthday/tfdobl" /><meta property="og:wishlist:list:wish" content="https://example.com/lists/matt/birthday/apple" /><meta property="og:wishlist:list:wish" content="https://example.com/lists/matt/birthday/cake" /><meta property="og:wishlist:list:wish:more" content="https://example.com/lists/matt/birthday/page-2" /><meta property="og:wishlist:list:wish:more" content="https://example.com/lists/matt/birthday/page-3" />
For wishlist:list:user, I toyed with calling this “wisher” and a few other things but finally concluded that there was no good reason to invent new terms when the existing idea of a site user or member was already well established.
There are other data points that might fit inside the graph for a wishlist. Please suggest any you think I should add here.
wishlist:wish object data
Wishlist entry implies the existence of wish with details such as – the gift wished for, how badly you want it (priority), how many you want, why you want it, and the list the wish is from. The whole thing might look like this:
<head prefix="wishlist: https://example.com/ns#"><meta property="og:type" content="wishlist:wish" /><meta property="og:wishlist:wish:gift" content="https://example.com/shop/item/tfdobl" /><meta property="og:wishlist:wish:priority" content="low|medium|high" /><meta property="og:wishlist:wish:quanitity" content="1" /><meta property="og:wishlist:wish:why" content="This book is the only one missing from my collection." /><meta property="og:wishlist:wish:inlist" content="https://example.com/lists/matt/wishlist-birthday" />
There are maybe other optional elements. Please do suggest data points you think should go here. Is, for example, wishlist:wish:why the best way to label that information within the graph?
Existing OpenGraph object data
OpenGraph neatly provides most of the other data points that could matter, I think.
<meta property="og:title" content="Fictional Dictionary of Bad Language" /><meta property="og:url" content="https://example.com/giftideas/tfdobl" /><meta property="og:image" content="https://example.com/images/tfdobl.jpg" /><meta property="og:description" content="..." /><meta property="og:determiner" content="the" /><!-- ect. -->
One small privacy issue
While writing this, it occurred to me that I did not really want to put my postal address and other sensitive information online as part of a social graph. To avoid that I went ahead and assumed that the wishlist site handling the list for the user would implement some way for gift-givers to privately obtain such data if it was even needed at all. Perhaps with some sort of request/grant system or some other similar privacy controls.
Thoughts and feedback?
That’s my ideas about presenting wishlists, gifts, and wishlist items using OpenGraph. I’m open to critique, objections, praise, or any other feedback.
Would you like to see a preview of how your link to a website will appear on different platforms where it’s shared?
This great tool provides insight into whether the (correct) image, title, and introduction are displayed properly.
Better support for the #OpenGraph protocol would be a great addition, as it allows you to control what gets displayed.
