BoldMinded

All add-ons currently require PHP 7.4 or greater.

On July 4th 2024 PHP 8.2 will be the new minimum requirement for all add-ons. Expect any add-on released after that date to require 8.2 or greater. Some releases may not immediately take advantage of 8.x specific features in PHP, which means you might, be able to continue using new releases in PHP 7.4, however, if you experience an error the first thing you should do is update to PHP 8.2 then create a support ticket if the error persists.

Please read about the changes to BoldMinded add-on licensing.

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}2oX10BPvKe8LGEzytlg1Hb9Ab8m2Zjpptypography_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