Shouldn’t be much work and it would make shared articles look a lot better on Telegram, Facebook and other sites. I would implement it myself but you’re making it rather hard to contribute :-/
Take a look at this for testing:
https://developers.facebook.com/tools/debug/
Documentation is here: http://ogp.me/
The facebook link is just a tool to test if everything gets picked up correctly 
Probably not the best way to request a feature. 
Anyway, opengraph, twitter cards, etc. is actually really easy to implement but I’m not going to contribute to this because I loathe social networks.
Nevertheless, I recently did this for a site I had to build and used this CSS-Tricks’ (no affiliation) article on doing it efficiently. It is true that places like Twitter/Facebook require an account to use their validator.
op, how about you read the contribution guide and do accordingly?
Post your idea on the forums. Preferably post diffs if you got them. Mention your gitlab username.
If your idea was accepted, request developer permissions for the project via Gitlab.
Where’s the problem? Is it the acceptance of the idea? I thought that that would be implied by granting permission for the project…
well for example i’m not seeing any diffs. what i’m seeing instead is what seems to be unwarranted sass and links to facebook. to be quite honest neither of those two things makes me particularly excited.
e:
The Open Graph protocol enables any web page to become a rich object in a social graph. For instance, this is used on Facebook to allow any web page to have the same functionality as any other object on Facebook.
you know what i don’t think i want tt-rss to become “an object in facebook social graph” either.
This diff should (in theory) be sufficient: https://paste.debian.net/plainh/47440ef0
I understand your concerns, however those tags are not just used by facebook since the Open Graph protocol is an open standard. For example this library (GitHub - oscarotero/Embed: Get info from any web service or page) which could be (and is probably) used for multiple purposes apart from so called “social media”.
<meta property="og:url" content="“.(isset($_SERVER[‘HTTPS’]) ? “https” : “http”) . “://$_SERVER[HTTP_HOST]$_SERVER[REQUEST_URI]”.”"
uhhhh
Is there a better way to include the full URL? :-/
e:
Apparently, og:description cannot be empty. I’m not entirely sure what to put there. Maybe “Tiny Tiny RSS Article” ?
e2:
It seems to work well even without og:url
e3:
So this would be the minimum required: debian Pastezone
e4:
Also, we could clean up the indentation while were at it: Debian paste error
BTW: Your gitlab server uses Open Graph meta tags so that this discourse forum can generate the preview found here
https://discourse.tt-rss.org/t/contributing-code-via-gitlab-the-guide/25
i don’t want to disappoint you and maybe this thing has its uses beyond ad metrics or facebook data mining but when i read stuff like this
Facebook introduced Open Graph in 2010. It promotes integration between Facebook and other websites by allowing them to become rich “graph” objects with the same functionality as other Facebook objects.
Put simply, a degree of control is possible over how information travels from a third-party website to Facebook when a page is shared (or liked, etc.). In order to make this possible, information is sent via Open Graph meta tags in the part of the website’s code.
or this
Why Marketers Need to Know about Open Graph
Social media sites are the major drivers of most of the web’s traffic. Consequently, the ability to harness the power of social meta tags is a vital skill for today’s marketers. The tags can affect conversions and click-through rates hugely.
it just makes me want to go take a shower because it feels like i was rolling in literal shit, pushed out by a collective gaping sphincter of facebook marketers and SEO specialists. so i’m not gonna touch any of this with a ten foot pole, let alone implement within tt-rss. ew.
consider me a luddite or whatever, i don’t really care. as far as i’m concerned social media and all this shit invented for and by it can go die in a fire.
e: and yes i understand it’s just a bunch of meta tags and basically no normal person would care, it’s the principle of it that matters to me.
Would it be possible to put this in a plugin so you could keep it away from the main codebase?
URL based sharing is a plugin already (even though not all endpoints are properly decoupled from main code because legacy code), i’m not sure adding plugin hooks to a plugin is a good idea, seems a bit too meta. although making a separate share plugin just to modify the output a bit is rather dumb, so eh.
e: i’m looking at the code, will post a bit later. so far things look ugly.
e2: i can pipe rendered article html through a hook which would make it potentially useful for other plugins (at this point it’s impossible to modify actual finalized article layout freely). to inject meta elements the plugin would then parse html into a DOMDocument and render it back after modifications. how does that sound?
BTW: Your gitlab server uses Open Graph meta tags so that this discourse forum can generate the preview found here
the cancer was here all along 
Just so we’re all clear (bizarre coding practices aside): This diff actually doesn’t implement OG properly. If you’re going to implement something, at least adhere to its standards and properly limit the length of fields per their spec (title, description, etc. all have character limits which are not accounted for here). Furthermore, the description is the whole point. What’s left? The link? That could just be shared in a conventional Facebook post. If you’re going to implement this so it looks nice, works as a proper Facebook object, etc.; do it properly. Put a description in there (e.g. an excerpt of the article body), properly limit the field lengths and HTML escape the data, use an actual image from the article (if it’s available). And so on…
yeah i kinda wanted to mention this too, you’re really missing the point with og:description. i actually went to read the spec because this just felt wrong and ended up ranting instead.
btw the head image could be the first img in the article but it won’t work half the time (because first img is going to be an invisible 1px tracker or something). i had to screw around with this on android when i was doing the image-summary layout and it’s gonna be really hard to implement without being able to check image dimensions (which would be hella slow doing synchronously server-side). good luck lol.
e: https://tt-rss.org/fox/tt-rss/commit/e50a64791687c27ba6a76df84a0e3b32dfd77936
What do you think?
this is now implemented in trunk. everyone seems to be using it, i figured might as well, i guess. :shrug:
i’ve also added the aforementioned simple flavor image picker (goes by attachments first, first img tag then).
e: one issue, not sure where og:url should lead to tbh
