Wasca

@vmarko I have updated my site to the latest version of W3TC, however the conflict error still occurs.

Hi Guys

I’m seeing the same issue using BuddyBoss Theme(v2.07). When a user uploads their profile image they are prompted to crop the image, but the cropped image is never pushed to the S3 Bucket and the URL is never updated to use the CDN URL.

@staxwp Thanks for the update!

I can’t say when it started to occur.

I have this in the “custom file list”, which should handle all the *.js files under /wp-content/plugins/elementor/ folder and its sub-folders.

{plugins_dir}/elementor/*.js

What does adding that path to the rejected files do? I want the file to be pushed to the CDN.

@vmarko I’m at a loss at how to get these WOFF and WOFF2 font files to appear in my S3 Buck with the Cache-Control header added. I would really appreciate it if you could test the process and see if you can get the WOFF and WOFF2 file listed in “Custom file list:” to appear in an S3 Buck with the Cache-Control set. You need to to test it with NGINX.

Thanks

I’m seeing the same issue, would be good if the plugin developer could help us out.

For our site the error existed in this function (function wpua_get_avatar_filter) in this file

/wp-content/plugins/wp-user-avatar/includes/class-wp-user-avatar-functions.php

We’ve temporarily changed line 476-479 from this

$avatar = sprintf(
           '<img src="'.$wpua_final_avatar_image_src.'"'.$default_image_details['dimensions'].' alt="'.$alt.'" class="avatar avatar-'.$size.' wp-user-avatar wp-user-avatar-'.$size.' photo avatar-default%s" />',
           esc_attr( implode( ' ', $class ) )
       );

to this

$avatar = '<img src="'.$wpua_final_avatar_image_src.'"'.$default_image_details['dimensions'].' alt="'.$alt.'" class="avatar avatar-'.$size.' wp-user-avatar wp-user-avatar-'.$size.' photo avatar-default'. esc_attr( implode( ' ', $class ) ) .'" />';

and the following lines below that

$avatar = sprintf(
           '<img src="'.$default_image_details['src'].'"'.$default_image_details['dimensions'].' alt="'.$alt.'" class="avatar avatar-'.$size.' wp-user-avatar wp-user-avatar-'.$size.' photo avatar-default%s" />',
           esc_attr( implode( ' ', $class ) )
       );

to this

$avatar = '<img src="'.$default_image_details['src'].'"'.$default_image_details['dimensions'].' alt="'.$alt.'" class="avatar avatar-'.$size.' wp-user-avatar wp-user-avatar-'.$size.' photo avatar-default'. esc_attr( implode( ' ', $class ) ) .'" />';

Hope this helps someone else.

• This reply was modified 3 years, 8 months ago by Wasca.

Go have a look what we did here.

https://www.ads-software.com/support/topic/bug-report-users-pictures-arent-showing-in-the-frontend-of-the-page/#post-14170697

• This reply was modified 3 years, 8 months ago by Wasca. Reason: Changed the way I teporarily fixed the issue

@vmarko Does W3Total Cache set the “type” and “cache-control” when it uploads the files to S3? If so, I think that part is broken for WOFF and WOFF2 files. All other files seem to get the correct “type” and “cache-control” metadata added to them when W3Total Cache uploads them to S3.

I’m still having the same issue.

I have noticed that the woff and woff2 files have a type of “octet-stream” instead of “woff” or “woff2” like some other font have.

https://imgur.com/a/BO3hyl2

These fonts appear to have the correct type set.

https://imgur.com/pC2iYak

@vmarko what I’ve noticed is that the woff and woff2 files when getting uploaded to S3 via the Custom Files Export process are not getting the Cache-Control max-age=31536000, public Meta value added to that file.

Here is what I’m seeing for the meta data for WOFF files

View post on imgur.com

This is what the meta values for a ttf file looks like once uploaded to S3

View post on imgur.com

• This reply was modified 3 years, 11 months ago by Wasca.

When I turn off the CDN I am seeing the Cache-Control setting being added to the font files perfectly fine.

View post on imgur.com

As soon as I turn on the CDN (Host Custom Files option) then the WOFF and WOFF2 fonts do not have the Cache-Control settings applied to them.

View post on imgur.com

• This reply was modified 3 years, 11 months ago by Wasca.

Hi @vmarko

Here is the URL: https://cmt.optuma.com/

There are no AWS origin settings for for the bucket. There is a caching policy for the Cloudfront distribution.

You can see the cache policy here

View post on imgur.com

Could it be because the “Initiator” is a .gzip file?

https://cdn.cmt.optuma.com/wp-content/themes/buddyboss-theme/assets/fonts/fonts.css.gzip

View post on imgur.com

• This reply was modified 3 years, 11 months ago by Wasca.

Thanks @vmarko ??

I think I was able to fix this, it looks like for some reason I this in the Rejected Files setting in CDN.

{plugins_dir}/