Auto-post to FB always using default (fall-back image) not post images

We recently upgraded to 1.4 of the Ultimate FB plugin. Since then, when auto-posting to FB our sites no longer send the images in the blog posts themselves for the update on the FB wall - they only send the default (fallback) images configured in the settings. Did something break here? Thanks!

  • Vladislav

    Hi,

    I have just tested this again to make sure something didn't get broken, but it appears to be working for me just fine. To better understand where the issue may be, let me try to explain how the image searching process works:

    - First, we check if any image has been set in "Facebook OpenGraph" > "Always use this image". If it is, we're using that and don't bother to look further.
    - Next, we're looking for the featured image. If we have that, that's what we'll use.
    - Next, we check the actual post body for any images.
    - If all of this fails and we couldn't find an image, we'll use what's set in "Facebook OpenGraph" > "Fallback image"

    Have you perhaps set "Always use this image"? Also, all images have to be publicly accessible on the web, or Facebook won't be able to find them. Another point is that images should be specified with their absolute URLs (starting with http://...). Lastly, images have to already be added to your post (or set as featured) when you first publish it. Are all these conditions met? Do you have anything recorded in your Error log pages? I'm sorry if I'm asking obvious questions, but I'd like to replicate this behavior so I can see what's going wrong and where.

  • ClvrTv

    I just wanted to add some additional value to this conversation for others who might come across it, since we are still seeing mixed results with FB pulling the default / fall-back image from Ultimate Facebook plugin settings versus the image we'd want to come through directly from the post.

    I think I have this nailed as to why. It would be super awesome if there's anything you can do in the plugin to work-around this, but if not I totally understand. It's probably something that should rather be factored into theme dev, but having it in the Ultimate FB plugin would be huge because I don't think most will every think of factoring this into theme dev or understand what is happening and why.

    So - issue: inconsistent results in FB pulling an image from the post vs. the default image configured in the Ultimate Facebook plugin even when ALL the conditions above are met.

    Reason: using the WP add image / media library to add an image to a post generates a WP specific URL for that image like:
    (A) - http://inkmonstr.clvr.tv/files/2011/11/custom-pingpong-table.jpg

    However, that image actually lives somewhere different on the server like:
    (B) - http://inkmonstr.clvr.tv/wp-content/blogs.dir/330/files/2011/11/custom-pingpong-table.jpg

    To WP both A and B are synonymous and it finds the image just fine. To 3rd party tools like timthumb or Facebook: format A is not valid because it requires WP rewrites in order to resolve and that's 1 hop too many for programmatic or GET operations that need to do something with the file itself. They will only work with the image url format found in B.

    When FB goes to a post url, it doesn't find any resolvable images in the post (even when they are present in format A) and therefore falls back on the default image configured in the plugin that is populating the og:image meta..... Hmmmmm! or actually - now I am wondering how Ultimate FB plugin decides to populate the og:image tag - maybe this is something that Ultimate FB should in fact be taking into a account before it falls back on the configured image. When Ultimate FB checks the post content can it also resolve format A and pass to og:image?.... As if that wasn't already complicated enough :slight_smile: it's probably only examining the content field too right? We use a lot of custom fields like "thumb" and "Top Image" and different things. Do those overlap with the "Featured Image" built into WP and can Ultimate FB consider those URLs too? It would be awesome to be able to have an additional option in the image setup where we could tell Ultimate FB to also check for a specific custom field to check for an image to send to og:image. And that one (in my mind) would be the first place (top priority) where it would check as to what to put in og:image. Now that would be SWEET. (And it would also need to factor in / translate url format A to B and format B would have to go in og:image. Ok, I digress.

    I had to work around this exact same issue with timthumb too and dynamically translate /files/ to /wp-content/blogs.dir/###/files/ for any images passed to that.

    The implications of the issue can be seen by comparing the following two URLs in FB status to see what images they pull:
    http://inkmonstr.com/burton-heat-transfers/ [doesn't "work" - pulls fallback image]
    http://inkmonstr.com/ping-pong-table-wraps/ [works - pulls image from post]

    The reason the 2nd one works is that the post also has an NextGen Gallery embedded in it and NGG uses the B format URL for it's images and therefore FB can pull that.

    Anyway, hope this helps someone else. Some times this crazy WP quirks can be pretty frustrating in this complex ecosystem. Only marking this as Open again to reflag for some love on the issue. Feel free to mark resolved and/or move to a Feature Request once you've had a chance to review.

    You guys are great! All the best!

  • Vladislav

    Hi,

    First off, thank you very much for such a detailed description of the issue and the underlying mechanics of it! Now, the strange part - I haven't been able to get any of my installs to insert images with such paths. Do you perhaps have a plugin (or a custom settings/rewriting scheme) to make that happen? Whatever it is, you're definitely right, that's one redirect too many for Facebook (and I guess timthumb too) to follow.

    As for the solution, I'm thinking on how we can solve this issue for you, without making it too specific and potentially hurting other users. The first thing that comes to mind is adding a filter which would be applied to image URL before passing it on. You could then hook up to it and apply your existing image paths remapping function (the one you already have for timthumb). Do you think this could work for you?

  • ClvrTv

    Wow, thanks VeBailovity - super helpful. A filter would be perfect and much appreciated, but maybe there's a bigger issue that I missed and I should really rather be looking at why those paths are coming out that way? This is an installation that has been updated all along the way from WPMU 2.9.2. Could it be related to that? Were there some old rewrites necessary in earlier versions that I just never knew I could clean out of .htaccess?

    Would WP-SuperCache or Domain Mapping be related at all?

    I did find this in my .htaccess:

    # uploaded files
    RewriteRule ^(.*/)?files/$ index.php [L]
    RewriteCond %{REQUEST_URI} !.*wp-content/plugins.*
    RewriteRule ^(.*/)?files/(.*) wp-includes/ms-files.php?file=$2 [L]

    But do not remember adding that manually and have no idea what (if anything) would break if I take it out. And would that even account for what we're seeing. Otherwise, not sure if/what other plugins might be the culprit.

    So the safest thing would be a filter option from you guys. But I don't want to cause you extra work if it is just my configuration. Nor do I want to redo with a filter something that is getting undone unnecessarily, when I could just remove what is undoing the way it should be :slight_smile:

    Follow? :slight_smile:

    Any additional insight / advice much appreciated!

  • Vladislav

    Hi,

    In my opinion, we can't have too many filters in the plugin :slight_smile: With a setup as complex as yours, taking the easy way out and just filtering out the image URLs would be the fastest and also, as you said, probably the safest way. The latest plugin release (v1.5.1, just released) comes with a number of filters you can hook up to in order to change the OpenGraph image. They're named after the image source:

    wdfb-opengraph-image-always_used_image: Image that is always used (from OpenGraph settings)
    wdfb-opengraph-image-fallback_image: Fallback image (from OpenGraph settings)
    wdfb-opengraph-image-featured_image: Featured image (extracted from your post)
    wdfb-opengraph-image-post_image: Extracted from post (extracted from your post)

    Additionally, there is one generic filter applied to all images after the source-specific filter has been applied:

    wdfb-opengraph-image: Generic (applied to all)

    All of these filters accept one string argument, which is the image URL, and they should return a single string (also an URL). In your situation, you may want to hook up the same function to wdfb-opengraph-image-featured_image and wdfb-opengraph-image-post_image - or, alternatively, just hook up to wdfb-opengraph-image.

  • ClvrTv

    Stared at this for a while and realized.... this only helps if one of the URLs is already picked up by the plugin automatically for processing by it's logic / filters. But now I'm running into the situation where I need to inject a URL into og:image that the plugin doesn't find in the_content (because it's not in the_content, but in a custom field for instance). Can I use a filter for this? Maybe I'm missing something obvious, but how can I use a filter to inject an image URL that the plugin would not otherwise find? Thanks!

  • Vladislav

    Hi,

    If the plugin doesn't find an image in your post, it will return what you have set as fallback image, always applying the wdfb-opengraph-image-fallback_image filter to it. Perhaps you can use this behavior to your advantage, by hooking up to this filter and checking any additional custom fields for your post and/or other image sources. You can then return the image URL you found from your function or, if your search comes up empty, just return the argument passed to it (which will be the fallback image). Does that sound like something you can use for your scenario?

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.