File replacement and extension

etc · 2024-02-02 13:06:51

Currently (dev), when replacing a file, either by a local or a remote one, the new file is renamed to the current name. That’s handy for permlinks, but can be problematic when it has a different type/extension. Sure, admins should care, but errare humanum est.

Can/should we improve this somehow?

colak · 2024-02-03 03:29:47

etc wrote #336559:

Currently (dev), when replacing a file, either by a local or a remote one, the new file is renamed to the current name. That’s handy for permlinks, but can be problematic when it has a different type/extension. Sure, admins should care, but errare humanum est.

Can/should we improve this somehow?

Possibly yes, as not all txp users are savvy enough.

Bloke · 2024-02-03 06:59:19

etc wrote #336559:

Can/should we improve this somehow?

One option is to put a note near the file replace area that it will take on the old name so that references to it remain the same. Maybe just change the pophelp to tell people that’s what will happen. Presumably the same behaviour applies when assigning a missing file from the drop-down?

If an uploader knows what they’re doing they can always rename it after, right? That means it’s sort of consistent with the Images panel, albeit the name there is always “virtual” because the filename matches the ID.

Convention over configuration ftw.

etc · 2024-02-03 11:12:01

Seemingly, both name and numeric file extension are changed when replacing an image. Should we do this for files too? Or add an option to preserve the name?

Bloke · 2024-02-03 12:01:20

etc wrote #336562:

Seemingly, both name and numeric file extension are changed when replacing an image. Should we do this for files too? Or add an option to preserve the name?

Whichever makes most sense. Swapping a jpg for a png on the Images panel is more likely than, say, a docx for a pdf on the Files panel.

But since it’s possible for people to upload images to the files panel if they wish, I guess some sort of option or checkbox (state remembered) to preserve or retain could be useful.

etc · 2024-02-03 15:26:52

Whatever way, assigning a wrong extension looks like a bad idea for me. On the other hand, preserving the old file name is often handy. Could we handle it that way:

if the new extension matches the (old or newly assigned) filename, let it be
otherwise,
- either use the new file name/extension
- or retain the name of the old file, but change its extension, like we do for images.

Which means we’d leave the choice of the name with users, but not the extension. In this case, the extension should not even be editable by users.

Dragondz · 2024-02-03 15:43:16

Hi Oleg,

Your solution seems logical, because if the old file was pdf and the new one is a .doc, user who download it will be surprised.

Cheers.

Bloke · 2024-02-03 15:55:40

etc wrote #336564:

we’d leave the choice of the name with users, but not the extension. In this case, the extension should not even be editable by users.

Interesting. If you merely edit the name in the Images panel, the extension is optional and has no bearing on how the file is treated because the extension is determined from the id.ext filename.

If we’re going to display the File name without extension, we’ll need to display the file type somehow on the panel info. Whether this is the extension or querying its mime type (or both) I don’t mind.

phiw13 · 2024-02-13 06:22:46

I see you more recent commit(s) now have a warning when the user uploads a replacement file with a different extension then the original file. That is sufficient I think, the user has the option to cancel the upload if in error or is reminded to update the filename if needed.

(I had the same idea last week while sitting in one of those horrible flying cigar-like things… les grands esprits etc.)

One thought though. The layout of the file upload/replace block is a little strange when there is also an unregistered-in-the-DB file select widget (#existing_file). Visually it looks like the second select is dependency on the first field (file upload widget). A bit confusing…

Would the following be a slightly better markup structure? (Sample/demo here with Sandspace)

<form class="txp-upload-form async replace-file" method="post" enctype="multipart/form-data" action="#">
  <div class="txp-form-field file-uploader">
    <div class="txp-form-field-label">
      <label for="file_replace">Replace file&nbsp;<a rel="help" title="Help" role="button" class="pophelp" href="#"><span class="ui-icon ui-icon-help">Help</span></a></label>
    </div> 
    <div class="txp-form-field-value">
      <input name="thefile" type="file" required="required" id="file_replace">
    </div>
  </div>
  <div class="txp-form-field file-existing" id="existing_container">
    <div class="txp-form-field-label">
      <label for="existing_file">Existing file</label>
    </div>
    <div class="txp-form-field-value">
      <select name="newfile" id="existing_file">
        <option value="" selected="selected">&#160;</option>
        <option value="uploaded_file.pdf" dir="auto">uploaded_file.pdf</option>
        <option value="darkness_green.pdf" dir="auto">darkness_green.pdf</option>
        <option value="darkness_red.pdf" dir="auto">darkness_red.pdf</option>
      </select>
    </div>
  </div>
  <div class="txp-form-field-shim">
    <span class="inline-file-uploader-actions">
      <input type="reset" value="Reset">
      <input type="submit" value="Upload">
    </span>
  </div>

<progress class="txp-upload-progress hidden"></progress>
<div class="txp-upload-preview"></div>
</form>

etc · 2024-02-13 13:48:02

phiw13 wrote #336621:

One thought though. The layout of the file upload/replace block is a little strange when there is also an unregistered-in-the-DB file select widget (#existing_file). Visually it looks like the second select is dependency on the first field (file upload widget). A bit confusing…

Would the following be a slightly better markup structure? (Sample/demo here with Sandspace)

Not sure. Formally, both inputs serve the ‘replace file’ feature, hence their common ‘title’ looks justified. Technically, though, #file_replace input might acquire its own ‘upload’ label, but this requires rewriting our (ugly) upload_form() function.

phiw13 · 2024-02-14 01:16:09

etc wrote #336623:

Not sure. Formally, both inputs serve the ‘replace file’ feature, hence their common ‘title’ looks justified.

Would it improve the narrative it the whole block (.txp-upload-form) is preceded by a heading (h3 Replace file) ? See my updated sample/demo – I added two headings, and wrapped each block in its own <section>……</section>. The text of each <label/> might be served with some better wording. Not sure if that would help (or not) for the back-end code.

The way I see (or an AT would read) is a block with two possible actions.

Now if think that going that way is more complicated than you’d like on a technical level in the upload_form code, I certainly will understand ; I wouldn’t want to abuse your time:-)

And this is possibly an edge case, do many people have “unregistered” files on their servers? I certainly don’t.

Textpattern CMS

Textpattern CMS support forum

#1 2024-02-02 13:06:51