Thread

First of all, fantastic work with the updates to File management. Have loaded up 2.2 to the site I’m developing and it’s great.

I am hoping that the image manipulation settings (resizing) will do away with my need for the ImgSizer plugin.

Simplified version of some code to set the scene (this of course works fine):

{exp:channel:entries}
    {banner}
    {content}
{/exp:channel:entries}

In the File Upload Prefs for the Upload Destination linked to the ‘banner’ file field, I have set up a thumbnail to be created using the Image Manipulation feature: short name ‘small’.

However, I’m unsure how to reference the ‘small’ thumbnail version, rather than the original image.

Replacing ‘{banner}’ with ‘{small}’ or ‘{banner_small}’ or ‘{banner:small}’ doesn’t work.

Using the File module appears to be the way to do this, with code along the lines of:

{exp:file:entries file_id="{???}"}
    {small}
{/exp:file:entries}

Question is though, if I did this inside an {exp:channel:entries} tag, how do I pass the file_id to the file tag? Using ‘{banner}’ only spits out a URL.

I’m sure I must be missing something here. The Image Manipulation feature seems fantastic and as if it was supposed to be the end of image resizing plugins, but I’m lost.

I don’t think you are missing anything unfortunately. I asked the same question myself and it seems that the functionality hasn’t been written yet to do this natively with a File field. You need to use the File Entries tag to get what you need at the moment.

Robin did say that it is going to be added in the near future though.

Best wishes,

Mark

Thanks Mark.

So let’s assume for the moment that the File Entries tag is the only way to go (something along the lines of my second example).

How can I go about letting the File Entries tag know what file I’m after? The only parameter that it appears to accept to that effect is “file_id”, yet the File field appears to only be able to generate a URL, not an ID.

Only thing I can think of at the moment is some PHP to either alter the URL to reference the smaller version (adding “/_small/” before the filename) or to use some presumably complex PHP/queries to try to retrieve the file_id knowing just the URL. Both of these options are of course ridiculous given I could just throw an ImgSizer tag around it, but it feels similarly ridiculous to subvert this feature which is surely designed precisely for this need!

Cheers and thanks again,

Ben

HI Ben,

Thanks Mark.

So let’s assume for the moment that the File Entries tag is the only way to go (something along the lines of my second example).

At the moment it is the only way although that tag I believe is more for creating a page where it shows the files uploaded I believe.

How can I go about letting the File Entries tag know what file I’m after? The only parameter that it appears to accept to that effect is “file_id”, yet the File field appears to only be able to generate a URL, not an ID.

I have to say I haven’t tried anything like that yet so not too sure although I do know that Robin mentioned that they will be adding in functionality to allow us access to all the other images / uploads at some point so hopefully that will be sooner rather than later.

Best wishes,

Mark

OK. Many thanks once again for your help on this Mark. I’ve just reverted to using ImageSizer for the moment and look forward to the next release when they integrate it all!

OK. Many thanks once again for your help on this Mark. I’ve just reverted to using ImageSizer for the moment and look forward to the next release when they integrate it all!

Yep, me too. Definitely will be nice when it’s all integrated.

Best wishes,

Mark

Thanks for starting this thread, I was searching high and low for a way to get ahold of the manipulated image’s URL - didn’t even think of the possibility that it’s not all properly integrated yet…

After reading this, I wrote a small plugin to take care of the string replacements which is rather trivial, as in prepending ‘_’ and the ‘short name’ of the desired ‘image manipulation’ to the actual file name.

Next problem I faced was getting ahold of the image dimensions in order to put width and height in the respective img tag (note that in my particular case I wanted the manipulated image to have a fixed width while the height is not specified).

Maybe I didn’t look ‘hard enough’ yet but it seems that EE does not store the resulting width/height of the manipulated image anywhere and basically doesn’t create any records anywhere for the manipulated image at all, so the best way to get ahold of the dimensions I came up with is to locally ‘inspect’ the manipulated image by the time I want to display it and have my plug-in generate the entire img tag.

Seeing that the current automatic ‘crop’ feature doesn’t really make sense either, as pointed out in https://support.ellislab.com/bugs/detail/15984/ I am not sure whether anyone would actually use the built-in EE mechanism over a tried and tested image resizer plugin just yet.

If there is demand and I can find a little time, I could put my current plug-in up on github or send it over for testing though.

aleksblendwerk,

Thanks for taking the time to create share plugin even if it was a necessity for yourself.

I am going to move this thread to Community Help for now in case others want to chime in on conversation

aleksblendwerk,

Good idea. As a super-simple alternative to manipulating the {file_field} string, you can use a tag pair:

{file_field}
{path}_small/{filename}.{extension}
{/file_field}

But of course we run in to the same issue regarding the image dimensions. And then of course again agree with your final point as to why the crop feature doesn’t make sense, so I’ve gone full circle to ImageSizer.

A bit more digging shows that the file field stores merely a URL in the database field - e.g.:

https://ellislab.com/asset/images/team-photo/file.jpg

Presumably the next step of integration will be to store instead a related file_id so that we can bring everything together. Then perhaps within the tag pair of a file field as shown above, rather than just have those three variables available, they would make available all of the tags currently available within the full-fledged File Entries tag (e.g. width/height, id, title, etc)

Anyway, I suppose now we just wait!

Thanks for asking the exact question I also had.  It only makes sense to associate a file_id with a channel entry file (from a database perspective).  Also, it seems that this functionality would be very useful to a lot of developers, so we’ll hope it makes it into a future release.

I tried this:

{exp:file:entries limit="1" search:file_name="{filename}"}
...
{/exp:file:entries}

inside the channel field file tag, and can access the {title} and {size} but nothing like {thumbnail_file_url} or {thumbnail_url}.  I think that is because the database table “exp_files” doesn’t even hold that other information.  There is no height or width, just a column named “file_hw_original” which is a VARCHAR field containing numerical characters for height and width separated by a space.  Baffling as to why there is no INT width and height fields.

Anyway, the two solutions above seem to be the state of the art for now.  You could do a complicated query to find the thumbnail height and width in the “exp_file_dimensions” table, but even then you have to hardcode query parameters.

Thanks for the help, and verifying I’m not the only one questioning this.

I think I figured out a solution:

{exp:channel:entries channel="products" limit="10"}

  {product_photo}

    {exp:query sql="SELECT file_id FROM exp_files WHERE file_name = '{filename}.{extension}' LIMIT 1"}
      {exp:file:entries file_id="{file_id}"}
        {Product_Thumb_file_url}
      {/exp:file:entries}
    {/exp:query}

  {/product_photo}

{/exp:channel:entries}

This gives you a thumbnail image related to an image which is a channel field in the specified channel.  (Your channel, thumbnail, and channel field names will be different)