-
“Failed to fetch” error in the panel, happens often when you just close the laptop for a few minutes. Maybe a little hint to just try it with a reload?
-
Replace an image: You need the same extension to replace an existing image - which of course doesn’t matter to the editors. Why not allow all extensions?
I get the “Failed to fetch” message several times a day – usually for the reasons you mentioned. A clearer response like “No internet connection” would be much more helpful and easier for users to understand.
Replacing an image with a different format can also cause problems – especially if certain formats are required in a template, plugin etc.. A typical example is the company logo: Replacing an SVG with a PNG can lead to an error if the template uses the svg() method, which only supports SVG files.
In many cases, the file format is not relevant – therefore, it would be desirable to allow different formats when replacing images.
However, I find the restriction that images with the same name cannot be replaced using drag-and-drop much more annoying. Especially with larger image lists – for example, with 100 entries – this quickly becomes tedious if 20 images with identical names already exist and only need to be replaced with updated versions.
I cannot confirm that this is not possible.
Steps to reproduce:
- Install Starterkit
- go to an image, e.g. http://localhost:8000/panel/pages/photography+trees/files/last-tree-standing.jpg
- try to replace it with a .png
there should be no problem if we allow all filetypes of the original upload field…
Well, I did that before I posted my answer. Works fine for me in a fresh 5.0 Starterkit
1 Like
I just tried this with a Kirby 5 starter kit.
A JPEG can only be replaced with a JPEG, all other formats are grayed out:
Got it: on Mac / Chrome you need to set the format options to “all files” first, then you can also select and upload other filetypes… Sorry, I’ve never checked that. But why is it set to “custom files” in the first place? My editors often contact me and say that they can’t upload the files they want
Now I’ve noticed the well-hidden option too…
Thank you Apple for this well-considered decision 
1 Like
Seems to be a browser thing. Safari doesn’t show this option (at least not on my Mac), Firefox and Chrome have the options, but in Chrome not needed, as it shows all file types by default.
But is this the right way? Shouldn’t the HTML input have the correct “accept” attributes, corresponding to the files template?
But is this really intended?
In my tests, replacing a JPG file with A PNG will lead to a PNG file with the .jpg extension. In the upload confirm dialog I even see the correct/new extension.
Discussed this last night with the team, and no, it is in fact not intended. The extension or mime type should be the same. But in any case, there should be an error message in that case, so this is somehow buggy.
1 Like
@lukasbestle Thinking out loud here but could this have been broken with the chunked upload changes? That maybe the mime type isn’t correctly identified at first and also not checked properly again when the upload is completed? Haven’t had the chance to investigate this but wanted to leave a note (also to myself).
The new Upload class renames the file so that the extension matches the detected MIME if the uploaded source name does not have an extension or the extension is tmp or temp. This happens before the actual $file->replace() operation is triggered.
One thing I found is that $file->replace() calls $file->asset($source). But $file->asset() caches the first asset object in an instance prop, no matter if its props match. This is most certainly a bug. Caching should only happen when called with empty props. But not sure if it’s the bug that causes this issue.