failed to fetch error

Thank you for posting – if they haven’t already, the support team will respond after the Christmas break.

We will probably not be notified of replies to this thread here, so please do continue to email [email protected] for further queries!

Regards,

Dan

@dalecameronlowry, I see this issue was resolved. I too am now having this issue.

Are you able to provide the solution?

For others coming here for the solution, it’s actually detailed in the PDF Embedder plugin knowledgebase here:

https://wp-pdf.com/kb/

You will usually see this error in your browser because your PDF does not sit on the same domain as the current page on your site.

For example, if you access the page https://www.mycompany.com/ and see the error message:
Failed to Fetch while retrieving PDF “https://mycompany.com/wp-content/uploads/mydoc.pdf”
this is because the shortcode for the embedded document references the URL on mycompany.com whereas the page is sitting on https://www.mycompany.com.

The “www” is important – it references a different domain to the PDF’s URL that does not contain “www”.

For security reasons, browsers are not allowed to load the PDF from a different domain. This error will also occur if you try to embed a PDF from another 3rd party site.

You will need to ensure all your [pdf-embedder] shortcodes refer to the PDF’s URL in the new preferred manner.

Sometimes, the problem might be that WordPress is configured to upload PDFs to media.mycompany.com, or something similar, perhaps due to a content-delivery plugin that is attempting to speed up your site. It may still be possible to load PDFs hosted on a different domain, at least if you have the ability to set up the configuration of that domain – see Hosting PDFs on other services such as Amazon S3.

It is also possible that a PDF URL is being prevented from loading by a browser Ad Blocker. In the browser console, this shows up as an error net::ERR_BLOCKED_BY_CLIENT. To fix this, be sure that the PDF file name does not contain any words such as advertisement, advert, ad, click, doubleclick which are trigger words for Ad Blockers.

I’m getting this error as well.

The one website is known by 4 domains; NNN.ca, NNN.com, NNN.co and NNN.org. I can’t create 4 different websites because this plugin can’t load from a base URL that is different from the one used when the PDF embed shortcode was created from. It’s the SAME site, just a different base URL.

Can this be fixed ASAP please? Or at least made an optional toggle and we decide if it can load from a different domain?

Simple suggested fix: Have the plugin check the shortcode passed and see if the URL starts with “https://” or “https://”. If it doesn’t, then PREPEND the site URL used to the start of the shortcode URL. Problem solved. It no longer matters what the site is called, it’s still a local file that will be loaded.

Side note: I’m curious as to the “Exact” security reasons in the statement: “For security reasons, browsers are not allowed to load the PDF from a different domain. This error will also occur if you try to embed a PDF from another 3rd party site.”

• This reply was modified 6 years, 6 months ago by trevpaq.
• This reply was modified 6 years, 6 months ago by trevpaq.
• This reply was modified 6 years, 6 months ago by trevpaq.
• This reply was modified 6 years, 6 months ago by trevpaq.
• This reply was modified 6 years, 6 months ago by trevpaq.
• This reply was modified 6 years, 6 months ago by trevpaq.

Hi trevpaq,

The security reason is the Same-origin policy that is a cornerstone of the web application security model that has been implemented in all web browsers since 1995 as a means to prevent malicious content from being passed from one domain to another.

According to the Same-origin policy, NNN.ca is not the same as NNN.com is not the same as NNN.co is not the same as NNN.org. These are all different domains even if they are pointed at the same physical server location, as such the data can not be sent without permission. It isn’t feasible for the plugin to have a setting to retrieve data from another domain as the Same-origin policy requires that the permission be set on the origin the content is stored, and not the origin of the request. For this reason, many sites use CDNs such as Amazon S3 which facilitates cross-origin requests through CORS configurations.

For more information, please drop us an email at [email protected] and we’ll be happy to assist further.

Emma

What about the simple fix suggested? This ENFORCES the same-origin to a tee. This guarantees that the file is LOCAL and not on another site, yet gives the flexibility to use use differing URLS.

To re-iterate:
Simple suggested fix: Have the plugin check the shortcode passed and see if the URL starts with “https://” or “https://”. If it doesn’t, then PREPEND the site URL used to the start of the shortcode URL. Problem solved. It no longer matters what the site is called, it’s still a local file that will be loaded.

Hi trevpaq,

Thank you for the suggested fix. I will forward that information to the developers for further testing and consideration.

Emma

No need to fix this. I just tested.

By changing the shortcode used from:

[pdf-embedder url=”https://domain.com/wp-content/uploads/2018/03/filename.pdf”%5D

to

[pdf-embedder url=”/wp-content/uploads/2018/03/filename.pdf”]

Aka: strip out the leading “https://domain.com”.. it no longer matters what the site is known by. The file loads and is displayed.

Can someone else please also test to confirm my findings?

If this works, perhaps update the docs to note this functionality.