Hi,
This is a very similar problem to one that was posted by Callyofficial a few weeks ago in that when I open a widget to edit, the styles menu generally won’t load (I just get a spinning circle). I say ‘generally’ as Callyofficial found, occasionally the menu will load but the text area won’t and very occasionally neither will load. However, I never have an instance where both will load.
I’ve read the thread and tried everything suggested but to no avail, but I might be able to add more to the piece… In my instance, it’s every widget on the page not just the TinyMCE widget e.g. ‘Call to Action’. Also, it only occurs on my hosted site (with Fasthosts), I keep ‘InstantWP’ versions of my site on my computer on which I do the development and these work without a problem.
To get a site from my development machine to my hosted site I use ‘All-in-One-WP-Migration’ to export and then again to import. I have used this technique many times and always been able to edit the hosted site directly after import, this problem has only started in the last few weeks.
I have contacted Fasthosts and they’ve had a look and seen the problem but say that their servers are working without problem. Therefore, I contact you to see if you can throw any light on this?
Thanking you in anticipation, David.
Hi David
Sorry to hear about this problem.
To confirm, you’ve run a plugin conflict test? When you did so, did you deactivate all non-SiteOrigin plugins at once?
Did you test with all non-SiteOrigin plugins deactivated AND a default theme like Twenty Fifteen activated?
Another idea might be to install: https://wordpress.org/plugins/server-ip-memory-usage/. It adds a single line of text to your footer in the WordPress admin. What percentage of memory are you using when all required plugins are activated?
Thanks
Hi,
Yes, I did do the plugin conflict test and with all plugins (other than Site Origin) deactivated and the Twenty Fifteen theme, but the result was exactly the same. I’ve just tried it again to make absolutely sure and still no difference.
I’ve installed the memory usage plugin and opened the home page on both my systems and I get the following footers on each of my systems:
Fasthosts:
Memory: 10.75 of 256 MB (4%) | WP LIMIT: 40 MB | IP 127.0.0.1 | PHP 5.6.16 @64BitOS
Version 4.4
InstantWP:
Memory: 33.61 of 256 MB (13%) | WP LIMIT: 40 MB | IP 127.0.0.1 | PHP 5.4.36 @32BitOS
Version 4.4
Each system contains identical content; the Fasthosts system exhibits the problem and the InstantWP system doesn’t?
Hope this helps.
Thanks, David
Thanks for the feedback.
Both memory limits are low, I doubt it’s related, but you could mail both hosts and ask if they could increase memory to 256m. If you’re comfortable downloading the wp-config.php file from each WordPress root and making an edit then it’s really easy to make this change yourself:
https://codex.wordpress.org/Editing_wp-config.php#Increasing_memory_allocated_to_PHP
Once the above is done, perhaps we could take a look. Details below:
Would it be possible for you to create a temporary admin account for us so we can log in and take a look? You can create the account with the following email address:
[email protected]
Just navigate to UsersAdd New in your WordPress admin. Enter siteorigin for the username and [email protected] for the email address. Make sure you’ve selected Administrator for the role and enabled the Send Password field so we receive the details.
Once we’re finished taking a look, you can delete this account. We’ll let you know when to do that.
This is a private message.
Hi,
Have updated the memory setting and created a login as requested. I can see that you’ve automatically been emailed this in the thread.
…. and I should have said that a good example of non-working widgets is on the ‘home’ page, although other pages with widgets do suffer the same problem.
Thanks
This is a private message.
This is a private message.
Thanks for the big wait. Unfortunately, we haven’t yet found the cause of the problem. I’ve escalated the problem to our developers for review. We’ll report back ASAP. Feel free to follow-up next week if you haven’t heard back. Thanks for your patience.
Hi, just following up, any update on the cause of the problem? Thanks.
So sorry for the delay. We had another case of this. The problem lies with the website host. For security reasons, they’re blocking a certain request that Page Builder is making. Perhaps you could reach out to your hosts and ask if they can do anything about the following 503 error:
Failed to load resource: the server responded with a status of 503 (Service Temporarily Unavailable)
http://www.vallectric.co.uk/wp-admin/admin-ajax.php?_panelsnonce=10872501a8
Thanks for this, I’ve relayed your findings to Fasthosts and will let you know what happens.
Hi,
Having provided Fasthosts with your information they said that they only allow plug-ins to have 60 seconds of execution time by default and that I should check out the following links:
https://help.fasthosts.co.uk/app/answers/detail/a_id/2621/kw/plug%20in
https://help.fasthosts.co.uk/app/answers/detail/a_id/2170/kw/plug%20in/related/1
As per the first link I installed ‘Heartbeat Control’ and set it as stated, but this made no difference. I also ran GTmetrix, but this didn’t tell me anything as it’s all about loading pages not editing them.
I told Fasthosts that nothing has changed and they have now asked me to ask you for system requirement needed by the plug-in so that they can check to see if they are supported. Can you give me these please and I’ll go back to them?
Thanks
David
Hi,
I am having this same problem and my site is hosted by Fasthosts. However I am using the plugin on a different website which is also hosted by Fasthosts but not getting this same problems.
Help would be much appreciated.
Thanks
Josh
Hi Josh
That’s very interesting. We’d love to narrow this down. Can you supply any information on what might be different? Are both sites hosted on shared servers? Any chance you could reach out to your hosts and ask them if there are any differences between the two servers.
To rule it out, you should also run a plugin conflict test on the site that’s having an issue. Details below:
This sounds like it could be a plugin conflict issue. 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.
Hi David
Thanks for your efforts. I’m escalating your question for attention from our developers.
Hi David
I’m going to do some performance testing on the styles request and see if I can spot any bottlenecks. This should be a fairly light weight request, but there might be something in there causing a problem.
Hi,
Fully appreciate that your doing some testing to try to determine the problem, but I did ask earlier if you could provide me with the system requirement for the plug-in to give to Fasthosts so that they can progress investigations from their end. Is this possible? Thanks.
Hi David
I’ve managed to figure out what’s likely causing the issue. There’s a function called filter_input that causes problems with some configurations of PHP. Mostly those using HHVM. We removed the use of filter_input in most places, but it turns out we were still using it in the widget styles request.
The next update of Page Builder will include this change. Hopefully we’ll release this early next week.
https://github.com/siteorigin/siteorigin-panels/commit/382f1054b496763bb26ce56cb4d7e8e437a7b601
So this is likely not being caused by insufficient system resources. Page Builders system requirements aren’t going to be too much different to those of WordPress – https://wordpress.org/about/requirements/ – although we generally recommend 128mb-256mb memory just to make sure you don’t run into any issues.
So for now you could just check with your hosts if they’re using HHVM.
Hi,
Just installed version 2.3.1 of Page Builder and, unfortunately, this has made no difference to behaviour. Do I need to do anything in addition to the update?
I did ask Fasthosts if they were using HHVM and their reply was that “it was not supported in our shared server where you are currently hosted”.
Thanks
This is a private message.
Hi, it’s all been vey quiet for a while now. I’d be grateful if you could let me know if you are, or will be, giving the problem any further consideration. I’ll understand if you’re not, but will be delighted if you are; the problem remains with all the latest versions installed. Thanks.
Updated to version 2.4.8 on release with no change in behaviour, however, just logged on to check for updates and tried to edit pages and everything now loads. So, problem now gone; I can only assume that Fasthosts have updated their configuration as I’m still on 2.4.8. Thanks for your help, although a bit quiet in the latter stages.
Hi, Is there any update on this?
I am still having this issue. I am running pagebuilder on amny sites and I am still having this problem with all apart from one. All sites are hosted with Fasthosts including the one it words on. They are all on shared servers and I get the same response from fasthosts as @DavidAntAll.
You help would be most appreciated.
Thanks
Josh
Hi Josh,
As David’s is not experiencing the issue anymore, it’s possible that the issue with Fasthost itself has resolved itself. Could you contact support to see if their previous answer applies, and if it does, can provide an error log so we can review it? SiteOrigin Page Builder taking 60+ seconds to load is very unusual.
Also, just to clarify, could you send me a screenshot of your plugin list? If you would prefer to keep your plugins list private, select “Private Reply” on the bottom right of the comment box.
Hi Alex,
Here are screen shots of my plugin list and also a shot showing the spinning wheel. This is the same issue that I am having with all five out of six sites which are using pagebuilder.
Thanks
Josh
Hi Kilodesign,
ThemeTrust runs a fork (a version based on our code but not actively developed by us) of SiteOrigin Page Builder so we’re unable to help you due to the version differences. We recommend contacting Theme Trust directly. I’ve heard that Theme Trust has a fix out for this so I would definitely recommend contacting them about this issue.
Hi,
Given the above posts by Kilodesign I Just thought I’d check to see if I was still able to edit pages and the answer is ‘yes’, before and after updating to page builder 2.4.9.
I’ll just throw something else in that may influence the thinking which I didn’t really think much about at the time. Before the Page Builder problems started, when applying plugin/theme updates the dashboard would list each update as it happened and say if successful or not (normal behaviour). After the Page Builder problems started, when updates were applied the dashboard did not show the update history and after a while a time out message was displayed. However, when I reloaded the screen it would show that all the updates had been applied. This behaviour has now stopped and has gone back to displaying the updates as they happen.
It may be a total co-incidence that two seemingly unrelated problems cured themselves at the same time, but it would suggest a tweak by Fasthosts has made WordPress work better. I haven’t asked Fasthosts if they did anything, I was just glad to have everything working!