Martin Bailey

Hiqtwrk,

It didn’t fail when you checked, because I’d run the search and replace, and the post was still using https://martinbaileyphotography.com/ without the cdn subdomain.

However, I just came to share my latest post on my social networks, because it wasn’t working yesterday, and once again, I found everything broken, so I did the regex search/replace again, and found 24 posts had already been updated in the database, to use the https://cdn.martinbaileyphotography.com/ URL for the featured image.

Something is gradually working through posts in the background and changing this, but I don’t have a clue what. All I know is that this started when I switched to from Apache/Nginx to the LiteSpeed Web server, and started using you LiteSpeed Cache plugin for the CDN settings. I’d been using WP-Rocket until that point.

I can’t say for sure that it’s your plugin that is at fault, but it would be a big coincidence timing-wise if it wasn’t.

My concern is that it’s not only me that is sharing my posts on the social networks, and pretty much all other shares will also be without the Featured Image and that looks really bad from a marketing perspective.

Regards,
Martin.

So, I just released this week’s Podcast and unfortunately it seems that the code I updated to last week was not effective in fixing this issue.

The Facebook Developers page is still giving me the Image Unavailable error: Provided og:image, https://cdn.martinbaileyphotography.com/wp-content/uploads/2019/08/Cover_Shot.jpg could not be downloaded. This can happen due to several different reasons such as your server using unsupported content-encoding. The crawler accepts deflate and gzip content encodings.

Using a plugin called Search Regex, I searched for https://cdn.martinbaileyphotography.com/ and did not find it in any of my post entries, but like last week, the Post Meta Value table has around 30 posts with featured images, including this week’s post’s featured image, that were all linked using the https://cdn.martinbaileyphotography.com/ URL. I did a search and replace on these last week too, so it would seem that these are being overwritten by something.

I just executed the search and replace, so that it actually made the changes in the Post Meta Value table, and the facebook error went away again.

Is the cdn URL supposed to be saved in the Post Meta Value table?

Regards,
Martin.

OK, so I tried disabling the CDN again, but it did not work. I’m not sure why it worked last week, but it no longer affects the Facebook OG:Image.

So, I did another regex search and replace but this time on the Post Meta Data, and found another few URLs that were in the database with the cdn subdomain, so I got rid of all of those as well.

Now Facebook recognizes the Featured Image via the OG:Image metadata, and all seems fine.

The final test will be next week when I release another post. If the fix that I applied after releasing yesterday’s post is valid, this issue will be resolved.

I’ll keep you posted. Thanks for your help and patience.

Regards,
Martin.

Sorry for the delayed reply. I didn’t see a notification of your reply, and was reminded of this issue when I released this week’s post and had the same issue over on Facebook. ??

I just followed your instructions and updated to that commit without issues, but my post was already created and published by this time. I did a regex search and replace to get rid of the cdn.martinbaileyphotography.com urls from my post, and cleared the cache, but the Facebook issue is still occurring, as you can see here:

https://developers.facebook.com/tools/debug/sharing/?q=https%3A%2F%2Fmbp.ac%2F671

I’m not sure if this is because I upgraded after creating the post or not. But the OG:image is still coming from the cdn, and I don’t really know what to try next.

Thanks for letting me know Stanley, but I cannot find an option to upgrade.

I do see at the top of the page that I’m still at v2.9.8.4, so it has not been automatically upgraded.

Can you tell me what I’m looking for? There is nothing that says upgrade etc. on the LiteSpeed Cache > Debug page.

Regards,
Martin.

Are you using the Gutenberg editor, adding an Image block or drop the image into the post/page editor, then select the Media File under the Link To pulldown, as in my screenshot?

https://www.dropbox.com/s/nuxp4q0zbfqbfzl/Image_Links.jpg?dl=0

I tried adding action=edit to the URI Exclude field as you suggested, but nothing changes. When I select Media File to link to, the image URL incorrectly contains the cdn subdomain and this is stored in the post body in the database.

