alexgso

Hi,

It’s great to hear that helped! ??
The provided changes were included in the 2.27.1. Please update Page Builder by SiteOrigin, and this issue will be resolved on the rest of your sites.

We have no plans to drop the Classic Editor at this time.

Kind regards,
Alex

Hi,

Sorry for the delay. I’ve come up with a fix for this issue and you can download a patched version of SiteOrigin Page Builder by clicking here.

Before proceeding, do a backup.

Navigate to Plugins > Installed Plugins and deactivate Page Builder by SiteOrigin and then delete it. Scroll to the top of the page and click Add New, Upload New. Upload siteorigin-panels.2.27.1-beta.zip. When prompted, activate it. You should now be able to access the SiteOrigin Layouts Block without issue now.
????
Kind regards,
Alex???

Hi,

It’s great to hear that helped! Please feel free to post a new thread if anything else comes up.

Kind regards,
Alex

Hi,

You can disable the Installer by default by filtering siteorigin_add_installer. For example, the following PHP will change the default state to disabled:

add_filter( 'siteorigin_add_installer', function() {
	if( get_option( 'siteorigin_installer' ) === false ) {
		return false;
	}
}, 11 );

If you would like to add this script to your multisite but don’t have a method of adding PHP, I’ve prepared a plugin that you can install that adds the above code. You can download that plugin by clicking here. Once downloaded, open your Multisite plugin page and click Add New, Upload Plugin and upload siteorigin-installer-disable-by-default.zip.

Kind regards,
Alex

Hi J?rn,

Thanks for reaching out and for your report. I’ve made the required changes to restrict the setup based on DISALLOW_FILE_MODS. This change will be included in a future version.

Kind regards,
Alex

Hi Alexander,

Thank you for your feedback. We’ll look to allow the stylesheet to be optionally output to the head or end of the body in a future update.

Kind regards,
Alex

Hi Waqas,

It’s great to hear that helped! ??
This issue was resolved in Page Builder 2.26.1.

Kind regards,
Alex

Hi Shaun,

It’s great to hear you were able to find a workaround.
This issue was resolved in Page Builder 2.26.1.

Kind regards,
Alex

Hi Smash,

Thanks for reaching out.

Thanks for reaching out. I’ve identified what’s going on and come up with a fix. We’ll be releasing an update shortly that resolves this issue. I’ve prepared a build for you to use now so you can avoid this issue now. That can be downloaded by clicking here.

Before proceeding, do a backup.

Navigate to Plugins > Installed Plugins and deactivate SiteOrigin Widgets Bundle and then when prompted, delete it. Scroll to the top of the page and click Add New, Upload Plugin and upload so-widgets-bundle.1.55.1-beta.zip.

Kind regards,
Alex

Hi Shaun,

Thanks for reaching out. I’ve taken a closer look at the changes in the most recent update and have identified a fix for the issue you’re facing. This issue will be fixed in an upcoming release. In the meantime, I’ve created a beta release for you to use until then. You can download this version by clicking here.

Before proceeding, do a backup.

Navigate to Plugins > Installed Plugins and deactivate Page Builder by SiteOrigin, and then delete it. Scroll to the top of the page and click Add New, Upload Plugin and upload siteorigin-panels.2.26.1-beta.zip. When prompted, activate the plugin.

Kind regards,
Alex

Hi Waqas,

Thanks for reaching out. I’ve taken a closer look at the highlighted CSS, run some tests, and come up with a different way of handling the Background Image Opacity setting to avoid the need for this change. This CSS will be removed in an upcoming release. In the meantime, I’ve created a beta release for you to use until then. You can download this version by clicking here.

Before proceeding, do a backup.

Navigate to Plugins > Installed Plugins and deactivate Page Builder by SiteOrigin, and then delete it. Scroll to the top of the page and click Add New, Upload Plugin and upload siteorigin-panels.2.26.1-beta.zip. When prompted, activate the plugin.

Kind regards,
Alex

Hi Frisco,

Thanks for reaching out. In older updates, there was previously a small chance for CSS to be output directly on the page rather than using an external CSS file and I suspect SiteOrigin CSS was unintentionally doing that. That would explain why it’s not working like it previously did.

That difference would be intentional by MonsterInsights Premium as they must be setting up scripts to defer until after the page loads. This is a popular performance technique but it can result in display differences like you’re getting. I can’t seem to find a method of adjusting this from their documentation so consider checking with them as it would be useful for you with other plugins.

You can tell SiteOrigin CSS to always output its CSS directly to the page (how it used to work for you) by adding some PHP to your website. If you don’t have a method of adding PHP, please install Code Snippets.

add_filter( 'siteorigin_css_enqueue_css', '__return_false' );

Click Save Changes & Activate.

If you do have PHP, please add the above PHP using that method.

Kind regards,
Alex

• This reply was modified 1 year, 2 months ago by alexgso. Reason: Added snippet

Hi,

Thanks for reaching out and for your kind words.

1. We use a third party to cover linting (basically code analysis to highlight properties). Unfortunately, most of the viable options for this are lagging behind the CSS spec. We’re watching this space and as this changes, we’ll introduce this and support more modern CSS.

I’ve logged internal feature requests for everything else requested. Thank you for outing your reasoning.

Kind regards,
Alex

Hi,

Thank you for the report. I’ve run a few tests and come up with a fix to prevent this. This fix will be included in a future update.

Kind regards,
Alex

Hi,

So you’re saying that the server doesn’t block the classic widgets plugin unless your plugin and SmartSlider are also active at the same time

I’m not directly saying that, no. The issue you’re facing likely doesn’t relate to any one of the specific plugins you mentioned and instead relates to a hosting provider specific rule for mod_security (or an equivalent).

Rules are effectively a special pattern that the server checks each request for and if it matches it’ll block the request. It’s very easy for a pattern to be a little too general and block things incorrectly and that’s called a false positive. False positives are unfortunately very common so your hosting provider’s technical support will be aware of this type of issue and will be able to help you with this issue. Fixing this issue won’t just help you, it’ll help their other users also so they have every reason to help – we would happily fix this issue if it was on our end for the same reason.

Kind regards,
Alex