In general moving documents isn’t going to break anything, so long as you update your File Base URL setting (if you use it) or your shortcodes to point to the right location. If the standard viewer works then I expect you’ve done this already.
Can you link to an example? Otherwise be sure to clear your browser cache as that’s the source of most issues like this.
Kevin
Here is the problem : When I attach documents uploaded on my domain alexse.com the standard and enhanced viewer work great, but when I attach a document uploaded on a different domain than mine like example.com or even on my sub-domain upload.alexse.com the standard viewer works fine but the enhanced viewer shows a 404 error inside the viewer itself.
enhanced viewer with document on my domain:
http://alexse.com/ssp-electro-3-4/2013/07/29/demo/
enhanced viewer with document on my sub-domain:
http://alexse.com/ssp-electro-3-4/2013/08/15/demo-2/
I have to admit I’m initially stumped on this one. I’ve reproduced the behavior on one of my own subdomains, so it’s presumably nothing you’re doing wrong. The behavior is very strange. I can’t think of a reason why a page that loads plainly will give a 404 based on the contents of its query string.
I’m going to have to dig into this one a bit more and get back to you. Just wanted to confirm I’ve received your messages and I’m looking into it. Thanks for your patience.
Thanks for your response. Any new updates ?
can you help me with a quick fix: is there a way to hide the full-screen button in the standard viewer manually without changing to the enhanced viewer ?
I’m still working on this problem, I’m sorry for the delay.
It’s not possible to make any changes to the viewer pane itself without using the Enhanced Viewer (only to its dimensions, and the download link properties). It is by definition the original code as Google provides.
Hello,
After more investigation into this issue with subdomains, it turns out my initial assumption was not correct – I am not able to reproduce this exact issue. I was seeing a different problem on my own subdomains.
I can in fact embed both of your source documents on my dev site without issue:
http://dev.davismetro.com/single/subdomain-test/
This doesn’t explain the behavior I’m seeing on your site, so I don’t mean to say that there is nothing to fix, only that since I can’t see the issue when I try to recreate it on my site using your documents it seems related to your particular server config.
One difference I see from my server to yours is that yours is sending a Content-Disposition: attachment response header, meaning a direct link to the PDF is prompting me to download it rather than attempting to view it in the browser (such as with the built in PDF viewers in Firefox and Chrome). I don’t think that’s the specific issue, since both your main domain and subdomain do the same thing, but there are definitely configuration differences that are altering PDF file behavior in general when called from my server vs. yours.
I’m willing to test this further but I might need admin access to your WordPress to do some debugging by editing the view.php file in your configuration. I’m not sure if you want to pursue that or not, but wanted to present the option.
The reason my server is sending a “Content-Disposition: attachment” is because I added this
<FilesMatch "\.(mov|mp3|jpg|pdf)$">
ForceType application/octet-stream
Header set Content-Disposition attachment
</FilesMatch>
to my hataccess file.
Another question: if I host my PDF files on a sub-domain will this make GDE load them faster or it wont have any effect ?
I had similar issues which always occurred only then when my browser was logged-in at a Google account simultaneously (e.g. Google Plus or YouTube).
But by todays plugin update to ‘Google Doc Embedder’ version 2.5.8 this error seems to be eliminated. For me it works fine at my site http://katja.at/verantwortung/muetter
Loading a document from one domain or another will be about the same speed, especially if they are on the same network/server.
You might try starting with a minimal (or no) htaccess file to see if there’s something else in there that’s defeating the GDE embedding on the subdomain.
