Support Forum
I'm using Metabox with a "File" field in a plugin. It's working as expected, including the ajax delete function.
However, if I add that field to part of a clone group the ajax delete function breaks and pops up an error when I try to delete a file.
I haven't had much time to debug, but I believe I may have the source of the problem as the 'ajax_delete_file' function in the inc/fields/file.php file. There is a call to a function called 'rwmb_get_field_settings' that is not returning any data, which causes the delete to fail.
Looking at the data that gets posted to the server when you call the ajax delete function, it seems the ajax call sends the name of the 'File' subfield inside the group instead of the name of the group. This causes the call to the 'rwmb_get_field_settings' function to fail. If I manually call the 'rwmb_get_field_settings' function with the name of the group instead of the subfield, it returns the expected settings data about the group.
So there's a a mismatch between the 'field_id' being posted back to the server, which is the name of the subfield in the group, and what the 'rwmb_get_field_settings' is expecting, which is the name of the group and NOT the subfield.
Hi,
Thanks for your feedback.
The setting force_delete
file of the field file
is not working properly in a cloneable group. I will inform the development team to fix this issue in future updates.
Hi Long,
That wasn't the setting I was referring to, but you answered my question as part of a comment in a other thread here: https://support.metabox.io/topic/error-invalid-file-when-delete-image-custom-field-user-type-image/
The important part of that thread was a comment where you said "Please use the field image or file as a top field, not a subfield to delete images/files when clicking "X" button. This issue will be fixed in the next update."
I updated to the latest version, but the error still occurs, however it's slightly better than with the old version.
I set up a few fields to test this out.
Metabox Version: 5.6.1
Addons: Groups and Tabs
In a tabbed Metabox I set up:
- 3 "file" fields
- A "clone group" with 1 "file" field set to allow a maximum of three fields.
I have uploaded a file to each of them, so have uploaded 6 files in total. All of the files uploaded successfully and the information was saved in the database.
As you know, underneath all 6 of the file I've uploaded there is now a red "Delete" link showing.
Expected behaviour: Clicking those delete links would delete the files.
Actual behaviour:
- For the three "file" fields that were added separately, and NOT as part of a group, the files are properly deleted.
- For the three files that were added as part of the clone group, only the last file added can be deleted. The rest show the "Invalid File!" error. What's weird is that it will always allow me to delete the last file in the list. So say I have File1, File2, and File3 in a clone group. I can delete File3, but not File1 or File2. But if I delete File3 and then save my post, when the page reloads it shows File1 and File2, and I can delete File2 but not File1. So if I had a list of 10 files in a clone group I would have to delete them one at a time starting at the bottom, and saving the post in between deleting each file.
Prior to updating to the latest version of Metabox it wouldn't allow me to delete files in a group at all, so being able to delete them one at a time is a slight improvement, but it's still not working the way it should.
There is a workaround I can use for now, by using a single file field that allows multiple file uploads. That causes the "add new file" link to show up so people can upload additional files.
However, my original reason for wanting to use a clone group is because my clone groups had a file field and a text field where people could enter a title for the upload. My current workaround doesn't allow adding a title to the files being uploaded.
Hi,
It is the issue that I've mentioned. Our developer has pushed a fixed for this issue, please find it here https://github.com/wpmetabox/meta-box/commit/1e38828ba6c4dc3c83240fdbc8f533bbd1b27a73
You can try to pull this branch to your staging site to re-check it.