wpwebdevj

It’s not causing any indexing issues, just wondering if it could theoretically. Thanks for the explanation.

Changing

.site-content .content-area, .right-sidebar #right-sidebar.sidebar  {
     width: 100%;
 }

to

.container .site-content .content-area, .right-sidebar #right-sidebar.sidebar  {
     width: 100%;
 }

seems to work.

I guess .container .site-content .content-area is a more exact match than .site-content .content-area so it’s applied even though the inline CSS appears last.

Thanks again for all your help and quick responses.

Same problem as before, the inline rule is still taking precedence when the CSS files are combined.

With Autotomize completely disabled, I noticed that my child theme css file is loaded after the html inline CSS. Most of the CSS files are loaded before the inline styles except for 2 files which are loaded after. The child theme css and another CSS file generated by the customizer are loaded after.

When CSS is combined, the combined file is called before the inline CSS.

Does this explain why the inline rule takes precedence when the CSS is combined?

I think there is something not quite right with some of the NGINX rules (the basic 4 with default settings).

location ~* \.(xml|xsl)$ { add_header Cache-Control "no-cache, no-store, must-revalidate, max-age=0"; expires -1; }
location /robots.txt { add_header Cache-Control "no-cache, no-store, must-revalidate, max-age=0"; expires -1; }
location /wp-cron.php { add_header Cache-Control "no-cache, no-store, must-revalidate, max-age=0"; expires -1; }
location = /wp-content/wp-cloudflare-super-page-cache/cachetest.anon4.com/debug.log { access_log off; deny all; }

The location /robots.txt block never matches because I already have another location block in my config.

location = /robots.txt {
        try_files $uri $uri/ /index.php$is_args$args;
}

There is no actual robots.txt file in the webroot, it is created by WordPress /index.php. So even if I add the header in the above block, it won’t get processed because it gets forwarded to index.php location block. However, I don’t think it’s necessary because this plugin is already adding the necessary header when page caching is enabled even without adding this rule.

cache-control: no-store, no-cache, must-revalidate, max-age=0

When page cashing is disabled in this plugin then that header disappears so I’m pretty sure it’s added by the plugin.

The location ~* \.(xml|xsl)$ block causes a 404 on /sitemap.xml because there is no actual file sitemap.xml in the webroot. As with robots.txt, it is generated by WordPress /index.php. As I don’t have a specific location that matches, it relies on matching the default location block.

location / {
        try_files $uri $uri/ /index.php$is_args$args;
}

Unlike with robots.txt, this plugin is not adding the correct header to sitemap.xml. Rather, it is adding the same header as other static files.

cache-control: s-maxage=31536000, max-age=60

The header is not present with page cashing disabled in this plugin.

For sitemap.xsl this plugin doesn’t appear to add any cache-control header. I am getting the below header for sitemap.xsl but it is present whether page caching is enabled in this plugin or not.

cache-control: max-age=1800

I’m not sure where that header is coming from, maybe added by WordPress core or another plugin. I don’t have any rules for xsl in my server config.

I’m not sure if there is a bug in your plugin that is preventing the cache-control header being set for sitemap.xml like it does for robots.txt (without relying on adding custom NGINX rules). If the plugin can add the header for robots.txt without additional NGINX rules, it should be able to do the same for sitemap.xml?

Thanks for your explanation. Good to know that what I am seeing is normal.

I understand what those 4 NGINX rules do, I was just confused about how those 4 rules related to some of the settings of the plugin. I didn’t realize that the list of rules in that link changed after updating settings.

I will also recommend you to enable the Add browser caching rules for static assets option under the Cache Tab inside the plugin settings and once you enable it the plugin will show you a few nginx rules for better static files caching and you can add those rules to your nginx config as well.

When I enable browser caching, I see that you are recommending these cache-control headers for static assets.

