Problem with Images/Media

Sylvain,

First of all thank you for the kind words!

Second of all thank you for doing the legwork of ruling out the simplest root causes for this issue.

The plugin rewrites all applicable media files in the rendered HTML in this case to go through our CDN. The media files should be including :

'jpg|jpeg|png|gif|bmp|pdf|mp3|m4a|ogg|wav|mp4|m4v|mov|wmv|avi|mpg|ogv|3gp|3g2|webp|svg'

So whats happening is some media files are not being routed through our CDN? This could mean that another plugin is interrupting or circumventing the above file extension rewrite to change yourdomain.com/wp-content/uploads/file.jpg to go through the CDN url.

If I had to guess, maybe a plugin like “Rename media files” could be the culprit?

Alternateively what I would do is lets zero in on one media file thats not being rewritten to go through the CDN. Focus on that one media file thats not working (so long as its in the above list of media files).

Then disable each plugin one by one and see if it ever starts working. To prioritize things, if I had to guess, you could start with these plugins to disable (hopefully to save time) :

1. Autooptimize
2. Enable media replace
3. Media file renamer
4. Network media library
5. Rename media files
6. WP Optimize

If none of those resolve the problem, then run through the rest of the plugins one-by-one. I would be sure to clean the cache of a cache based plugin prior to disabling just in case the deactivation of those plugins doesnt auto clean cache.

You can hopefully appreciate how difficult it is to avoid these types of conflicts with WordPress plugin development in general. If we do isolate a plugin that is causing it , please let me know here. I can give it a shot to see if there is any custom workaround that can be implemented for this particular scenario. If you dont need the plugin or its not integral, even better! Just leave it deactivated ??

Again I dont mind helping with this diagnosis , if you run into trouble just pass some admin credentials to the test site to the email above.

Hopefully we get this resolved for you!

• This reply was modified 4 years, 3 months ago by Yui.
• This reply was modified 4 years, 3 months ago by Yui. Reason: dont ask for login credentials

Hi again Shift8,

First of all, let me say that I did what you suggested.
First I cleared all possible caches.
Then, I began by disabling all the 6 plugins you suggested with NO luck!
Then, I went for the home run, I disabled ALL Plugins. NO more luck! NO changes!
The problem persists!
It seems the problem is NOT related to a possible conflict with any Plugins!

