404 Errors

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

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