technabob

Just confirmed that your plugin is now outputting absolute paths WITHOUT any code changes. Sorry to send you on a wild goosechase here.

I just figured out why I had that function in place. It was my mistake to attach it to the wp_get_attachement_url function when I only needed it in one very specific place. I’ve now moved it to the location where needed, and I think the problem is resolved.

I’m still not sure why the image paths are stored as relative in the DB on this site, but wp_get_attachment_url is now returning absolute paths.

Well, I just found the culprit! I had the following in my functions.php…

function relativePaths($url, $ID) {
        return '/'.implode('/',array_splice(explode('/', $url), 3));
}
add_filter('wp_get_attachment_url', 'relativePaths', 10, 2);

Commenting this out fixes the problem, regardless of how the paths are stored in the DB.

That said, I now need to figure out why the heck I had that in my functions.php in the first place.

As far as I know, there are no plugins running on this particular site that affect image uploads. The only one I’m running allows the thumbnail to be upscaled if the source image is smaller than the thumbnail itself, and I’m running that on all four of my sites. The only material difference between the upload process on my sites is that the upload directories are different.

Out of curiosity, I ran the first query on two of my sites, and here were the results:

theawesomer.com:
/photos/2010/03/032510_splatterhouse_x.jpg
/photos/2010/03/032510_splatterhouse_t.jpg
/photos/2010/03/032510_splatterhouse_4.jpg
/photos/2010/03/032510_splatterhouse_3.jpg
/photos/2010/03/032510_splatterhouse_2.jpg
/photos/2010/03/032510_splatterhouse_1.jpg
/photos/2010/03/032510_wififan_1.jpg
/photos/2010/03/032510_wififan_x.jpg
/photos/2010/03/032510_wififan_t.jpg
/photos/2010/03/032610_bbote_3.jpg

95octane.com:
https://95octane.com/wp-content/uploads/2013/09/ferrari_458_in_brushed_gold_t.jpg
https://95octane.com/wp-content/uploads/2013/09/volvo_concept_coupe_l.jpg
https://95octane.com/wp-content/uploads/2013/09/volvo_concept_coupe_t.jpg
https://95octane.com/wp-content/uploads/2013/09/volvo_concept_coupe_2.jpg
https://95octane.com/wp-content/uploads/2013/09/volvo_concept_coupe_1.jpg
https://95octane.com/wp-content/uploads/2013/09/volvo_concept_coupe_6.jpg
https://95octane.com/wp-content/uploads/2013/09/volvo_concept_coupe_3.jpg
https://95octane.com/wp-content/uploads/2013/09/volvo_concept_coupe_4.jpg
https://95octane.com/wp-content/uploads/2013/09/volvo_concept_coupe_5.jpg
https://95octane.com/wp-content/uploads/2013/09/volvo_concept_coupe_8.jpg

So it’s clear that The Awesomer is storing uploads with relative paths for some reason. I’ll keep digging to see if I can find anything that could be causing this.

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

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’);

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).

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.

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.

Happy to be of service. The og:video code for the custom field is working swimmingly, so thanks!

Yes. That’s resolved. I did notice one other – somewhat related issue with the og:video tags that are injected from the_content. If you have a link to Vimeo that ISN’T a video embed – i.e. to the video author’s page like: https://vimeo.com/stevenbenedict, we’re getting an extra og:video tag that just links to : https://player.vimeo.com/video/

I’m assuming this is a bug in the WP oembed mechanism, but I figured I’d mention it in case it’s something specific to your plugin.

Oops. My bad. I didn’t realize you released a plug-in update. I was still running 2.6.8. It’s working now. Thanks!

Odd. I tried removing everything else in my functions.php to ensure there was no conflict with other filters and I’m still getting no og:video tag.

I wonder if there’s something I’ve got configured differently in my Add-Meta-Tags plugin settings. Otherwise, I’m assuming its some other plugin conflict.

So far, I can’t seem to get it to output anything. I’m currently sticking the video embed code in a custom field called “video” but I usually have the link in a field called “link”. I tried both of these data sources, and neither resulted in any og:video metadata being output.

Here’ are some examples you can use if you want to check on your end:

video custom field: <iframe width="960" height="540" src="https://www.youtube.com/embed/u76DYViVQto" frameborder="0" allowfullscreen></iframe>

link custom field: https://www.youtube.com/watch?v=u76DYViVQto

Any thoughts?

George:

Looks like this problem is still occurring if an IMG tag is partially opened within the portion of the post that is extracted for the description. At least that’s what I think is happening here…

https://technabob.com/blog/2015/02/27/review-dell-xps-13-uhd-2015-model/