By the way, the 3 “Media Renaming” plugins (#2, #3, #5) are rather “statics”. They facilitate the renaming of Media files on disk and updating all the DB links accordingly, without requiring to delete some Media and Uploading new ones with an other name. They don’t act on the fly on any way.

The “Network Media Library” plugin (#4) though provides a central media library that’s shared across all sites on a Multisite network. It allows all sites on a Multisite Network to “share” common Media Images files stored in the main “Uploads” directory rather than having to spread Media files all over the place in various “Sites #No.” directories.
Here, I don’t know if this strategy may have an effect on your product?
Maybe you can tell…

Regarding the “rewriting” of Media URLs to route the Media files through the Shift8 CDN, I noticed that when I installed your service for the first time (after registering), the process added the following code in the .htaccess file in the WordPress root directory:

# BEGIN Shift8 CDN
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^sylver-tech\.com$ [NC]
RewriteCond %{REQUEST_URI} \.(jpe?g|png|svg|gif|pdf|tiff|css|js|eot|ttf|woff2?)$ [NC]
RewriteRule ^ https://bg2jxdf1juus.wpcdn.shift8cdn.com%{REQUEST_URI} [R=301,L]
</IfModule>
# END  Shift8 CDN 

Besides, when I registered a 2nd “Pull Zone” for the “Test-01” site, a new CDN URL was issued (https://rmtz4odwfzo1.wpcdn.shift8cdn.com), but this new CDN route was not added anywhere in any .htaccess files.
So, I don’t know if it’s OK, and if so, I don’t know how the assets of this secondary site can find its route???

Finally, amongst all the site’s pages, there are not much media files that succeeded to be served by the Shift8 CDN, but over time, one thing that I observed is that the only files that succeeded have one thing in common: they all had “brotli” as “content-encoding“. Never saw other “content-encoding” formats. Besides, “.css” and “.js” files had other “content-encoding” formats, namely “gzip”, etc.

That’s it! These are my bests findings from my side till now.
Maybe these observations may trigger some light from your part. At least I hope, because that’s all I can see for now…

Hello!

Besides, when I registered a 2nd “Pull Zone” for the “Test-01” site, a new CDN URL was issued (https://rmtz4odwfzo1.wpcdn.shift8cdn.com), but this new CDN route was not added anywhere in any .htaccess files.
So, I don’t know if it’s OK, and if so, I don’t know how the assets of this secondary site can find its route???

The rules at first glance look right either way. The rewriting that happens in our plugin is in the code actually where it is detecting and rewriting all the urls that match the file types specified (media,js,css,etc).

Finally, amongst all the site’s pages, there are not much media files that succeeded to be served by the Shift8 CDN, but over time, one thing that I observed is that the only files that succeeded have one thing in common: they all had “brotli” as “content-encoding“. Never saw other “content-encoding” formats. Besides, “.css” and “.js” files had other “content-encoding” formats, namely “gzip”, etc.

When a url actually goes through our CDN, it should have brotli compression enabled by default. This is likely why you are seeing that header.

Just looping back to the originally reported problem, you mentioned that one image would go through the CDN but then the remainder are not? Can you give me an example page where this is happening as well as the file names that it is working and not working?

Hello Shift8,

The rules at first glance look right either way. The rewriting that happens in our plugin is in the code actually where it is detecting and rewriting all the urls that match the file types specified (media,js,css,etc).

If I understand you well, the code in the “.htaccess” file is not required?
If it is present, is it superseded by the code in the plugin?
In other words, does the code in the plugin have priority over the code in the “.htaccess” file?

Can you give me an example page where this is happening as well as the file names that it is working and not working?

If you refer to my 1st post:

The problem can be seen if you look for ” https://sylver-tech.com ” at GTMetrix (Waterfall / Images + Other) and/or at Pingdom.

But if you can check the HTML source code of the ” https://sylver-tech.com/test-01/ “ page ( view-source:https://sylver-tech.com/test-01/ ), you will see the full details of all references to assets that have been catched by the Shift8 plugin and those that haven’t.

Just to summarize the result, check the table below:

Type of assets SHIFT8 Ref. NON SHIFT8 Ref. TOTAL

.css 14 0 14
.js 21 0 21
.gif 5 10 15
.jpg 0 8 8

As you can see, all “.css” and “.js” are successfully catched, “.gif” are partially catched and “.jpg” are NOT catched at all.

Hope this will allow you to better seize the problem.

Hello,

If I understand you well, the code in the “.htaccess” file is not required?
If it is present, is it superseded by the code in the plugin?
In other words, does the code in the plugin have priority over the code in the “.htaccess” file?

The htaccess may be more efficient, but for the purposes of troubleshooting, please comment that out and let the plugin handle the rewrites directly.

As you can see, all “.css” and “.js” are successfully catched, “.gif” are partially catched and “.jpg” are NOT catched at all.

Maybe you can help break down how these images are loaded on the page:

• https://www.sylver-tech.com/test-01/wp-content/uploads/weather-station-small.jpg
• https://www.sylver-tech.com/test-01/wp-content/uploads/smartherm-pci-3-0.jpg

Are you able to confirm that you aren’t using any sort of “lazy loading” of images in any caching plugin, or post grid or anything of that nature? Our plugin cannot rewrite images that are lazily loaded.

For example W3 Total cache has options to enable lazy loading of images : https://www.boldgrid.com/support/w3-total-cache/configuring-lazy-loading-for-your-wordpress-website-with-w3-total-cache/

If this is enabled and disabling this resolves the problem, I’ll spend efforts at figuring if there are workarounds to this. At the original time of the plugin’s development, there was no easy way to rewrite images that are lazy loaded simply due to the nature of how lazy loading works (jQuery + ajax query after a page is loaded to update the DOM with images to make the page appear to load faster).

Please let me know if I am on the right track.

Thanks!

Alternatively you could switch the “off” switch for the Shift8 CDN settings page and add the CDN url to the CDN section of W3 Total cache. Since at this point there are multiple plugins handling asset rewriting on your site, it might be more efficient if W3 Total cache handles the rewrites to our CDN for now. This is an alternative solution if my previous message produces no feasible results.

Hello,

First of all, I should say that the Plugins List generated by the “Support” tab in your Settings page is very misleading because it is labeled “Active Plugins:” when it is a list of “

“, Active as well as INActive!
So, the REAL “Inactive Plugins List” should have been:

Admin Menu Editor (1.9.5)
Advanced Image Styles (0.4.1)
Advanced TinyMCE Configuration (1.6)
Better Search Replace (1.3.3)
Canada Post Shipping For WooCommerce (2.5.1)
Classic Editor (1.5)
Collapse-O-Matic (1.7.11)
Disable Cart Fragments (1.21)
Duplicate Page (4.0)
Duplicator (1.3.24)
Easy Google Fonts (1.4.4)
Enable Media Replace (3.3.11)
Google Analytics for WordPress by MonsterInsights (7.10.4)
Header and Footer Scripts (2.1.1)
Hummingbird (2.4.2)
Insert HTML Snippet (1.3.1)
Media File Renamer (Auto Rename) (4.7.0)
Mesmerize Companion (1.6.111)
MslsMenu (2.1)
Multisite Language Switcher (2.3.0)
Network Media Library (1.5.0)
Ninja Forms (3.4.24.1)
Rank Math SEO (1.0.45)
Rename Media Files (1.0.1)
Shift8 CDN (1.42)
Shortcode For Current Date (2.1.1)
Shortcoder (4.6)
Social Bucket (1.0.9)
The SEO Framework (4.0.7)
TinyMCE Advanced (5.3.0)
Ultimate FAQ (1.8.30)
UpdraftPlus – Backup/Restore (1.16.21)
WooCommerce (4.2.2)
WordPress Importer (0.7)
WP-Optimize – Clean, Compress, Cache (3.0.16)
WP Cerber Security, Anti-spam & Malware Scan (8.6.6)
WP Fail2Ban Redux (0.5.1)
WP Site Importer (1.9.5.1)

Are you able to confirm that you aren’t using any sort of “lazy loading” of images in any caching plugin, or post grid or anything of that nature? Our plugin cannot rewrite images that are lazily loaded.

For example W3 Total cache has options to enable lazy loading of images :

Don’t focus too much on “W3 Total cache” !
This Plugin was in the original first “Plugins List” above, but has been disabled a long time ago (many months) as well as “Autoptimize” which has similar functions and features (Assets Optimization, Minification, Header & Footer Assets and Images Loading, Caching, etc.). These were the first plugins that we downloaded for Page Optimization but after testing these we downloaded the Hummingbird plugin at this end, and

I totally disabled the first two

and retain Hummingbird for Page Optimization and Caching.

Since I issued this Support Ticket though, I completely disabled the Caching and Page Optimization options of the Hummingbird plugin, at least for the ” https://sylver-tech.com/test-01/ ” site.

Also, don’t forget that following your recommendations above, I also completely disabled all plugins and caches to make tests…

Regarding “Lazy loading” of Images, taking into account the revised “Active Plugins List” above, the only plugins that have the capabilities to do “Lazy loading” of Images are “W3 Total cache” and “Autoptimize” and like I said before, these have been disabled since many months and are no more used. For its part, Hummingbird plugin does not have this option yet and despite this function is missing, this plugin is disabled for the ” https://sylver-tech.com/test-01/ ” site.

Finally, as far as I’m concerned, I really can’t see any plugin that can do some sort of “lazy loading” of images.

Hope this will fulfill your request.

Hello,

First of all, I should say that the Plugins List generated by the “Support” tab in your Settings page is very misleading because it is labeled “Active Plugins:” when it is a list of “ALL Plugins“, Active as well as INActive!

Yes your right that is misleading. I’ll see if we can split off a list of inactive/active plugins in a future version update.

Don’t focus too much on “W3 Total cache” !

Ok – keep in mind my visibility is limited and I have to methodically rule out potential issues in order to help you out.

Quick question – is this a WordPress multisite?

Finally, as far as I’m concerned, I really can’t see any plugin that can do some sort of “lazy loading” of images.

Hope this will fulfill your request.

Wordpress 5.5 builds this into the system , FYI, from what I understand. There are plugins that inject libraries to do this potentially without you being fully aware. Again, trying to methodically rule things out as best as I can in order to support you.

Please let me know if you are using multisite.

Oh also can you please paste the entire contents of your .htaccess file in the root folder but also if there is other htaccess elsewhere (i.e. wp-content, uploads, etc)

@shift8

Please dont ask for site data dumps, they can contain private or otherwise sensitive info. It is almost as bad as asking for admin access, its bad stuff

@fierevere

Yup – got it.

This issue is tricky and I feel with the level of information available in the format of this forum is not enough to get to the bottom of the problem. The user can email us directly at [email protected] and we can try to troubleshoot further.

Thanks

Please let me know if you are using multisite.

YES, this is a Sub-Directories Multisite with https://sylver-tech.com/ as main site, https://sylver-tech.com/fr/ (French version site) and lately https://sylver-tech.com/test-01/ for the purpose of troubleshooting this problem.

The user can email us directly at [email protected] and we can try to troubleshoot further.

I knew from the get go that it would not be ideal to troubleshoot this problem through this platform (WordPress Support Forum). That’s why I tried to contact you through your [email protected] address with no success and this with a company ([email protected]) email address as well as with a GMail account address. In both cases, your server responded with this message:
“Your email to group [email protected] was rejected due to spam classification”.
This seems to be a frequent problem with Google Apps Group email…

So, unless you can solve this email problem or give me another email address to reach you, I’m stuck!

Hello,

YES, this is a Sub-Directories Multisite with https://sylver-tech.com/ as main site, https://sylver-tech.com/fr/ (French version site) and lately https://sylver-tech.com/test-01/ for the purpose of troubleshooting this problem.

Actually we are aware of some issues potentially with multisite. I want to do some internal tests on our end with multisite and maybe I can try to replicate your problem. This is long overdue as there are a few other posts with other issues with multisite (not related to yours, mind you).

So, unless you can solve this email problem or give me another email address to reach you, I’m stuck!

Ah thats too bad! All our internal business domain mail goes through google mail unfortunately. Let me spend some time troubleshooting multisite and if I can replicate your issue this way, then we can quickly roll out a plugin update to address (if it is indeed the source of the problem obviously).

I appreciate that you’ve been very patient throughout this and rest assured I’ll try my best to get to the bottom of this. If it indeed is something that we need to patch, your help in this issue will be invaluable to the other (thousands) of users for this plugin.

Thanks and I’ll update here after running through some tests.

Hello Shift8,

Do you have something new regarding our problem ?

Hello,

So far I conducted some tests by implementing a multisite with our plugin and have not been able to reproduce the issue.

The next step is to continue with the multisite tests insofar as replicating the installed plugins with the hope that perhaps that combination of edge case conditions will reproduce the problem. The key obviously is to replicate the issue in order to identify what , if anything, should be fixed.

Thanks for your patience!