Hi Gunter,

Hope you had some time off!

Wanted to get back to you on the issue mentioned above that we need your help with.

We seem to have tracked down where the problem occurs with Imgix images and any masonry style ALB element (since they use the same core files). In the av-helper-masonry.php file it calls the make_image_responsive function and passes this string to it:

$img_html = '<img src="'. $attachment[0] . '" title="' . $img_title . '" alt="' . $alt . '" />';

Eventually the WordPress function wp_filter_content_tags attaches a width and height HTML attribute to the string because it’s not in the string. Because the way Imgix works (server.com/imgname.jpg?w=123&h=456), and every other image proxy service, WordPress looks up the details for imgname.jpg which it gets the full size width and height, it then adds these dimensions to the HTML rather than the width and height it’s requesting.

By comparing the code in other elements such as the easy slider or the image element (which work fine) we noticed that the difference in the way they works is that when these functions call the make_image_responsive function they pass in the width and height into this function. Eg.

$img_tag = "<img src='{$img[0]}' width='{$img[1]}' height='{$img[2]}'

This then stops WordPress later on looking up of the attachment details and adding the width and height. So how ever you pre-lookup the width and height in these other elements works fine.

So can you see the best way for us to get around this so that we can use Imgix and others can use other image proxy services without issue? We are not experts but thought of a few ways:

1. Should a lookup of the width and height happen and it be add to the HTML string before calling make_image_responsive like the other elements do?
2. Should we intercept the function that WordPress makes ( these is a hook there) and extract the width and height from the string Eg (server.com/imgname.jpg?w=123&h=456)
3. Some other better way that you think it should be done?

The first option seems the best as this problem only seems to be effecting the masonry element and option 1 is specific to masonry code.

Option 2 I worry will impact other unforeseen things and is unnecessary for all other elements as they work fine.

• This reply was modified 3 years, 9 months ago by THP Studio.

Hey Gunter,

Amazing turn around time on that fix, thanks so much!

Yeah I would love a copy to try out if I can please.

Thanks again

Tim

• This reply was modified 3 years, 9 months ago by THP Studio.

Hey Gunter,

That’s brilliant, thank you, really appreciate it.

Tim.

Hey Gunter,

I have just started playing the the new responsive typography feature, and I wanted to say a big thank you for implementing this suggestion.

I’ve only just started with it, so sorry if I’m missing something or don’t understand something fully, but I had a few questions/suggestions on it’s implementation.

1. In the articles I linked to when I started this thread, and in the ones you link to from the Enfold theme settings, to achieve the best responsive results they usually use em or rem units for font sizes. However, I can only select pixel sizes in the Enfold settings. Is there a reason for this? As a suggestion, could we do away with the drop down list of pixel sizes, and instead use a text entry box where we can enter a value that we want, such as 1em, 2vw, 1.5rem, 10px etc? This would provide a lot more flexibility, plus also I think would be quicker than using a drop down list for all of these sections. Then it would be easy to implement the typographic scales you link to in the articles for instance by simply copying/pasting the em values if we wanted to.

2. Would it be possible to add an option in for each h1-h6 section along the lines of “override individual page settings”? For instance, on some sites before this feature was added, I’ve customised the Special Headings using the responsive settings in the ALB element. But now with these global features, I have to find each one I customised and revert it to default for this new feature to take affect on it. Another possibility to help with this could be a global option “set all heading elements responsive styles to default” which as a one-time thing when starting to work with the new responsive typography element you can select it and know that any custom headings/special headings that you’ve ever customised over time are now back to defaults, so you can start using the new responsive typography without any surprises. (I think I prefer this second option)

3. How does this feature interact with the Advanced Styling tab? For instance, if values are set in responsive typography, and values for a H1 exist in the Advanced Styling tab, does the AS tab take priority? (It seems that way, but just want to be sure).

Thanks again Gunter for your brilliant work implementing these and other features.

Regards,

Tim

• This reply was modified 3 years, 10 months ago by THP Studio.

Hi Gunter,

Thanks again

Tim

Hi Gunter, that’s really great thank you for that.

Just out of curiosity, what was the reason to keep the current functionality and use filters for this fix? (rather than maybe the other way around)

Thanks so much for improving this for us.

Tim.

• This reply was modified 3 years, 10 months ago by THP Studio.

Hey Gunter,

Brilliant, that seems to have fixed it, thanks for such a speedy fix.

Have a great weekend,

Tim

HI Yigit,

Regards

Tim

This can be closed, thanks.

Hey Gunter,

Ah ok sorry I didn’t see that other thread.

That is a strange one. Maybe someone with some ARIA experience (not me!) can shed some light on it for the forum.

Thanks for getting back to me so quickly.

Tim

Hey Yigit & Gunter,

Been using this more and more and loving it, thanks again.

One small additional request:

Currently if you have a field, say a Text Area field, and you don’t want anything in the “Form Element Label” section, it still outputs a:

“: ”

in the email, as it’s expecting a field name like “Test: “.

So the resulting email can look like:

Test: 12345 (this field has a Form Element label of ‘Test’)
: 12345 (this field has a blank Form Element label)

But especially now that we can do headings using the new heading elements, can we change the logic to say that if we leave a fields Element Label section blank, that it doesn’t output a “: ” in the email?

I hope that makes sense.

Regards

Tim

Thanks Yigit!

Cache perhaps? I had to navigate to another front end page to see the logo show up, as my browser was caching the page I was on.

Perfect, thanks!

Off topic – will the final post-css elements be included in the next release too?

Hey Gunter, great thanks for considering this. I think it would be a really helpful feature.

And thanks Guenni007 for the suggestions!