location ~* \.(css|js|pdf)$ { add_header Cache-Control "public, must-revalidate, proxy-revalidate, immutable, max-age=2592000, stale-while-revalidate=86400, stale-if-error=604800"; expires 30d; }
location ~* \.(jpg|jpeg|png|gif|ico|eot|swf|svg|webp|avif|ttf|otf|woff|woff2|ogg|mp4|mpeg|avi|mkv|webm|mp3)$ { add_header Cache-Control "public, must-revalidate, proxy-revalidate, immutable, max-age=31536000, stale-while-revalidate=86400, stale-if-error=604800"; expires 365d; }

It appears these rules are not only for browser caching (cache-control: public, …)?

Currently I am using cache-control: max-age=315360000 for all static assets. Why do you recommend only 30d for css and js?

If I want to keep my current browser cache settings, should I still add the “public” part of these rules, as below.

location ~* \.(css|js|pdf)$ { add_header Cache-Control "public, must-revalidate, proxy-revalidate, immutable, max-age=2592000, stale-while-revalidate=86400, stale-if-error=604800";}
location ~* \.(jpg|jpeg|png|gif|ico|eot|swf|svg|webp|avif|ttf|otf|woff|woff2|ogg|mp4|mpeg|avi|mkv|webm|mp3)$ { add_header Cache-Control "public, must-revalidate, proxy-revalidate, immutable, max-age=31536000, stale-while-revalidate=86400, stale-if-error=604800";}

Doesn’t Cloudflare ignore these headers anyway when you are using the cache everything page rule?

Just to clarify, the .site-content .content-area{width:70%;} is the default width set by the theme (content area 70% and sidebar 30%). The CSS that I added into the child theme is supposed to make the width 100% only when the width is below 991px and the right sidebar collapses to the bottom.

The inline CSS .site-content .content-area{width:70%;} is added by the Generate press theme. I don’t understand what you mean by “before the 991px mediaquery, add .site-content .content-area{width:100%;} inside the 991px block and it will probably be OK”.

Yes, after removing the autoptimize_filter_imgopt_lazyload_js_noptimize filter I can see where it’s coming from now. Thanks.

Thanks for the reply. I did some more research and decided to use this plugin’s lazy loading.

Thanks for confirming. Just a quick follow up question. Will changing to a different localized version change anything on the front end of the website such as the format for how dates are displayed? Or does it only apply to the backend?

Yes, but both versions say en-CA.

Wow that was fast!

Thanks for the quick support. I’m loving your theme so far. I think it’s great that you offer options like this (loading Google fonts locally), which require a lot of research and manual coding with other themes. And nice to see that you are actively and quickly fixing bugs.

Ok, thanks. While you are working on a fix, is there a workaround to preload both fonts in the meantime?

Hello,

Thanks for the replies, but I am still getting 2 separate woff2 fonts downloaded, even when disabling the preload option.

The only difference with preload disabled is that both of them are loaded from css instead of 1 loaded from html and 1 loaded from css.

Here is a test site with a fresh install of WordPress and your theme with no plugins or settings changed except for setting the font and the Load Google fonts locally option (preload local fonts is disabled).

https://kadence.anon4.com/

You can see there are 2 separate woff2 font files downloaded when loading the site.

XRXV3I6Li01BKofINeaB.woff2

XRXW3I6Li01BKofAjsOUYevI.woff2

After checking the CSS file that these are loaded from, it appears one is a 700 weight and the other is a 400 weight. The default weights for everything in the typography settings is 700 so I’m not sure if this 400 weight is needed or not?

If both of these are actually required, then shouldn’t they both preload when the preload local fonts setting is on? Instead of only 1 preloading and 1 loading from css?

If possible, I prefer to only load 1 .woff2 file instead of 2.

Wow, thank you so much for the in depth explanation! I always learn a lot in your support forum.

I ended up disabling WordPress from generating all those additional images except for a small thumbnail size and then used the Regenerate Thumbnails plugin to clean everything up (also reduced a lot of html bloat on the front end with less srcset paramaters).

I noticed the images still look fine even when the dimensions are larger than the container width of the site. The browser must be doing some rendering to add the extra colors needed?