Notice: This thread is over two years old; the information may be outdated. Please consider creating a new thread if you require free support. If you have an active SiteOrigin Premium license, you can email our premium support desk at [email protected].
I’m using the standalone Widget Visibility plugin, and when Page Builder and Widget Visibility are both active, it takes 20 seconds to load the post/page editor. I noticed in the changelog there was an update way back in April to fix compatibility with the version of Widget Visibility in Jetpack, is there something in the standalone one that got missed perhaps?
Hi Shane,
Could you please provide a link to the relevant plugin? The Jetpack Widget Visibility and the plugin you’re using are unlikely to be affected by the same issue due to the not being directly related. Regardless, the Jetpack Visibility issue didn’t cause extra load and instead just didn’t work.
If possible, can you try disabling all non-SiteOrigin plugins and see if this fixes the issue? You’ll need to clear all your caches after disabling your plugins.
If it does fix the issue, then try re-enabling your plugins one by one until the issue comes back. This procedure will help diagnose which plugin is causing the issue.
Once we know that, we’ll be able to look at what might be causing the conflict and either solve the problem or help you find an alternative plugin.
If you aren’t using a SiteOrigin theme, then you can also try temporarily switching to one of the default WordPress themes to see if the issue is theme related.
The plugin I’m using is this one: https://wordpress.org/plugins/widget-visibility/
I’ve done quite a bit of testing, and the only way the conflict appears is when Page Builder, and Widget Visibility are both active (using the twenty-fifteen theme for testing with NO other plugins, just to be safe). If only one of them is active, there is no problem, the Add New Post loads within 1 or 2 seconds.
There are other areas where the delay is noticeable, but going to Posts->Add New has been the most reliable way of verifying it. The fastest load time for Add New Post was 13 seconds with those two plugins enabled at the same time.
I did a further test on my live site with 30+ other plugins active. With only one of the plugins active (Page Builder OR Widget Visibility), Add New Post loads within 1-2 seconds. When both are active, it skyrockets to about 30 seconds, so additional plugins seem to feed into the issue. But again, when either of those two are inactive, there is absolutely no impact on the load time.
Ok, here’s what the problem is, and I think it may indicate problems on both plugins, but I’ll let you decide what can reasonably be fixed here.
1. Page Builder runs do_action_ref_array( ‘in_widget_form’, … ) in a couple places, potentially when it isn’t necessary. For example, on the Add New Post screen, it fires approximately 15 times. I could be wrong, but I don’t think it is necessary to fire that action at all on the Add New Post screen (at least the stock WP does NOT run that action ever on Add New Post).
2. Widget Visibility hooks onto that action each time, and attempts to add it’s visibility controls to the “widget”
Normally, that is no problem on your average site. Widget visibility adds controls for each page, category, tag, archive, and author.
If the query for any of these is too large, that’s what bogs things down. In my case, it is the authors query, as it finds 5,000+ users (I’m going to ask the Widget Visibility author to fix his query too), and parsing that 15 times takes a little while.
So what can SiteOrigin do about it? Please make sure you only run the do_action_ref_array() function for ‘in_widget_form’ when it is necessary. Perhaps you already do, but please make sure, as 15 times on the Add New Post screen is a bit odd. This also seems to carry over to the Page editor, and any other place in the dashboard where there are “widgets” of any nature. It’s very painful trying to manage a site when it takes 30 seconds to edit a page, 30 seconds more to save the page, etc.
Thank you so much for your time!
Hi Shane,
Thank you for the information.
We actually use do_action_ref_array to allow widgets to load their data and output their assets and such. It’s not something that can be avoided as if we don’t do this it’s quite likely large incompatibilities would be introduced. In other words, this is intended.
With that said, the widget visibility plugin running as a result of us using this shouldn’t affect performance so negatively so it’s quite likely something is going on with their code. My validation in this is the Jetpack Widget Visibility module which (technically) does exactly the same thing but doesn’t suffer from the same issue.
Yeah, it looks like Jetpack calls the authors dynamically (via AJAX), but it still runs the same expensive query as Widget Visibility (not your problem though, of course).