File name does not match viewer’s

This message shows up when the PDF is trying to load from a different domain. The PDF must reside on https://blueridgeeyemd.com/.

It looks like the media on your site is loading from https://secureservercdn.net/50.62.172.232/b34.5c9.myftpupload.com/ and not https://blueridgeeyemd.com/.

Technically they are the same server, so the question is why is the media showing a different URL?

I too am confused by this message.

Hmm, I just updated to WP 5.6, and I think it worked before that!!!!!

I have https://www.centuryhouseassociation.com/?page_id=8446

While editing the page, the Preview works fine, and so does View Page after I Update. But viewing the page in a separate I get the error message.

I installed the plugin, and used its WP block to embed a PDF from my WP’s media library. At no time did I make any choices or overrides to where things go.

I see that “both the viewer and PDF have to be on the same domain” but how are they not?

In “Edit as HTML” I see
<div class=”wp-block-pdfjsblock-pdfjs-embed pdfjs-wrapper”>[pdfjs-viewer viewer_width=0 viewer_height=800 url=https://www.centuryhouseassociation.com/wp-content/uploads/2020-12-Clarion-Web.pdf download=true print=true fullscreen=false fullscreen_target=false fullscreen_text=”View%20Fullscreen” zoom=auto search_term=”” ]</div>

The URL of the PDF is correct. How can I tell where the plugin is, and surely I don’t have to override the WP defaults on that???

Ugh. Further to that, the same file works in a test page at
https://www.trh.bc.ca/?page_id=656

That setup is also on WordPress 5.6, so that isn’t it.
But it is hosted on a different ISP.

Ugh.

Aha! Found the mismatch … now to see how/where to FIX it.

<iframe width=”100%” height=”800px” src=”https://www.centuryhouseassociation.com/wp-content/plugins/pdfjs-viewer-shortcode/pdfjs/web/viewer.php?file=https://www.centuryhouseassociation.com/wp-content/uploads/2020-12-Clarion-Web.pdf&dButton=true&pButton=true&oButton=false&sButton=true&v=1.5.4#zoom=auto&pagemode=none&#8221;

FORGET IT! A THOUSAND APOLOGIES!

Just found the offending code and it’s MY error.
I owe you a good rating and will now provide it.

Glad you figured it out. Sorry I didn’t respond sooner.

I got the same problem, but figured out that the shortcode created by your preconfigured block removes the “s” from “https://&#8221; in the url so that this creates the mismatch.

To see how I can debug this: Could you point me to where in the code the url is concatenated/created?

I’m getting the URL from WordPress. I do not in any way add or remove the s from https. What’s more than likely the issue is that your site is configured in a way that the main URL is different from the media URLs. Do you have a URL where I could take a peek?

Okay, thank you very much!

Your hint that you get the URL from WordPress was exactly what I needed. I saw that the base url is explicitely defined in the options menu on wp-admin/options-general.php and not, as I presumed, inferred by some environment variable or folder structure.

So, that’s where I still had the “http” (without s) and what caused the media manager to create its file urls with “http:”. And since my server implicitly redirects every http request to https, I hadn’t had any problems. Until now, when your plugin (very appropriately!) checks for consistency.

Thanks for the quick reply! I appreciate the hints you gave!