Carbon-fields: [field] - Image field value

[nlemoine]

When using image field, the value saved is an absolute URL. I think saving the image ID would probably be more appropriate:

• It does not rely on a domain name (getting image URL from an ID will work event the domain has changed)
• It leaves the choice of choosing a size when displaying the image in a template
• It allows to retrieve metadata attached to the image file
  etc.

[tyxla]

Carbon Fields has a different field type that stores the ID - it is called Attachment.

You can read more about it here: http://carbonfields.net/docs/fields-attachment/

[nlemoine]

I read this part of the doc. I just don't understand why the attachment field saves the ID and the image don't.
IMHO, the only difference between those fields is only visual. But both should save IDs.

[nlemoine]

Would make sense from a client point of view? From a developer point of view, you are very limited with an image URL (see the cons I mentioned in the first place).

[tyxla]

This is a design decision we made some time ago.

The Image field type is a subtype of the Attachment field. It has the following differences, compared to the Attachment field type:

1. Image field allows only images to be uploaded;
2. Image field has slightly different appearance and button/label texts;
3. Image field stores the URL instead of the ID.

So if you want to store the ID (for any type of attachment, including images), simply use the Attachment field type.

From your perspective, it would probably make sense if the Image field is actually called Image URL. We might consider renaming it in the near future to avoid further confusion.

[nlemoine]

From your perspective, it would probably make sense if the Image field is actually called Image URL.

No. That's not the problem. From my perspective, saving the URL is a bad practice. Take a look at all plugins, libraries dealing with custom fields, they all chose to save to the attachment ID whether it's a file, a pdf, an image, etc.

But this is of course your call, it's ok if you leave it that way, I guess we have to agree to disagree :)

[fgilio]

Hi!
I also agree with @nlemoine on saving the ID, not the URL. The former would be much more useful.

On the other side... why not store the ID, give the option to choose the returned value and use a wrapper to return the value in the chosen format.
Am I clear?
It's like ACF does it. It gives you possibility of choosing the returned value when creating the field. Current options are: Image Array, Image URL and Image ID.

[tyxla]

Hi @nlemoine and @fgilio,

While I agree with you that saving as URL is bad practice, and we should save the ID, I guess you are missing the point. Let me clarify.

I'm not sure you understand the purpose of the Image (URL) field. Sometimes you don't want to store the image as a media attachment. Sometimes it is hosted somewhere else - on twitter/instagram, another site, blog or a CDN. In these cases, you should use a field that saves the URL. You don't have an ID to save, because you don't have a media attachment. This is when the Image field comes in handy.

And if you need to store it as an ID, use the Attachment field. It supports all types of files (PDF, DOC, images) and stores the attachment ID.

In terms of returning image array, URL or ID just like ACF does: this is a developer-oriented plugin, and a developer should be able to retrieve anything they want from the attachment ID. Why limit them to the array or a URL with a specific size?

With these thoughts in mind, I believe we can conclude this topic.

[emohamed]

The intuitive field type that most developers will use when they need an image is not attachment, but an image. So having an image field that saves it's value as an URL is developer-unfriendly, which goes against the philosophy of the plugin.

From your perspective, it would probably make sense if the Image field is actually called Image URL. We might consider renaming it in the near future to avoid further confusion.

:+1:

I think that this will resolve the issue as long as we actually change the image field type so it saves the ID. This is going to be a breaking change though. Not sure if there is elegant way to keep the backward-compatibility in this case.

Alternatively we could deprecate the image type and introduce new type that saves the ID and is specifically targeted for image attachments, e.g. img:

Container::make('post_meta', 'Cover Image')
    ->add_fields([
        Field::make('img', '_crb_cover_image'),
    ])

The old image type will resolve to image_url

What do you guys think?

[nlemoine]

@tyxla

Sometimes you don't want to store the image as a media attachment. Sometimes it is hosted somewhere else - on twitter/instagram, another site, blog or a CDN.

With a media manager link attached to the field, I didn't consider using an external image source. I get your point now. But still, I'll use a simple text field in that case. Hotlinking is not a very nice practice either and this is pretty rare or at least less frequent. In my opinion, in most developers expectations and most use case scenarios, the standard remains:

• using images from the media library
• I use an image field == I get the image ID when retrieving the field value on the front end

In a CDN case, many developers will opt in for something like an Amazon S3 plugin that intregrates seamlessly with the WP media library.

And if you need to store it as an ID, use the Attachment field. It supports all types of files (PDF, DOC, images) and stores the attachment ID.

Sure, but I consider the image field as a subtype of an attachment field. And again from a client perspective, it's less confusing to have a "select image" field (with files restricted to images only) than a "select files" field.

this is a developer-oriented plugin, and a developer should be able to retrieve anything they want from the attachment ID

Totally agree, I don't care if it's an object, an array as long as I can get the ID.

With these thoughts in mind, I believe we can conclude this topic.

I promess, this is the last one :)

@emohamed

Not sure if there is elegant way to keep the backward-compatibility in this case.

I guess that's the main issue here. Your solution looks good if the call is to keep the ìmage`field in place.

[fgilio]

I agree with naming it 'Image URL', as it's what it really is and IMHO when a dev reads 'Image' spects to get an ID from the DB.

I also agree with @nlemoine in this: 'it's less confusing to have a "select image" field (with files restricted to images only) than a "select files" field.'

PD: Sorry for the formatting in this comment, I'm replying from my phone

[tyxla]

Guys, thanks for your active participation in the discussion!

We've decided it is a good time to make some major changes on the file, image and attachment field types, as it really makes sense for the ID to be stored by default. And the earlier we do it - the less trouble we'll cause for compatibility with your themes and plugins.

Here is what we've done: https://github.com/htmlburger/carbon-fields/compare/42b10147c2ca3a473985fd2e833f1c24a9d50112...52c31d6983e565dcd0886ae8fb31b93c0d3de29e.

Here is a summary of the changes:

1. The attachment field has been removed. Use file instead. Using attachment will fall back to file for backwards compatibility reasons.
2. The file field will now save the media attachment ID instead of its URL.
3. The image field will now save the media attachment ID instead of its URL. Also, the image field now extends the file field instead of the no longer existing attachment field.
4. We've introduced set_value_type() method that you can use on both file and image fields. It allows you to change what is saved. So using ->set_value_type('url') will alter the field to save the URL (just like the file field was working before).

These will be addressed in the documentation as well - working on that right now.

So, no file_url or image_url field type was introduced, but in case you still want to store the URL instead of the ID, you can do it this way:

Field::make( 'file', 'custom_file_field' )
    ->set_value_type( 'url' )

Also, now there is a clear differentiation between file and image field types. If you want to store any file type (PDF, DOC, PPT, images or whatever format is allowed) - use file. If you want to store an image (JPG, PNG, GIF) - use image.

We're open for your feedback, and also feel free to ask any questions.

[nlemoine]

:+1:
Awesome! Thanks a lot for considering our feedback.

[fgilio]

Sounds great, thank you!