Note that I actually select to link to the Media File when I embed images, as over the years some Lightbox plugins have not displayed images if you don’t do this. It’s just a regular WordPress option though. Nothing special.

I was just inserting images using the regular WordPress Media Library, but they are being linked to the cdn subdomain.

Because I already saved the the last few posts with the CDN turned off, I can’t check again, but I have a test page that I just embedded an image into, and then checked my database directly, and found that the image is indeed embedded using the cdn subdomain in the URL. Here is the code from my database:

<!-- wp:paragraph -->
<p>This is a test image in a test post.</p>
<!-- /wp:paragraph -->

<!-- wp:image {"id":302083,"linkDestination":"media"} -->
<figure class="wp-block-image"><a href="https://cdn.martinbaileyphotography.com/wp-content/uploads/2019/07/MBP_Namibia_20190616_MR12152.jpg"><img src="https://martinbaileyphotography.com/wp-content/uploads/2019/07/MBP_Namibia_20190616_MR12152-1440x960.jpg" alt="Sleeping Lion" class="wp-image-302083"/></a><figcaption>A lion sleeping peacefully in the Etosha National Park, Namibia</figcaption></figure>
<!-- /wp:image -->

<!-- wp:tadv/classic-paragraph /-->

This surely shouldn’t be how this works? What happens whenever I turn off or stop using the CDN?

Regards,
Martin.

Sorry about the 404 error. I got the error message from my clipboard history, and the link was before I reuploaded the image earlier. Forget about the 404 error. That was not happening when I had the issue earlier. My bad.

But, the error message is what I was seeing, and is a real issue that won’t go away without your help.

Aah, I actually opened the post while the CDN was off and saved it, so it seems that the issue is no longer occurring, but it will happen again when I create and release next week’s post.

The error I was seeing was this, for this week’s post, so a different image, but the same issue:
Provided og:image, https://cdn.martinbaileyphotography.com/wp-content/uploads/2019/05/Marc_Silver_Interview_Featured.jpg could not be downloaded. This can happen due to several different reasons such as your server using unsupported content-encoding. The crawler accepts deflate and gzip content encodings.

I initially tried changing my headers to gzip, deflate etc. but nothing worked. The only way I could get around the issue was to turn off the CDN. Thinking about it, I also went into my posts and reselect the images, then saved the posts, so that they did not have the cdn subdomain in the image URLs.

If you can tell me, if it is normal for images to be embedded using the cdn URL or not, that would initially be a big help. Here is a screenshot of the media link of an image in one of my recent posts: https://www.dropbox.com/s/nuxp4q0zbfqbfzl/Image_Links.jpg?dl=0

Should this be happening?

Yes, but as I explained, I believe the problem may be caused by the deep linking in my WordPress posts. I’d really like help/advice on both sides of this if possible.

I was adding the header by the CDN, as that was the only way I could get it to work before using LiteSpeed, but on your advice, I just removed it from the StackPath settings, and put it back into my .htaccess but using my domain, not “*”, which is how I would prefer it to be set up.

I then also went back and saved the settings on your plugin’s CDN page, and although the block above is back, along-side my own header adding my domain, at this point, it seems to be working fine!

I’ve flushed my caches etc. so it seems that this was the key, so thank you!

I’ll keep my eye on this, but now I’m wishing I mentioned this three days ago when I started struggling with this issue. Thanks again!

Also note that ideally I’d prefer to add my own website address instead of * as the wildcard is the worst option security-wise, but if I add my domain the error still occurs because with your added block I still have two entries and Chrome doesn’t allow that.

Ideally, I agree, but none of the other plugins are adding this to .htaccess, neither are they adding it only for fonts. If I remove it from the other settings, I lose that header for all other file types, and that is not acceptable.

Yes it is removed, as it causes errors on my site. I just need to stop it from being readded when I save the CDN settings in your plugin.