Open rgmears opened 7 years ago
Usually SEO extensions will take care of that. But I think this is an awesome improvement to the core articles. Let's get someone from dev to answer that.
The problem is each platform has its own metadata criteria, and usually its own image sizing criteria. So you'd end up with a social sharing tab just to configure all of that properly, even if it were only done for Facebook and Twitter.
Any hopes for an easy way, where Joomla will resize/crop to each media, and that's it? I mean, if the user wants something advanced, a SEO or social media extension is in order. We would just provide the very very basic stuff.
Joomla already has an image processing API, so programmatically we can do image manipulation pretty easily (but, it requires an optional PHP extension on the hosting server, and it's not one that we require for Joomla to run).
Like I said, to do it right, you really have to make it configurable on a per-platform basis. The absolute most you could possibly get out of core is a single field that lets the user choose an image for use on social platforms, but we start running into the problem of we would then have to ship code in core that explicitly sets meta tags (or whatever attributes are in use for different platforms) so the right image is automatically selected when sharing to Facebook, Twitter, etc. That's the part where you start running into conflict, should core be shipping code to optimize sharing for targeted social media platforms which may or may not be relevant to our global audience. We already get enough backlash for supporting Google services with optional plugins.
Generally, the first image to display on a page is the one FB or Twitter use. Although FB often provides a selection of images that the sharer can choose from.
Here is how I've done it on a page that doesn't have images: http://www.silverplains.ca/site-visit.html HTML: <div class="insert_image not"> <img src="/images/site/yard_front_small.jpg" alt="yard front"> </div> CSS: .item-page .insert_image.not { height: 1px; margin: 0 0 0 -1px; overflow: hidden; width: 1px; }
The image called is a cropped (width) version of the most recent image in the slideshow. It does not display on the page. The code for it is included in the beginning of the article. I leave the scaling of the image to the social media site.
The relevant meta tags are:
<meta name="twitter:image" content="http://www.silverplains.ca/images/site/yard_front_small.jpg" /> <meta property="og:image" content="http://www.silverplains.ca/images/site/yard_front_small.jpg"/>
If we are only going to do Facebook and Twitter then sure. Those may be the prevalent platforms today, but they aren't the only ones. In general as a project we have to be careful about what external services we provide inbuilt integrations for in the core distribution.
Would other social platforms not also use the first image?
Possibly, depends how they're configured I guess (I know Pinterest share links have to be configured with the image URL as a query string variable if you're doing a share button, but I don't know if it has something to automatically grab an image if one isn't given), but it's still showing a bias toward select platforms by making those configurable directly within core.
Honestly I'm not opposed to the idea at all, it's a feature that in today's web you almost have to have. I do have to play the balancing game with it though and point out there are issues (even if they're more political and/or social) with taking this and accepting it unchallenged.
If, along with Intro Image and Article Image, there was a Social Image selection then, if there is a Social Image, the appropriate code could be inserted at the top of the article and the image itself set to NOT display with the core CSS.
Of course, as it is now, the Article Image would be the Social Image.
Ok, Robert, how about you do a quick research on other ways of informing a social media site about the page image?
See if there is an universal meta tag we can use for that, because I don't find a hidden div an acceptable solution for this. It would create problems with templates, because they use wildly varied structures.
Sent from my Samsung SM-G930W8 using FastHub
I use a plugin to generate OG tags: Perfect Open Graph Tags (https://extensions.joomla.org/extensions/extension/site-management/seo-a-metadata/perfect-open-graph-tags/). It has several options including choosing a default image. And it writes the OG Tags which Joomla core does not presently do. It selects the first image in the Content Component or uses the default if there is no image.
Apparently Drupal has a Metatags module that writes the appropriate code in the HEAD section. https://drupal.stackexchange.com/questions/37715/adding-open-graph-metatags-to-head
I agree a "hidden" image is not the best solution. However, if there was an option to specify a Social Image and that code got written into the HEAD section that would be great. Then there would be no need for causing the image itself to not display.
The other issue we need to keep in mind is, sometimes facebook is just broken. There are times when I HAVE to use their debug tool to skim my page several times before it finds an image that's tagged correctly using an OG plugin. If we add this to the core, and it APPEARS to be buggy, we may get flack over something that we have no control over. Just a thought. :)
Sometimes, if cache is enabled, you have to clear the cache for the proper image to display when using the debug tool.
So, an og tag will cover all social networks?
Sent from my Samsung SM-G930W8 using FastHub
No. Twitter has its own tags which are called Twitter Card Tags. The Open Graph plugin writes both.
See "The relevant meta tags are" above.
If I'm not mistaken, Facebook designed Open Graph as a universal standard. But, largely it seems only Facebook actually uses it.
I did some research. Facebook, Pinterest, and Google +use it. Twitter will read it, but it prefers its own cards. So OG is compatible with the biggest 4, plus og was designed as open, and any social media engine can adopt it.
There is a chance that, by supporting Open Graph, we may get flak by not supporting another formats (and I'm guessing some are open as well, just not relevant enough), even though we tell people that OG is open and everyone should adopt it, and it is not our fault if they don't.
About it not working, we just put a message that og may take a few days to take effect (and that was a joke, of course).
@mbabker Is it worth to support a single open format (og) and let the rest out served by plugins?
This harkens to the days when the W3C got started establishing standards. FB, being proprietary, isn't likely to get much co-operation in setting a universal standard.
Many universal standards started from closed companies and proprietary formats.
Even Google search will read OG and add, for example, video thumbnails to search results. It is up to each system/engine/media to add support for OG or not.
I'm not opposed to this in general, most builds I do have some kind of extension or support for social sharing and hooking up all the extras needed for that. Just gotta make sure people are aware of concerns that may exist, and be aware that the project does have a market position that building in support for select third party services can have unintended consequences.
Well, if there was an option -- alongside of the other images -- when composing an article to select Social Image and have that code written into the HEAD section that would be great. A wrinkle, though, might be that if a Social Image is not selected then no image displays in a share. Conversely, if the OG tag comes from the first image on the page by default and from the Social Image (if there is one) then the wrinkle would be gone.
@mbabker That's my question: Is it worth it building this considering all those issues at hand? There is a good chance it isn't, but considering that the free plugins will generate OGs from the main image, without giving the user a chance of selecting something else, it may even the scale.
@rgmears If we build this, not adding a social image will prevent the og from being generated by the system. Not presenting an og is better than presenting an empty one.
And Robert, we will always take into consideration not hurting the bottom line of extension/plugin/template providers when evaluating new features. Even free ones have use to providers, as marketing tools.
I agree. So, if we build this then it would have to function as an if "no Social Image" then use "first image" ... the way the plugin works.
Nope. If there is no social image, we won't create the meta tag, so the user have the ability to select something else at post time (the logo perhaps?).
This will be a content plugin, and will have to be enabled by the user/admin. It should ship disabled, to avoid conflict if the user/admin wants to install other social ext.
When the new helper system is ready, we can have a post-install helper to guide the user through all this post install stuff, such as explaining and enabling plugins that shipped disabled.
I'm still on the fence about this though. I'm not sure if you remember it, but when Joomla added tags to the core, most tags extensions just went puff. So care must be taken when adding to the core things that are covered by other extensions. Bringing new users with easier tools have the same weight as having a good and trusted/trusting extension developer base.
I'll ask for input from other people in production. Michael already stated a maybe, with the same reservations I have.
I don't know the expression "over the fence". Searching it, the meaning seems to be something different than what you intend.
I don't know anything about the etiquette when it comes to interfacing with third-party extension developers.
I mean "on the fence", sorry. Undecided, not leaning one way or another.
That makes more sense.
I can see that this is a controversial suggestion.
Thanks. I'm tagging this on hold until we get input from other in production.
I also started using the plugin 'Perfect Open Graph Tags' a while back. It seems to be working fine. When you take a look at all the option you can select in this plugin I wonder if this will be simple to implement. If we do I think it needs to be a plugin that can be configured by the user to fit their needs. And published by default.
Just wondering: Is this a topic for this UX team?
And who decides (in general) what features are added to the core and what features you need to use external plugins for? I was under the impression that Joomla is trying to cut down on default extensions (banners, contacts, etc.) Bu maybe og tags are a 'basic' need. I do think they are ;-)
At present Social Media uses the first image from a page to display in article previews. This isn't always appropriate. I use a CSS workaround to control which image is displayed when an article is shared.
Perhaps there is a way to add this level of control in Joomla's backend.