SylverTECH

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 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.

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…