Bricks frontend layout error on multisite?

Hi all, I’m having some difficulties with a Bricks/Automatic CSS multisite. I’ve searched for a solution online (and in the Bricks forum) but haven’t found any reference to a similar situation.

On the main domain avo-dev.co.za the content appears the same on the frontend as in the backend.

However, on the network site a1.avo-dev.co.za the same doesn’t apply. The backend settings (gap and flex direction) are completely ignored on the frontend.

Unfortunately, as a first-time user, I’m only allowed to add one image file here.

In the correct version the following CSS is applied to the blocks for the 2 sets of buttons:
#brxe-lfquqc {
flex-direction: row;
column-gap: var(–content-gap);
justify-content: center;
}

#brxe-xvjitv {
flex-direction: row;
justify-content: center;
column-gap: 3rem;
}

In the faulty version, the only CSS applied to the blocks are:
.brxe-block {
align-items: flex-start;
display: flex;
flex-direction: column;
width: 100%;
}

I’ve racked my brain, cleared the cache and re-installed the WordPress setup numerous times but I keep getting the same error.

Thanks in advance for any assistance.

Hi @Travis_H,

Welcome to the forum :slight_smile:

I’ve noticed that although your site is served over HTTPS, the requests for the stylesheets are being made over HTTP. This mismatch is causing them to be blocked by the browser due to Content Security Policy (CSP) rules, which are designed to enhance security by only allowing content to be loaded from certain sources. When your site is HTTPS but tries to load HTTP resources, CSP sees this as a potential security risk and blocks those requests.

Here’s what you could try:

  • Verify WordPress URL Settings: Check that the WordPress Address (URL) and Site Address (URL) in your WordPress settings are set to use “https.” This discrepancy could cause your site to request HTTP resources inadvertently.
  • Flush Rewrite Rules: After ensuring your WordPress settings are correct, go to Settings > Permalinks and click ‘Save Changes’ to flush the rewrite rules.

If adjusting these settings doesn’t resolve the issue, it’s a good idea to get in touch with your hosting provider. They can offer more specific guidance on CSP settings and ensure your server configuration is aligned with HTTPS protocols.

1 Like

Update: This problem only occurs when I set the multisite to use subdomains. Everything works fine when using sub-directories.

When set to use subdomains, I get the following Bricks error in the back-end:
“Bricks: Please update your WordPress URLs under Settings > General to use https:// instead of http:// for optimal performance & functionality. Valid SSL certificate required.”

Possibly a bug since I do have a valid SSL certificate and everything is set to https://. I’ll log a bug report.

Was this resolved? I’m having the same issue.

Same issue. What is the solution for multisite on subdomain?

That fixes it.

Specifically… this answer:

Someone from the German wordpress.org site helped me out with a link form Stack Exchange. So in case someone had the same issue, here is a possible solution that helped me out. That´s his words regarding to this link: multisite - Multi-site: Change the URL of main site to HTTPS - WordPress Development Stack Exchange

"Workaround:

1.) Make a backup of the database. No backup, no pity.

2.) In wp-config.php, comment out the code block for multisite with the prefix // in front of each line (do not delete).

Analogous:

// define ('WP_ALLOW_MULTISITE', true);
// define ('MULTISITE', true);
// define ('SUBDOMAIN_INSTALL', true);
// $ base = '/';
// define ('DOMAIN_CURRENT_SITE', 'example.com');
// define ('PATH_CURRENT_SITE', '/');
// define ('SITE_ID_CURRENT_SITE', 1);
// define ('BLOG_ID_CURRENT_SITE', 1);

3.) Login again and change the URL to https://example.com (with your domain) under Settings > General

4.) In the wp-config.php delete in the code block the comment characters // for multisite.

Analogous:

define ('WP_ALLOW_MULTISITE', true);
define ('MULTISITE', true);
define ('SUBDOMAIN_INSTALL', true);
$ base = '/';
define ('DOMAIN_CURRENT_SITE', 'example.com');
define ('PATH_CURRENT_SITE', '/');
define ('SITE_ID_CURRENT_SITE', 1);
define ('BLOG_ID_CURRENT_SITE', 1);

5.) Carry on as if nothing had happened."

He said that it seems that WordPress didn´t consider that the main page / parent page would change in any way. So it is the easiest way to return with the previous steps to a “normal site”, change the urls and then “activate” Multisite again.

Hope it helps! See ya!

1 Like

For anyone else running into this in the future, all I had to do was to fix my Network Site urls under Network Admin > Sites and ensure that every sub-site’s mapped domain started with https://. For some reason it looks like Wordpress, by default, sets the protocol on new sub-site creation to http: when using sub-domain setup.