Meta Box

There is a really easy fix for this.

The only reason this problem exists is because the plugin calls the "wp_get_attachment_image" function on whatever is returned, since it expects an attachment ID.

So if a simple check is done on the returned value first, we can change the output based on if it's attachment ID or a file URL.

Inside the image.php file if I add a new variable like this:

$attachment_image = (is_numeric($file)) ? wp_get_attachment_image( $file, $field['image_size'] ) : '<img width="150" height="150" src="'.$file.'" alt="" />';

I can then replace the call to wp_get_attachment_image with the $attachment_image variable instead. If an attachment ID is returned, it works as it always did. But if a file URL is returned (because a custom upload folder was used) the preview image still shows up as expected.

This small change seems to make the plugin work as expected, and removes one of the limitations people may run into.

So the original code looks like this:

		return sprintf(
			'<li class="rwmb-image-item">
				<div class="rwmb-file-icon">%s</div>
				<div class="rwmb-image-overlay"></div>
				<div class="rwmb-image-actions">
					%s
					<a href="#" class="rwmb-image-delete rwmb-file-delete" data-attachment_id="%s"><span class="dashicons dashicons-no-alt"></span></a>
				</div>
				<input type="hidden" name="%s[%s]" value="%s">
			</li>',
			wp_get_attachment_image( $file, $field['image_size'] ),
			$edit_link,
			esc_attr( $file ),
			esc_attr( $attributes['name'] ),
			esc_attr( $index ),
			esc_attr( $file )
		);

And with my changes, it looks like this:

$attachment_image = (is_numeric($file)) ? wp_get_attachment_image( $file, $field['image_size'] ) : '<img width="150" height="150" src="'.$file.'" class="attachment-thumbnail size-thumbnail" alt="" />';
		return sprintf(
			'<li class="rwmb-image-item">
				<div class="rwmb-file-icon">%s</div>
				<div class="rwmb-image-overlay"></div>
				<div class="rwmb-image-actions">
					%s
					<a href="#" class="rwmb-image-delete rwmb-file-delete" data-attachment_id="%s"><span class="dashicons dashicons-no-alt"></span></a>
				</div>
				<input type="hidden" name="%s[%s]" value="%s">
			</li>',
			$attachment_image,
			$edit_link,
			esc_attr( $file ),
			esc_attr( $attributes['name'] ),
			esc_attr( $index ),
			esc_attr( $file )
		);

I've implemented a solution to this issue that's working for me.

Cloning the group does clone my hidden fields, but they keep the same value.

I have some JavaScript that listens for changes to the DOM directly, and if a clone is added to that group the value is reset to 0.

I haven't tested it extensively yet, but in the testing I have done it seems to be working exactly how I want.

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.

Great, thank you. I was having some trouble and wanted to make sure I was doing it correctly, but my problem was related to another issues and it's now working properly.

Thanks for your help.

I have resolved this issue and you can delete this thread.