Publisher does not support the Fluid field type. Please do not contact asking when support will be available.

If you purchased an add-on from expressionengine.com, be sure to visit boldminded.com/claim to add the license to your account here on boldminded.com.

Ticket: SimpleGrid file shortcodes only output the url and dont respect {file_shortcode} {path}/{filename}{/file_shortcode} syntax

Status Resolved
Add-on / Version Simple Grids & Tables 1.5.1
Severity
EE Version 6.3.4

Rick Harrison

Aug 01, 2022

I’m using a SimpleGrid of files, but notice I can only get the full url of an image, none of the associated file attributes, so where i have a grid field called “photo”, using

<img src="{photo}" />

works as expected, but doing

{photo}
<img src="{path}{file_name}" alt="{description}" />
{/photo}

just results in the first reference to {photo} being replace with the image path, and leaves all the other variables unreplaced.
(Which means currently I can’t add alt-attributes to images for good accessibility, nor make use of EE’s image manipulations to fetch a resized image).

#1

BoldMinded (Brian)

I’ll have to look into this further, but do you have to use the full tag pair? If you just use {photo} and no tag pair, it’ll print out the full path to the file.

#2

Rick Harrison

Hey Brian - for a lot of our CMS builds we can’t trust the end users upload a reasonably-sized image, so we use expressionengine’s built-in file-upload image manipulation functionality to create a specific re-sized image automatically on upload - the output url from simple-grid is just the original un-optimized image that was uploaded (i’ve lost count of the number of times people upload 10Mb+ PNG files as photos and wonder why the site is slow!), where we would write it as follows (assuming the image manipulation is called “1200px”): {photo} {path}_1200px/{file_name} {/photo} So that we can explicitly access the resized version of the image (expressionengine puts the resized images in subdirectories - so that translates to /uploads/hero-images/_1200px/my-file.jpg instead of /uploads/hero-images/my-file.jpg

On top of that for better google lighthouse scores we’ll generally also use a JS plugin called lazysizes that allows us to specify multiple different-sized image urls and have the page dynamically lazy-load the version best sized for the size of the screen width for better download speed/rendering time - for example:

{photo}
[img]{path}/_thumbs/{file_name}xw0tG7F7wFxn4jGjd7Cv91tiVYUzBpubtypography_img_src_end
               data-src="{path}/_post_1440w/{file_name}"
               data-srcset="{path}/_post_375w/{file_name} 375w,
                            {path}/_post_750w/{file_name} 750w,
                            {path}/_post_768w/{file_name} 768w,
                            {path}/_post_1024w/{file_name} 1024w,
                            {path}/_post_1440w/{file_name} 1440w,
                            {path}/_post_1536w/{file_name} 1536w,
                            {path}/_post_2048w/{file_name} 2048w,
                            {path}/_post_2880w/{file_name} 2880w" alt="{description}" class="lazyload hero__bg"
               data-sizes="auto"
               data-low[/img]

And also very increasingly clients are looking for WCAG-2 spec accessible websites - so we need to be able to output a good image {description} or {title} attribute of the uploaded image - the easiest way it to take it from the file’s title and description attributes so they’re defined in one place. (ideally we also need the built-in {location} attribute associated with an image as we often use that within the html of an image too)

Note it’s not a super-urgent issue for us at the moment (but presumably is still limiting for other people) as i’ve written a simple custom plugin routine i’m using to wrap your file url output to look up the file in the database and template it’s attributes from the exp_files and exp_upload_prefs tables, but obvs it’s a dirty hack:

{exp:chatter_helpers:parse_file_attributes parse="inward" file="{photo}"}
{path}{file_name}
{/exp:chatter_helpers:parse_file_attributes}
#3

BoldMinded (Brian)

I was worried this was going to be a difficult fix, turns out it was pretty easy. Try the build in the comment.

#4

BoldMinded (Brian)

Comment has been marked private.

#5

BoldMinded (Brian)

I’m pretty sure the build in the previous comment fixes this issue, so I’m going to close this ticket.

Login to reply