Struggling with an issue around LinkedIn downsizing images posted via their API. Hoping someone has some resources that might be able to assist?
When posting via LinkedIn's reach media share, as described here:
https://www.linkedin.com/help/linkedin/suggested/70781/image-specifications-for-your-linkedin-pages-and-career-pages?lang=en
https://learn.microsoft.com/en-us/linkedin/marketing/integrations/community-management/shares/rich-media-shares
It seems their API only supports a "1.91:1 ratio" (1200 x 627)
What's ironic about this is 1.91:1 looks terrible in the application.
So after some experimentation (forgive the bright green background, I was testing whether white padding was being added) I discovered that LinkedIn's native posting of images is actually a 1.5375:1 ratio when done within the application, which lo and behold... actually looks good within the application. Example:
So then naturally I try to post 1.5375 via the API and get these hideous gray bars on both sides:
Further, the API adds a crop factor to the overall height that is just simply not present when an image is added in the application natively. This example is a side-by-side of the exact same image... (left = posted via API) (right = posted natively on LinkedIn)
You can see how much better the native image looks.
Does anyone have any suggestions on how to resolve this issue?
Many thanks!!
Related
I'm working in a project of building a responsive website. The painful thing we're having is to deal with the content of the image in different display modes. Please be noted: the image content.
The thing is: in almost pages at PC view, the images are displayed in landscape, with great ratio between width and height. Now when bringing them to mobile view, we have to display it in a different frame. And as you might imagine, now the content of the image was scaled and cropped and then exported to some very weird images on mobile view. Like a wide picture with people are almost in left side, but after being cropped there are only non-sense objects in the picture left.
IMHO, via technical solutions we are only processing the technical attributes of the image (resizing, scaling), we are unable to deal with the image content, that's really a human matter, right?
I'm thinking about 4 solutions:
1 - Despite the customer feelings, we just scale the picture (keep
all content, just resizing it). The output sometimes will be very
ridiculous I guess because of resizing a landscape picture to a
portrait or square one. But that's mostly the easiest way to come up.
2 - Considering to image frame size on mobile view, and auto crop the
picture by picking the center area of the picture. As I said above,
it produced the non-sense picture after all.
3 - Informing customer, whenever they upload a picture, they have to upload 2 copies of it, 1 for desktop view and 1 for mobile view, and they're definitely responsible for the content displaying at front side. Tons of effort need to be spent by customers, but easier for development.
4 - Advanced feature: user can upload only 1 picture, we provide the
different view-ports and a cropper for them to decide how the image
displays on those after being cropped.
I don't have much experience in dealing with these stuff, and not sure how the world out there handling this case. As I see for now Wordpress is only requiring users to upload only 1 picture and it will automatically scale it (my 1st option). Does anyone have experience on this? Can you please share me your solutions and also your thoughts about my above solutions? Thank you.
you can build a simple web application for them to upload the picture and provide your client with a preview of how the pictures with look like for both desktop and mobile. in php, there is the GD library and it is quite easy to use for cropping and resizing.
Apply the 4th and the 1st option so you don't have to deal with it,
Crop and scale with the options you have AND let the customer decide if they want to change it and choose how the image is been displayed.
in case they ask you can say they have the option to fix it, in case they don't want to you already handle the best technological option.
I made a post on WordPress, then shared it on a Facebook page. In the past, the shared image would be the large "post" image. But now, for some reason, it's using the thumbnail. Running the url through fb's debugger shows that Open Graph recognizes both og:images, but that neither of them are being used in the share preview. Once posted, it uses the thumbnail.
I checked the meta content in the page head just to double check and sure enough, it looks fine:
<meta property="og:image" content="##">
What's causing this? It's recognized, but not used. What?
I currently facing the same issue, after contacting facebook, it turns out there is an issue in Open Graph in facebook that affects some users.
The Bug has been reported and assigned as "high priority" in Facebook support center - https://developers.facebook.com/bugs/978421888869140/
Be sure to have a look at
https://developers.facebook.com/docs/sharing/best-practices#images
You need at least images of 1200x630 pixels size to be able to get a large preview image.
Furthermore, you should put the larger image first IMHO.
See
https://developers.facebook.com/docs/sharing/webmasters/optimizing#cachingimages
https://developers.facebook.com/docs/sharing/webmasters#images
I know this is probably not the best SO question ever because I don't have the relevant code (I don't know where it is and I can't find it). If anybody has seen this problem before or knows what is causing this I can't tell you how much I would appreciate it.
I have a storefront and the images in the storefront are showing up rotated 90 degrees to the left for no apparent reason.
The actual source files of the images are normal, if you look at the actual .jpg used in on the site they are upright.
How or why would they be showing up rotated? Is this some setting or a bug in WooCommerce?
Note
Yes, I've disabled every addon and used only WordPress and WooCommerce and the result is the same. Different themes yield the same result as well.
I discovered the problem in case anybody stumbles across this later down the road. The issue is with Apple's exif data and rotation information they store within each image. It is apparently not compatible with most computers and when you upload a picture from a mobile device from Apple (ipad, iphone etc.) you are likely to experience this phenomenon.
There is little than can be done about it, shy of uploading the images to a computer and manually fixing the orientation of all rotated images before using them.
I Tried to find the answers here on stackoverflow but couldent find it , so I hope someone can help me.
The question is pretty simple I guess, Im trying to optimize My site with a image sprite instead of many images.
And I wanted to know if a background:inherit counts as HTTP Request?
Was thinking otherwise I could let My DIVs just inherit the first DIVs background image and save me a lot of Requests.
And do Two img links too the same image sprite count as one or Two HTTP Request? I mean do the browser understand that it already download it?
Assuming that you cache images, two (or a thousand) image links will only issue one HTTP Request, as long as the image itself doesn't change, though it's really about the browser implementation. The same goes about using inheritance or even using the same resource in different CSS elements. If you are using Chrome, I'd suggest that you'll take a look at the network tab in the Developer tools and verify that this is indeed the case. Otherwise, you can try using Fiddler.
If you'll share a link, I'd be more than happy to take a look at it myself.
I'm using a Google maps iframe to display the location of my customer on his webpage. Works fine, but when viewed on Ipad the Google server apparently sends a different version of the maps. It looks like this:
Now, that wouldn't be a problem, but the two buttons on the bottom (i marked them in red), which I'm assuming are supposed to allow routing or something, don't do anything when being clicked?!
Has anyone an idea what my problem here might be? And how I either get those buttons to work (preferred solution) or else get them to disappear?
You can get rid of them by reducing size (height) of your iFrame and adding overflow:hidden style.
They don't work for me either. I seen this bug. But it's not the first time Google screws something on mobile devices (Google News for example somehow thinks my PC is a Tablet), so I wouldn't worry about that too much. Eventually hopefully they'll figure it out.