CUNY Academic Commons

Right,not disappearing- thanks for the clarification.

Wont touch anything on the site for now. And ill tell the user know you are taking a look so hopefully they don't make any changes either.

We just got another similar report to the help desk

https://cl89200sp25.commons.gc.cuny.edu/

User writes:

It's running on the Ashe theme, and initially, the header image I chose displayed with no issues. Yesterday, >however, I noticed that the header was no longer visible, and when I tried trouble-shooting, I found that I >couldn't get any image to display in the header.

I've put a general fix in place in https://github.com/cuny-academic-commons/cac/commit/85f10ffcbceedb85a99af03486faf124cd4714b4, which is pushed to the production site. This fixes the problem for https://espeeuu.commons.gc.cuny.edu/ and probably most other sites.

The Ashe theme is doing something strange, which I'm now investigating.

Thanks for the fix and further investigation!

The problem with Ashe is that it shows the header image not using a 'src' attribute, but by printing a background-image CSS declaration to the page. The Ashe theme uses esc_url() when printing the CSS, which in general is a pretty good practice. But esc_url() encodes query arg characters like ampersands in such a way that CSS is unable to understand them. Therefore, the signature param is not included with the S3 request, and the user gets a 403.

If Ashe were abandoned, I'd put a hotfix in place. But it appears to be maintained, so I need some sort of persistent fix. The call to esc_url() is hardcoded into the ashe_dynamic_css() method, and there's no easy way to intercept that markup before it's echoed. So the technique I chose is as follows: add a callback to the 'clean_url' filter (inside of esc_url()); detect whether the caller is ashe_dynamic_css(); and if so, use esc_url_raw() plus some additional XSS mitigations. A general 'clean_url' callback would run far, far too often, so I try to target it by (a) only adding the filter at 'wp_head' if we determine that the current theme is running Ashe (and then unhooking it afterward), and (b) by checking the debug_backtrace() to ensure we're looking at the right caller. This method is totally bonkers, and perhaps in retrospect I should have unhooked 'ashe_dynamic_css' from 'wp_head', dumped it into an output buffer, and then done a search-replace on it. But I'm going to stick with this for now, since it's built and it's working: https://github.com/cuny-academic-commons/cac/commit/fe3813c76e618a7846ef9be3a7b4bc9f28c6e708

Copying Jeremy and Ray here so you're aware of the hoops we're jumping through. It's nearly certain that other themes are using PHP to generate background-image CSS using S3-stored files, and if they also use esc_url, then we will run into the same issue.

Laurie, if you're able to confirm that the images are working properly, I'll close this one out.

I can see now see the images on both course sites.

tested an image on another site ashe theme here too: https://yourname.commons.gc.cuny.edu/

All looks good to me. Thanks Boone!