alexgso

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

Hi Alex,

Thank you for the report. These will be corrected in an upcoming update.

Kind regards,
Alex

Hi Alex,

Thank you for the report. These will be corrected in the next update.

Kind regards,
Alex

Hi John,

The type of issue you’re facing is a common sign of the server blocking the request. I recommend reaching out to your hosting provider about this and asking if mod_security (or an equivalent) is installed, and if so, are you getting blocked by it.

Kind regards,
Alex

Hi,

Mod_Security is an application firewall. Data is passed through the firewall and the firewall does some checks on everything passed through using a set of rules and it checks for any potential issues. These rules can be quite specific but some of them can be quite general and that’s where false positives can occur. A false positive is something being flagged incorrectly due to an issue with the rule, not the flagged data.

These rules aren’t perfect and mistakes happen. For example, a few years ago we had some reports of pages being blocked for a few people. The cause? The users had added emojis to the page and a rule was incorrectly flagging them. We were able to resolve that issue by getting the rule corrected.

Please reach out to your hosting provider asking them for more information about the block. This will allow us to investigate this issue further. Most hosting providers use an off the shelf solution for rules (which is ideal for a number of reasons) so they should hopefully be able to provide us with a rule id.

Kind regards,
Alex

Hi,

The provided snippet will override the custom value if it’s set to 9999 and clear it. This will prevent this issue on the frontend and clear it when editing the widget. That would in theory speed up removing it as you can simply save the page.

Kind regards,
Alex

Hi,

That’s odd. I just retested the provided snippet and it’s working for me. Hm. Can you please try adding the code on this page instead? That’ll remove any chance of formatting causing issues.

Kind regards,
Alex

Hi usainds,

I’ve run a few tests and I’ve come up with a snippet that’ll allow you to avoid this issue with the latest version. Please install Code Snippets and then navigate to Snippets > Add New and add the following PHP:

add_filter( 'siteorigin_widgets_instance_sow-image', function( $instance, $widget ) {
	if ( ! empty( $instance['size_width'] ) && $instance['size_width'] === 9999 ) {
		unset( $instance['size_width'] );
	}

	if ( ! empty( $instance['size_height'] ) && $instance['size_height'] === 9999 ) {
		unset( $instance['size_height'] );
	}

	if ( ! empty( $instance['size_external_width'] ) && $instance['size_external_width'] === 9999 ) {
		unset( $instance['size_external_width'] );
	}

	if ( ! empty( $instance['size_external_height'] ) && $instance['size_external_height'] === 9999 ) {
		unset( $instance['size_external_height'] );
	}

	return $instance;
}, 10, 2 );

When prompted, activate the snippet. How does that look?

I have always set one of the custom values to 9999 which automatically sets that value to the largest size it needs to be while still being proportional to the other value that is set.

This happens automatically with all of our widgets so I recommend against doing this.

Kind regards,
Alex

Hi,

Can you please elaborate on what you’re seeing that suggests you’re experiencing major CPU usage? Are you seeing an alert or a notice? If so, can you please provide me with what you’re seeing? These alerts/notices can sometimes provide more insight into what’s going on.

Do you get the same performance results if you temporarily disable all non-SiteOrigin plugins and switch to a default theme? Page Builder allows you to add non-SiteOrigin widgets and shortcodes and if something isn’t performing well it can sometimes appear as though Page Builder isn’t, but it’s actually just something being added with Page Builder. This test will allow you to confirm if it’s specifically Page Builder, or something else being added using Page Builder.

If it performs better, try re-enabling each plugin you deactivated one by one until this issue returns. If it doesn’t, try reactivating your original theme.

Is it possible that these auto-saves are piling up and causing the site to overload and lag?

This is unlikely and would be indicative of other issues related to the server itself. Regardless, Page Builder uses the standard WordPress auto-saving and revision system so any plugin that allows you to manage those will also cover Page Builder. This article covers a few options you could use to manage your revisions.

Could you look at the screenshot in this Pasteboard link and let me know if it tells you anything about what’s happening?

The contents of your screenshot are expected. Your page contains widgets that require CSS to be generated and served to the user. Rather than generating this each and every page load we generate it once by caching the generated CSS and then serve that CSS each subsequent visit. This improves performance overall and it won’t directly impact performance when saving the page as it happens when a user views the page, not when the page is saved.

Kind regards,
Alex

Hi,

That’s great to hear! ??
I’ve had a look at your video and it appears the timeout is set to 29 seconds (29000). The video length is 27 seconds so there will be a slight gap before the next slide shows. To completely prevent it you should set the slide Timeout to 27000. This can be done in the the widgets Controls section.

Kind regards,
Alex

Hi Vladimir,

Thanks for reaching out. I’ve run a few tests and I’m unable to replicate the described issue. I’ve come up with a fix here and this fix will be included in a future SiteOrigin Widgets Bundle update.

Kind regards,
Alex

Hi,

Thanks for trying. I don’t blame them for not wanting to supply the rule. It does however make identifying what is going on quite tricky. I’ll run some tests and try to identify what could be causing this but I suspect this may not be something we can reliably resolve without knowing specifics (it’s quite a gap in knowledge and filling it is going to be difficult).

Kind regards,
Alex

Hi,

Thanks. That appears to be a response to why the rule was added rather than the rule itself. Can you please try requesting the rule again directly again? Regardless, I’ll run some tests on our end to see if I can spot what they may be flagging.

Kind regards,
Alex

Hi,

This is a tricky one. It’s not immediately clear why this rule is being triggered. This is likely a bit of a stretch, but would it be possible for you to request the full rule that’s being flagged? This is different to the log and it will provide more insight into why it’s being flagged as we can see the specific pattern they’re looking for. This looks to be a custom rule so it’s possible they may decide not to share it and that’s understandable.

Kind regards,
Alex

Hi Shaun,

Thanks for reaching out. Images added using the SiteOrigin Image widget are designed to pick up on the images alt text if it’s set in the Media Library and the Alt Text setting isn’t set.

I just ran a test and it’s working as expected for me. Hm. Can you please link me to a page on your website where I can inspect a SiteOrigin Image widget and the same image added using a SiteOrigin Editor widget? This will allow me to compare the differences on your website and hopefully give me a better idea of why it’s not working as expected.

Kind regards,
Alex