alexgso

Hi,

It’s great to hear you were able to get it working. ??
Due to how Create handles the theme container a rather complicated override is required for it to work as desired so the CSS in your last reply is effectively the best way of doing this.

Kind regards,
Alex

Hi twowithink,

I’ve had a look at Create and I’ve come up with an updated snippet. Please try replacing the previously provided PHP with the following PHP:

add_filter( 'siteorigin_panels_theme_container_width', function( $container ) {
  return '1200px';
} );

add_filter( 'siteorigin_panels_theme_container_selector', function( $selector ) {
  return '.siteorigin-panels .body-wrap';
} );

Some additional CSS on top of this will also be required due to how Create sets its container. Please add the following CSS to Appearance > Customize, Additional CSS:

.siteorigin-panels.siteorigin-panels-css-container .body-wrap {
	max-width: none !important;
}

As for WP Rocket, please also try excluding /wp-content/plugins/so-widgets-bundle/js/jquery.cycle.min.js

Kind regards,
Alex

Hi Sparen,

It’s great to hear that helped! The update we just released included the changes in the provided beta to allow for this so you can safely update to the latest version.

1. A CORS error is a sign that your website isn’t setup to allow for requests across domains (www and non-www is considered cross-domain). I recommend reaching out to your hosting provider about this as it’s not a Page Builder issue.

2. This is occurring because of 1.

3. This is unrelated to Page Builder. I recommend ensuring re-adding the missing image on your website or removing references to it.

I’ve marked this thread as resolved as the original issue has been resolved and has now been released.

Kind regards,
Alex

Hi jahrat,

That’s great to hear! ??
I’ve let the rest of the team know about this and this will be in an upcoming Vantage Update.

Kind regards,
Alex

Hi sparen,

I’ve prepared a patched version of Page Builder that includes the fix I mentioned. This will allow you to test it and resolve this issue prior to the next Page Builder update. You can download it by clicking here.

Before proceeding, do a backup.

Navigate to Plugins > Installed Plugins and deactivate Page Builder by SiteOrigin. Delete it and then scroll to the top of the page and click Add New, Upload Plugin. Upload siteorigin-panels.2.20.1-beta.zip and when prompted activate it.

Kind regards,
Alex

Hi Sparen,

Thank you for the additional information. With your help, I’ve identified a situation where Page Builder won’t allow for the non-standard directory name and submitted a patch to account for this situation. This change should be available in an upcoming release.

Kind regards,
Alex

Hi jahrat,

Thanks for reaching out. ??
I’m having trouble replicating this so I suspect these errors are related to a plugin creating a custom post type on your website using a method we don’t expect. I’ve come up with a potential fix for this that may work but you’ll need to confirm if it does. You can download patched version of Vantage that contains this fix by clicking here.

Before proceeding, do a backup.

Navigate to Appearance > Themes and change to a different theme, and then delete Vantage. Click Add New, Upload Theme and upload vantage.1.20.5-beta.zip. Are these warnings still being logged?

Kind regards,
Alex

Hi Sparen,

I’ve run a few tests and I was able to rename the siteorigin-panels directory to just builder while using 2.22.0 and have everything work as expected (Page Builder appeared and worked, no 404’s or references to the siteorigin-panels directory). We haven’t modified how the assets listed are loaded. They’re set to be dynamically loaded based on the directory loading the files rather than siteorigin-panels.

How are you renaming the siteorigin-panels directory? Are you renaming it directly (using a file manager or FTP), or with the help of a third-party plugin?

I recommend reinstalling the plugin to see if that helps. You can do this by navigating 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 and search for Page Builder by SiteOrigin. Once found, install it. Rename the Page Builder directory as you normally would and then activate Page Builder.

Kind regards,
Alex

Hi Arutha,

That’s great to hear! ??

Yes, the provided changes will be in an upcoming SiteOrigin Widgets Bundle update. When the update is released it’ll update like normal so no additional steps are required on your end.

