Brian Alexander

Hi, @andrewhoyer:

Thank you for reporting this display bug.

This issue has been tracked previously with the following ticket, with planned inclusion in WordPress 6.0:

https://core.trac.ww.wp.xz.cn/ticket/54219

Hi, @nehaahmed:

It sounds like you’re on the right track by inquiring with specific plugin authors for each plugin. They will be able to address questions related to plugin functionality or errors they may introduce.

In addition to suggestions on how to resolve these errors, I was wondering if you could provide me some suggestions regarding the plugins I have installed. I get reports about the low load times of my website, 5xx error and problems with css and js files not being minified.

Because there are so many plugins in play here, it may be easier to test each plugin in isolation to confirm it’s working as expected. This is especially true when using plugins that modify or cache files and response data.

A common process is to disable all but the plugin in question to eliminate interference by others. This may be challenging for a production site, so if you can duplicate the site for staging/testing, that should prove helpful.

Once you can test each plugin individually, check that the plugin is doing what it claims, and note anything weird that you could report to the author. You could also enable two plugins at the same to see how they interact with each other.

…it would be very helpful if you could suggest which plugins I should keep to improve the speed and security of our website, and which ones I should get rid of…

This is a tough one, since each site is so unique in its requirements.

As a general rule, however, the fewer requests that are made for your site, the faster it can potentially be. For instance, when the homepage is loaded in Chrome with DevTools open to the “Network” tab, there are around 200 requests made. These requests amount to over 7 MB of data transferred (with a clear cache). Reducing these requests would be a good place to start, possibly with concatenation of JS and CSS files.

Keep in mind that every active plugin possibly brings with it more load requirements. Social media and video player plugins are good examples of this, since they load their own assets. DevTools offers sorting requested files by size and speed, so may reveal additional areas of improvement.

Security is a big topic on its own, so I would suggest starting with this article for more information: https://ww.wp.xz.cn/support/article/hardening-wordpress/.

Also, would you suggest that I install the plugin “Schema – All in one schema rich snippets”?

I can’t make a direct recommendations here, but encourage you to back up WordPress and/or using a staging site before giving plugins a test drive 😉

I hope this helps as you delve deeper into performance!

Hi, @alexclassroom:

The patch to provide i18n context for font styles and weights has been prepared by @audrasjb: https://github.com/WordPress/gutenberg/pull/37939. This update is targeted for backport to 5.9.

Thanks, again, team!

Hi, @gangleri:

I’m glad you’re making some progress!

As for name resolution, you will need to account for BOTH domain variations. It sounds like you have www working, but not the apex domain (non-www).

The domain configured in Network Admin’s “Site Address (URL)” field is your primary domain. This is the inbound domain WordPress will be watching for.

In order for the non-www domain to resolve to the same site, you could implement a redirect rule in your .htaccess file (or corresponding feature in your hosting tools). The idea is to send non-www traffic to your registered subsite’s primary domain. It is typical to use HTTP 301 (“Permanent”) as the redirect type.

In practice (your scenario):

1. Requests to www.example.com will route to the server, and then along to WordPress.
2. Requests to example.com (non-www) will route to the server, and receive an HTTP 301 redirect instruction to www.example.com. Then the request resolves per #1 above.

Make sure to account for for http(s) in the redirects. In order to redirect HTTPS traffic, the requested domain MUST have a corresponding SSL certificate. It could be a certificate that handles both domain variations, or two separate certificates.

Later on, if you decide to set your primary domain as the non-www apex domain, then just reverse the logic above: set the apex domain in Network Admin, and redirect www to the apex.

Hi, @pclweb:

Are the front page images in question part of the_content or the_post_thumbnail, and also in the loop? This filter specifically targets that context.

Hi, @gangleri:

Please verify with your web host that they do, in fact, support Multisite. They may not support the technical requirements needed, especially as related to domain mapping.

Once confirmed that they support Multisite, then these articles have information that may be of help:

Some good sanity checks:

Debugging a WordPress Network

Ensure that the network has been enabled correctly:

Create A Network

Admin topics, including .htaccess and mod_rewrite:

Multisite Network Administration