Causing Divi Builder in backend to Time Out

On my test site I was running Divi 3.0.89 and I wasn’t having any issues. I updated to 3.0.92, and still I don’t seem to be having any issues.

I would recommend ensuring that you clear out any caching / CDN tools you might have in place after having updated Divi. I have seen the Divi builder lag at times in general, and that always seems to fix it for me when it happens.

The IPN plugin definitely would not be causing anything with Divi as it doesn’t touch anything in Divi at all. This plugin does, of course, but again I am not having any issues on the latest version of 3.0.92.

Please try clearing out caching / CDN, as well as your browser cache, and let me know if you continue to have problems.

We can do that, and if it turns out to be a problem with our plugin we can get it resolved in our usual update process. However, if it turns out to be an issue at your end we’ll need to bill for premium support time.

Please submit a ticket here so we can work more directly and share credentials as necessary. Make sure to reference this thread please. Thanks!

John, I’m sorry, but it is not clearly our plugin causing the issue. I am indeed running on PHP 7.1, and I did update to the latest version of Divi followed by testing the editing of pages with the Divi builder. I am experiencing no lag at all. Everything is perfectly snappy, and again, we do not have any other reports of this problem.

You mention that you are running a bunch of plugins, so the odds of there being a conflict are pretty good. Whether that conflict resides on our end or on the end of one of the many plugins you’re using is not known at this point. You also mention that you’ve seen similar issues with Divi in the past (and I have as well, even without our plugin installed.) I cannot be paying my guys to troubleshoot a conflict with a 3rd party plugin. If, and only if, that sort of thing came up is when we would have to bill for the time. Our reputation speaks for itself. We do not ever “attempt to position people to pay” for anything related to bugs in our software, and frankly I don’t appreciate the sentiment. I also don’t appreciate the threat of “review accordingly”. I do not respond well to people trying to use bad reviews to get us to free work for them, beyond the free plugin we’ve already provided. Who’s the one trying to “attempt to position” the other here..??

You are using two powerful plugins of ours that you have not paid a dime for. Saying that we would need to bill if the problem was outside of our plugin is not out of the ordinary at all, especially for a FREE plugin. If you are confident that the problem is with our plugin then you should not have any worries at all about what we’ll find while troubleshooting. Whatever we do find, we would outline it with you in detail so that you know exactly what was causing the problem and how we fixed it.

The first step would simply be to disable all the other plugins except for ours to see if the problem remains. If not, then we would re-enable each of others one-by-one until the problem comes back. Once we find the culprit, then we can look to see if there’s something we need to fix in our plugin, or if it’s something they need to fix in theirs. If it’s something we need to adjust in ours then that would not be a billable task. If we find that the 3rd party needs to fix theirs, then yes, we would need to bill for the time we spent (and I paid for) to find the issue for you. I don’t see how you could possibly feel that isn’t reasonable..??

If you want to follow those procedures to find the culprit then we could install that plugin on our test site to see if we can reproduce the problem and check which side the conflict resides on. In this case there would be no charge from us, obviously. If we are able to reproduce it and we find the problem is on their end we would reach out to them and let them know, and it would be up to them to fix it. If the problem is on our end we would fix it and include it in the 1.0.5 update that we’ll be releasing soon either way.

If you cannot accept this procedure then I guess we simply agree that we are not a good fit and can respectfully go our own separate ways.

• This reply was modified 6 years, 4 months ago by angelleye.

Ok, great. I think we’re a lot alike with regard to the WordPress community and helping as much as we can for free, and I can understand that sometimes this stuff just gets a little frustrating. No hard feelings.

I’m glad you were able to find the conflict. That helps a lot. We’ll install that plugin to see if we can reproduce the problem and figure out where the hiccup is. I’ll update again here once we verify that.

Thanks!

@crzyhrse, We’ve been doing quite a bit of testing with this, and what we’re finding is that regardless of whether or not our plugin is active we are able to reproduce the timeout issue you reported when the ShortPixel Image Optimizer plugin is enabled. Based on this it seems the issue is with their plugin and is not related to ours at all.

We were able to resolve the issue by adding the following into our .htaccess file:

<IfModule mod_substitute.c>
SubstituteMaxLineLength 10M
</IfModule>

You may want to give that a try.