Support » Plugin: WP Document Revisions » 404 Errors

  • 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 2 years, 3 months ago by selliott.
Viewing 6 replies - 1 through 6 (of 6 total)
  • 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

    (@selliott)

    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

    (@selliott)

    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 2 years, 3 months ago by selliott.
    Thread Starter selliott

    (@selliott)

    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 2 years, 3 months ago by selliott.

    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

    (@selliott)

    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.