Can you explain what you did?
I noticed that the URL you’re getting is the Widgets Block preview URL so I set the widget to override those. In the second patch, I set the Blog widget to be excluded from the SiteOrigin Widgets Block cache.

In this case, what is better, to activate it on the network or to activate it in each site separately?
There’s no better in this situation so what you use really comes down to personal preference.

Hi Arutha,

Thanks for trying and for the additional information. Hm. I’ve run a few tests and I feel the best way forward is to simply exclude the Blog widget from the Widgets Cache. This combined with the previous change should prevent this issue from occurring without any adjustments required. You can download a patched version of the SiteOrigin Widgets Bundle to try by clicking here.

Before proceeding, do a backup.

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

Kind regards,
Alex

Hi Arutha,

Thank you for trying the provided beta. During testing, did you make any direct changes to the SiteOrigin Widgets Block that was used to add the Blog widget? If not, try making any changes to the widget to see if that helps. Alternatively, try adding a new SiteOrigin Widgets Block and setting that up to display the Blog widget. The SiteOrigin Widgets Form contains some caching so it’s possible you’re still seeing the older version of the Block.

Kind regards,
Alex

Hi,

We display widgets by using either the Widget Class or Hash rather than the widget id. We do this due to how WordPress stores widgets in the WP_Widget_Factory $widgets array which is by class (or hash) instead of id.

We provide the siteorigin_panels_widget_object filter to override the widget class with what it actually is. In your case, you can tell Page Builder about the updated Widget Class by using the following PHP (some adjustments will be required for it to be useable in your codebase):

add_filter( 'siteorigin_panels_widget_object', function( $the_widget, $widget_class ) {
	if ( $widget_class == 'Recent_Posts_Widget_Extended' ) {
		global $wp_widget_factory;
		if ( isset( $wp_widget_factory->widgets['RPWE_Widget'] ) ) {
			$the_widget = $wp_widget_factory->widgets['RPWE_Widget'];
		}
	}

	return $the_widget;
}, 10, 2 );

I’ve had a look at your plugin and I wasn’t able to find a compatibility area so I opted not to submit a PR for this. If you would prefer I did that, let me know and I’ll submit one to your repo. ??

Kind regards,
Alex

Hi Oliver,

I’ve identified what’s going on and come up with a fix which can be seen here. This fix will be included in the next update.

I recommend changing to the modern layout renderer. You can do this by navigating to Settings > Page Builder, open Layouts tab and set Use Legacy Layout Engine to Never (or Detect).

Kind regards,
Alex

Hi doffine,

Thank you for clarifying. There are a few situations where the SiteOrigin page Builder layout can be rendered twice and that can result in data being submitted twice. There aren’t any known instances related to any widget directly doing this, but other plugins have ben known to cause this type of issue. For example, the Yoast SEO automatic Open Graph tags used to process the page twice (we accounted for this in an update) and that resulted in this type of issue. I recommend running a plugin conflict test to rule out a third party plugin causing this issue. You can do this by disabling all non-SiteOrigin plugins except for Woody code snippets plugin and seeing if the issue occurs.

Kind regards,
Alex

Hi Doffine,

Thank you for the additional information. I’ve run a few tests and I can’t replicate this issue. Based on the provided information, you’re adding the shortcode using a SiteOrigin Editor widget to your footer widget area and that’s something I’m not able to directly test – I can test a fairly certain footer widget area but it’s unlikely to be exactly the same as the theme you’re using. At this stage, it’s quite possible this issue could be as a result of how the widget area is handled rather than directly an issue with the widget itself.

If possible, I recommend trying the shortcode using the SiteOrigin Widgets Block, or a different theme (ideally a non-custom theme) footer widget area. I totally get if this isn’t something you would like to do. Unfortunately, for these sorts of issues we need to be able to replicate it to be able to resolve them.

Kind regards,
Alex