relative paths to og:image..

Hello,

Yes, the plugin generates metadata only for the images that are attached or embedded (only flickr is currently supported) to the post. The post is not scanned for other images that have been manually inserted into the content.

What puzzles me is why the URLs are relative. Normally, this should not be happening. The plugin uses the WP API (wp_get_attachment_image_src()) to retrieve the image URL and uses the url without any further processing. So, I assume that somehow the URL has already been stored in the database as a relative path, but I’m not really sure.

What can be done is to pass the retrieved image URL through site_url() so as to transform it to an absolute path.

I’ll do some more research about this issue within the week and post back on this topic about it.

George

A quick test, if possible:

In file metadata/amt_opengraph.php in line 588, replace

$main_size_meta[0]

with:

wp_get_attachment_url($post_id)

… and check if anything changes?

On the other hand, WP may already store relative image URLs and then construct the full URL when wp_get_attachment_image_src() or wp_get_attachment_url() are used. Since these functions can be filtered, some custom code might not be letting them to return a full URL. I’m really out of ideas here… I’ll need to do some research about it within the week.

George

Just a quick note. My suggestion above about wp_get_attachment_url is wrong as this function does not take the image size into account.

I wonder if the problem has something to do with my images being stored outside of the conventional wp-uploads path. This was a decision made many years ago to put images under /photos, and unfortunately I don’t want to risk the SEO mplications of moving them to the default directory location.

I’ll dig through my plugins and functions.php as well to see if I can find anything else that could be messing with the paths as well.

Possibly this is the case. But, it definitely requires some thought before making any decisions or changes.

Can you check ig it can be resolved by replacing:

$main_size_meta[0]

with

site_url($main_size_meta[0])

site_url() should convert the current url to absolute.

I’ll test that in my dev environment in a little bit. I’ve had to temporarily disable the opengraph generation in my production environment, as I’ve discovered a rather nasty side effect of having it turned on for video posts at facebook. It turns out that no matter what other og: tags you have (images) Facebook ALWAYS prefers the video, and attempts to embed the actual video player in their timeline. This will not only kill click-through rates, but it appears that their YouTube embedded player is broken entirely. Oh joy.

I’m guessing that you might want to make the og:video feature an option you can uncheck if you don’t want it. I love how the other social network I’m working with wants the og:video tag and treats it properly, but Facebook doesn’t, and assumes the entire post is just a video. Ugh.

Just confirmed that the suggested change works, and it does make the path’s absolute.
site_url($main_size_meta[0])

Now I’ve just got to sort out this og:video mess between Facebook and Tapiture (the other site we’re trying to work with).

Thanks for letting me know about site_url().

Regarding the other issue, I’ve received another similar report, but it seems that this is an issue related to how Facebook uses the provided opengraph metadata and not to the Opengraph metadata itself. If I’m missing anything, please let me know and, if required, any issues will be fixed ASAP!

Also, I’m skeptical about making the generation of og:video meta tags an option, because I’m sure this issue will be resolved by Facebook sooner or later.

In the meantime, if you want to suppress og:video tags in opengraph metadata, you could filter the generated opengraph metadata by using the following code:

function customize_og_suppress_ogvideo( $metatags ) {
    $metatags_new = array();
    foreach ( $metatags as $metatag ) {
        if ( strpos($metatag, 'og:video') === false ) {
            $metatags_new[] = $metatag;
        }
    }
    return $metatags_new;
}
add_filter( 'amt_opengraph_metadata_head', 'customize_og_suppress_ogvideo', 10, 1 );

Please let me know if it does the trick.

Thanks in advance,
George

Also, out of curiosity, may I ask how are the images from the /photos/.. directory inserted in the posts?

George: Thanks for the replies. I agree that facebook needs to fix their og:video implementation, but for now I’ll try out the filter.

As for the site_url fix, is that something you’ll able to include in a release, or is it something I need to patch individually for my instance.

As for uploading the images to the /photos directory, we just use the standard wordpress media uploader, dragging-and-dropping images in while in the context of the post, to ensure they get attached.

The custom image path was originally set in the admin, but they removed this option in 3.5, so it’s now defined in wp-config.php:

define(‘UPLOADS’,’photos’);

I need to do some research about wp_get_attachment_image_src() giving a relative URL. Even with the custom UPLOADS directory, it should give an absolute URL. Nevertheless, I’ll provide a fix in the next release, but it might be delayed for a little while. In the meantime, please edit line 588 of amt_opengraph.php, if this is not a problem.

Thanks for your feedback.

George

Okay, that’s what I’ll do for now. Thanks for all your help.

I did some research. site_url(URL) is not safe to use if URL is already absolute. Please do not use the workaround on sites where wp_get_attachment_image_src() already outputs absolute URLs.

I’m still confused about why wp_get_attachment_image_src() returns relative paths in one of your sites. Do you use any plugins that could possibly interfere with image uploads in this particular site? Changing the uploads directory should not be a problem.

FYI, the following database queries display how the attachment links are stored in the database.

Images:

SELECT guid FROM wp_posts WHERE post_mime_type LIKE 'image%' LIMIT 10;

Audio:

SELECT guid FROM wp_posts WHERE post_mime_type LIKE 'audio%' LIMIT 10;

Video:

SELECT guid FROM wp_posts WHERE post_mime_type LIKE 'video%' LIMIT 10;

Not asking to run them. I’m just posting them for informational purposes.

I admit that I am surprised that WP stores absolute URLs int he database. So inefficient.

I also found many discussions about storing absolute or relative URLs, so I guess many web sites might be affected out there.

As I see it, the best way to resolve this issue is to create a wrapper function that checks if the returned attachment URL is relative or absolute and process it accordingly. I will need some time to make sure I have fixed all attachment URLs and that it will work as expected in all cases.

George