Title: 404 Errors Last modified: November 19, 2018 --- # 404 Errors * [selliott](https://wordpress.org/support/users/selliott/) * (@selliott) * [7 years, 6 months ago](https://wordpress.org/support/topic/404-errors-99/) * This plugin was working when I installed it, but now I’m getting a 404 error when I try to view the document. It seems the files are being saved to an “uploads” folder, but the URL is looking in a “downloads” folder. Also, it’s looking for some-file-name.pdf, but saving it as some random string like sdf78923jhsdf9234ksd9. pdf. Has something changed or is this a known or common issue? - This topic was modified 7 years, 6 months ago by [selliott](https://wordpress.org/support/users/selliott/). Viewing 6 replies - 1 through 6 (of 6 total) * [Neil James (lcyh78)](https://wordpress.org/support/users/lcyh78/) * (@lcyh78) * [7 years, 6 months ago](https://wordpress.org/support/topic/404-errors-99/#post-10910089) * You raise a pouple of points here. * Firstly about the stored file name. Yes, it always encoded the name and stores it like that. It goes to some lengths to hide that name from the front end. * That is, it is not an issue, it is a design feature. * Second, the “upload” and “download” directories. It doesn’t work like that. * There is the standard Media directory – normally …/wp-content/uploads. This is where documents are stored by default (with year and month sub-directories). * You can choose that your documents are stored elsewhere – and you define that in the Settings -> Media tab. And whether you want the year/month sub-directory structure. * Once you have set that then uploads and downloads are both to and from that new location. * I would think that the rationale for this is to NOT show the encoded name in the Media library view. (You use the Media library process to upload the file.) * If you have uploaded files into the Media library and then set the Document library to a different name then you will not be able to retrieve those existing files. Possibly all you need to do is move them – but I have never tried this. * Hope this helps, Neil * Thread Starter [selliott](https://wordpress.org/support/users/selliott/) * (@selliott) * [7 years, 6 months ago](https://wordpress.org/support/topic/404-errors-99/#post-10917206) * Upon further testing, I found that the plugin seems to have problems with .PDF files on an nginx server, but runs fine on apache. * Thread Starter [selliott](https://wordpress.org/support/users/selliott/) * (@selliott) * [7 years, 6 months ago](https://wordpress.org/support/topic/404-errors-99/#post-10917565) * If you add a forward slash at the end of the URL, it loads the file okay. * Also, I said it was working when I installed it, but it’s possible I just hadn’t tried a PDF. - This reply was modified 7 years, 6 months ago by [selliott](https://wordpress.org/support/users/selliott/). * Thread Starter [selliott](https://wordpress.org/support/users/selliott/) * (@selliott) * [7 years, 6 months ago](https://wordpress.org/support/topic/404-errors-99/#post-10922676) * I temporarily got this working by editing the following lines: * **class-wp-document-revisions-admin.php** – line 435 (added **. ‘/’** to the end) `$fn = $info['dirname'] . '/' . $info['filename'] . '.' . $fno['extension'].'/';` * **class-wp-document-revisions.php** – line 524 (added **. ‘/’** to the end) ` return $link . '/';` * It now adds forward slashes to the permalink, download link, and revision links, which causes it to download okay for some reason. However, I’ll have to re-edit this every time the plugin is updated, so if you have any suggestions for a more permanent fix, I’d appreciate it. * Thanks! - This reply was modified 7 years, 6 months ago by [selliott](https://wordpress.org/support/users/selliott/). * [Neil James (lcyh78)](https://wordpress.org/support/users/lcyh78/) * (@lcyh78) * [7 years, 6 months ago](https://wordpress.org/support/topic/404-errors-99/#post-10928042) * Thanks for this update. * I have a standard Apache + WordPress combination, rather than nginx. * Like you with Apache, I do not have the problem you describe. * If I have a document with permalink such as site/documents/2018/11/document.pdf and enter that URL into my browser, then I receive a 301 redirect to site/documents/ 2018/11/document.pdf/ which then displays the document. * This is identical to the treatment for, say, a page or a post if the trailing/ is not entered. * The code that does this is contained in wp-includes/canonical.php – and AFAICS is executed before it is determined that it is a document as it tries to standardise the format of the URL being presented. * Clearly having the trailing / will avoid the 301 processing. However the module redirect-canonical has a filter that may modify the redirect destination. * The plugin has a module redirect_canonical_filter that states: * “WordPress SEO rules properly dictate that all post requests should be 301 redirected with a trailing slash” * This is as observed. * The code would remove the trailing / for documents – except as noted above it is at the stage where it is just dealing with URLs; not posts. * The rationale given is “Because documents end with a phaux file extension, we don’t want that” * Thus it seems a deliberate design decision to not have a trailing / on the permalink; and there is standard code to deal with it. * Are you getting the 301 redirect in your browser under nginx? * Regards, Neil * Thread Starter [selliott](https://wordpress.org/support/users/selliott/) * (@selliott) * [7 years, 6 months ago](https://wordpress.org/support/topic/404-errors-99/#post-10930281) * I don’t get a 301 redirect at all with the .pdf extension for some reason. It displays a 404 not found error if the URL is _site/documents/2018/11/document. pdf_ and it remains at that URL. If I add the forward slash to the end manually, it works for the PDF’s. However, it 301 redirects fine for the other extensions I’ve tested…just seems to be a problem with PDF’s so far. So, site/documents/ 2018/11/textdocument.txt successfully redirects to site/documents/2018/11/textdocument. txt/ * Strangely, I found that if I changed the existing .pdf extension to .txt, it redirected to .txt/ and displayed the PDF, even though the extension was .txt/ instead of .pdf/ * It seems like nginx doesn’t like the way .pdf URL’s are being rewritten for some reason. Viewing 6 replies - 1 through 6 (of 6 total) The topic ‘404 Errors’ is closed to new replies. * ![](https://s.w.org/plugins/geopattern-icon/wp-document-revisions_6c6c6c.svg) * [WP Document Revisions](https://wordpress.org/plugins/wp-document-revisions/) * [Support Threads](https://wordpress.org/support/plugin/wp-document-revisions/) * [Active Topics](https://wordpress.org/support/plugin/wp-document-revisions/active/) * [Unresolved Topics](https://wordpress.org/support/plugin/wp-document-revisions/unresolved/) * [Reviews](https://wordpress.org/support/plugin/wp-document-revisions/reviews/) * 6 replies * 2 participants * Last reply from: [selliott](https://wordpress.org/support/users/selliott/) * Last activity: [7 years, 6 months ago](https://wordpress.org/support/topic/404-errors-99/#post-10930281) * Status: not resolved