nirvanagold

Just to say this is no longer an issue for me with latest version of the plugin. I’m not sure why, but I’ve been able to re-enable it!

@alisonn I don’t know if you use any SEO plugin, but I’ve just been configuring The SEO Framework. It produces config options at the bottom of each page (in edit mode) and among these is the option to exclude the page from site search results. This seems to be working fine, so I’ve uninstalled Search Exclude. (With The SEO Framework you can tweak titles and descriptions, exclude pages from search engines, and also redirect pages, so I’ve been able to deactivate the Redirection plugin too.)

Likewise – same issue and stacktrace. The plugin was configured and all looking good, but I discovered this issue after deactivating Complianz then activating it again (that’s when it triggered).

I had deactivated the plugin because I was noticing that after any plugin update or install, WP said it had failed, even though the plugin would actually install. I suspect those warnings were related to this issue, as they are not happening now with Complianz deactivated. (I disabled all plugins and re-enabled, one by one, testing.)

I note this plugin is “not tested with version 6.7 of WordPress”. I’ll deactivate it and wait until there is a fix for the above.

Yes, I’ve seen the same thing – blank Jetpack Settings page. When Search Exclude is enabled it also causes messages such as this at the top of pages in Edit mode:

The “jetpack-publicize” plugin has encountered an error and cannot be rendered.

Many thanks for your full reply.

I’m not sure if the root of the problem is not using an SSL certificate, as surely the preloading functionality should respect the fact I’m not, and always load assets over the specified HTTP protocol (we’re talking about local, minified and merged CSS and JSS which is just sometimes being wrongly loaded over HTTPS). However, I agree it is much better to have an SSL certificate, and that would circumvent the issue. Unfortunately my current host doesn’t accept Let’s Encrypt certs (!), however we will still get another one anyway, as it is worth it for various reasons including this.

Re. the second point, thanks. I had seen these settings but thought that using them might have the negative effect of opting those files out of processing completely. I’ve now tested both, and in both cases the child styles are still overridden by the parent styles:

In case 1 (excluding), the link tag for the excluded child CSS is placed before the link tag for the (minified) parent CSS, thus it is still overridden. In case 2 (loading asynchronously), the script tag for the deferred child CSS is placed before the link tag for the (minified) parent CSS, which seems to matter: even though that child CSS file loads after the parent CSS, it is still overridden.

So, I tried instead placing the path to the parent theme CSS in these boxes. In case 1 (excluding), the link tag for the excluded parent CSS is placed after the style tag for the (minified) child CSS, thus the child CSS is still overridden. In case 2 (loading asynchronously), the script tag for the deferred parent CSS is placed before the style tag for the (minified) child CSS – and this works, even though the parent CSS file loads after the minified CSS file.

Although I think there are still underlying issues here, you can mark this as resolved, if you like, as we can get around them, at the cost of 1) needing an SSL cert and 2) not processing the parent CSS file, or not inlining CSS at all (I will probably stick with the latter…).