@mickna.
Sorry for the delay. I had not seen the new thread for a couple of days.
This note will be quite long.
I’ll first identify the processing associated with loading attachment records and then using the standard plugin and the reasons why it is set up like it is.
Suppose that we have a file Structured_File_Name.pdf that we want loaded.
My understanding is that you want it to be accessible as https://example.com/Structured_File_Name.pdf
[I don’t know the format of your file names so I’m making one up with some clear differences using Capital letters and underscores to show how processing is done.]
It will be useful to see what would happen if I simply load this file directly as attachment records as this will highlight a couple of issues.
First Attachment
Post_title Structured_File_Name
Post_Name structured_file_name
Permalink …/Structured_File_Name.pdf
File Name …/Structured_File_Name.pdf
Second Attachment
Post_title Structured_File_Name
Post_Name structured_file_name-2
Permalink …/Structured_File_Name-1.pdf
File Name …/Structured_File_Name-1.pdf
I have done two loads of the file since the plugin supports revisions – and although we hold all the revisions, the standard process is that the user gets the latest one whichever it is. However we can see that the later version has a different identifier – which, of course they should not know.
Note that the target of the permalink is the upload file. There is no WordPress processing involved in downloading the file.
Now we’ll compare with the standard processing done by the plugin. What we will do is to create a Document record with a Title set to “Structured_File_Name”. This is Published and then the file Structured_File_Name.pdf is loaded and the Document record saved. Finally the process is repeated.
Document Record
Post_title Structured_File_Name
Post_Name structured_file_name
Permalink
…/documents/2023/06/structured_file_name/
File Name -
Revision Record
<code role="textbox" aria-multiline="true" aria-label="Code" class="block-editor-rich-text__editable rich-text" style="white-space: pre-wrap; min-width: 1px;" contenteditable="true">Post_title Structured_File_Name
Post_Name structured_file_name
Permalink
…/documents/2023/06/structured_file_name-revision-2/<code role="textbox" aria-multiline="true" aria-label="Code" class="block-editor-rich-text__editable rich-text" style="white-space: pre-wrap; min-width: 1px;" contenteditable="true">
File Name -
Attachment Record 1
Post_title 884828c11e0a21efdeef9a891be73059
Post_Name 884828c11e0a21efdeef9a891be73059
Permalink
…/documents/2023/06/structured_file_name/
File Name …/884828c11e0a21efdeef9a891be73059.pdf
Attachment Record 2
Post_title 884828c11e0a21efdeef9a891be73059
Post_Name 884828c11e0a21efdeef9a891be73059
Permalink …/documents/2023/06/structured_file_name/
File Name …/884828c11e0a21efdeef9a891be73059.pdf
Now the important thing is that the attachment record contains this encoded name – as does the file itself. This is a deliberate design decision.
Its objective is so that you do not know the underlying file name – since if you did, then you could access the file directly without using WordPress functionality. This forces access to be via WordPress – which can control access, manipulate headers, etc.
Whilst the permalink uses the post name, i.e. structured_file_name, you can enter the post title as Structured_File_Name since it will be internally mapped to structured_file_name and so the document will be retrieved.
I think that instead of changing the Attachment name, you should consider creating your document record with no name, and then on uploading the file, and saving the document, then the document title should be set to the original file name.
By doing this, when entering the file name it will go through the process to deliver the file – even though it is actually different.
Please let me know if this would meet your needs.
Regards,
Neil James
