Active
Project:
Drupal core
Version:
main
Component:
field system
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
22 Nov 2012 at 07:23 UTC
Updated:
14 Feb 2019 at 03:16 UTC
Jump to comment: Most recent
Comments
Comment #1
dave reidSome blockers:
#1448124: Image dimensions should be available from file_load() for images, and not stored in field data
Comment #2
dave reidComment #3
dave reid8.1.x material at this point
Comment #4
berdirfile/image actually extend the entity reference field type.
And as long as the have additional properties that they need to store, that'll stay like this. I'm fairly sure that continue to be like that at least for 8.x and not something that can be changed in 8.* as it would be major API and data change. Not sure if that's even the goal (some things like width/height, definitely but things like the display flag of file fields still makes perfect sense?)
Comment #5
dave reidWidth and height should be moved to the file entity object, and not stored in the field data: #1448124: Image dimensions should be available from file_load() for images, and not stored in field data.
The other problem becomes if I reference files using an entity reference field, I cannot use any image or field formatters. There's not enough sharing between the three field types.
Comment #6
berdirYes, as I said, width/height should definitely move away but I guess not all the other properties.
Yes, but that's actually solveable now. widgets/formatters now have a method to only apply to a field type with certain configurations.. for example, we have taxonomy term specific entity reference formatters. The same would be possible for an image/file formatter although they'd be missing things the file field display/description.
So we could open an issue to make them available.
My point is that I think we've likely done as much as possible already, apart from some problems that already have or should have separate issues. And might not even need this issue anymore...
Comment #7
yched commentedAgreed with what @Berdir said :
- since this issue was opened, a lot of progress was made on unifying the things that can be (file & image classes extend e_r classes, formatters extend the same base class...)
- but they need to stay separate field types since they have additional data and behavior, as demonstrated by the specific code that still exists in the respective Item and ItemList classes.
What might be discussed IMO is : should we reduce the UI confusion by hiding File entity in the list of entity types referenceable by a plain e_r field ? Is there a use case for referencing a file through an e_r field rather than through the native File / Image fields ?
Comment #14
johnpitcairn commentedYes. it might be desirable to be able to reference existing files in exactly the same manner as any other entity, without the ability to upload a file, but still display a file download link to the user.
I have exactly this use-case right now, and I think I'm gonna have to write a custom formatter, dammit. "Link to referenced entity" for an entityreference field's label formatter won't produce a link for file entities.