Feature Request: Static CDN Filters w/ Output Buffer

[xberg]

Hi, I would like to see the option to rewrite root relative refs in your CDN implementation as the plugin CDN Linker does.

I want to have links like /wp-content/xyz.png rewritten - i. e. without my blog’s domain as prefix.

Otherwise a lot of my images are not being served thru the CDN.

Thanks

[raamdev]

@xberg The ZenCache Static CDN Filters already handle relative refs.

I just tested this by enabling Static CDN Filters on my test site, then adding an image to a post and changing the src="" attribute to use a relative URL:

<img src="/wordpress/wp-content/uploads/2011/11/Ananda-1-week-old-225x300.jpg" alt="Ananda-1-week-old" width="225" height="300" class="alignnone size-medium wp-image-264" />

When I published and viewed the page on the front-end of the site, the Static CDN Filters correctly rewrote that relative URL by adding my CloudFront CDN hostname:

<img src="http://dktuaalw08xdd.cloudfront.net/wordpress/wp-content/uploads/2011/11/Ananda-1-week-old-225x300.jpg?iv=1" alt="Ananda-1-week-old" width="225" height="300" class="alignnone size-medium wp-image-264">

[raamdev]

I should add that if you have a bunch of images that the Static CDN Filters are not rewriting as you would expect, then you likely have another WordPress plugin, or possibly even your WordPress theme, inserting those images into the content of your site after the ZenCache Static CDN Filters has processed the content.

If a theme or plugin modifies WordPress content output in a non-standard way (i.e., it does not hook into the the_content filter, as all plugins/themes should), then ZenCache has no way of seeing the content that's getting added and rewriting those URLs.

[lkraav]

Sure you would. Hook into something really late, like shutdown hook and, catch the final output buffer and rewrite at that stage.

[xberg]

Raamdev, you are certainly right: this affects custom built pages and these might not have been developed with best practices in mind. That said, CDN Linker rewrites these links fine when I enable "relative refs" and Zencache does not. Of course it's your decision to enable support for less than optimally developed themes :)

[jaswrks]

@raamdev writes...

I just tested this by enabling Static CDN Filters on my test site, then adding an image to a post and changing the src="" attribute to use a relative URL:

I can confirm this also. Root-relative URLs (e.g., /wp-content/path/to/image.png) are filtered as well. Relative URL paths like ../wp-content/path/to/image.png are not filtered at this time.

@xberg writes...

this affects custom built pages and these might not have been developed with best practices in mind.

Can I assume that you mean a custom page template? In what way do you feel ZenCache is missing this content? At the moment, ZenCache filters all URLs generated by WordPress functions like home_url(), content_url(), etc. In addition, we also filter the_content overall.

We could improve on this later by filtering with an output buffer perhaps, but I'd still like to hear what sort of "custom built pages" are finding their way around these standard filters exactly. If you can let us know it might help whenever we come back to improving this in the future. Thanks! :-)

[lkraav]

I have a simple one. Build a page which is assembled from a combination of built-in content fields and wysiwyg custom fields, which is probably a pretty standard approach for long-form stuff. In your content template you output the main content block somewhere up above with the_content() but then you might also output a bunch of additional div containers that get their values however (get_post_meta()). Advanced tools like ACF would filter things automatically perhaps with get_field(), and yes, the template author should specifically take care to run all output through apply_filters( "the_content" ), but it's dead easy to miss this.

[jaswrks]

@raamdev I just took a closer look at this feature request; i.e., for Static CDN Filters to be applied as an output buffer. I'm not convinced it is a good route to take yet. I'm going to remove this from the Next Release milestone so we can take time to think this over first. I jumped the gun a bit here.

[raamdev]

I'm going to remove this from the Next Release milestone so we can take time to think this over first.

Sounds like a good idea to me. Thanks!

[jaswrks]

Another check in the plus column for this feature. Referencing private (internal) ticket: https://websharks.zendesk.com/agent/tickets/10106

The problem: Hard-coding a URL (e.g., while working in the Visual Editor) which leads to a media resource results in the URL not being filtered, because as it stands now the Static CDN Filters are applied to WP-driven URL filters only, and not to static content; i.e., filters are not applied to the final output, but at runtime.

[renzms]

On a related note contributing to this, CDN filters are using HTTP instead of HTTPS

Referencing internal ticket: https://websharks.zendesk.com/agent/tickets/10332

[jaswrks]

@renzms writes...

CDN filters are using HTTP instead of HTTPS

Note that HTTPS must be explicitly enabled whenever you configure Static CDN Filters, because your CDN needs to be configured in ways that allow for this to function as intended. If after reviewing the configuration panel for Static CDN Filters in ZenCache, you are able to find a bug, please open a separate issue for this.

[renzms]

Customer reported a conflict with Timber and Comet Cache using MaxCDN. Image URL's do not get filtered by the CDN. However, the JS / CSS files are loaded correctly.

---

Referencing internal ticket: https://websharks.zendesk.com/agent/tickets/11793

[raamdev]

@renzms Did you forget to mention that working on this GitHub issue (Static CDN Filters w/ Output Buffer) might help resolve the issue with Timber?