[Escalated to 2nd Tier] I am having repeated JSON response errors when using Toolset.

[Author]

Posts

[Christian Cox]

I don't want a speed and reliability comparison. I want to figure out why this issue keeps popping up and seems to be related strictly to Toolset. Can you help with that?
Yes, and I need feedback from the hosting provider to move forward. I understand that you communicated with them in the past, and they sent you to us. Now I have done some investigation into the problem and identified some specific causes - security errors returned when accessing specific data URLs in the editor. I'd like to get their feedback on these issues, because the problem does not occur on another environment. It occurs on this specific host environment, which is why I wanted to show you on a sandbox for your comparison - it's not necessary to have that sandbox and if you're satisfied without seeing that comparison that's fine.

Specifically, we are receiving 403 errors from the server when trying to access some data URLs in the editor under the directory:
hidden link
What would cause these errors from the server, and can we avoid them somehow? Can we open access to these URLs so the errors do not occur? Those are questions only the hosting company can answer. I look forward to their feedback.

[peterS-27]

Hi Christian,

Sorry for the delay! The "I still need assistance" button wasn't available until today. So I had no way to reply to this.

Is there a good way for you to communicate directly with the host? I'm not a developer, so it's hard for me to run interference between you two on issues that I don't really understand. Both of you are saying it's the others' problem.

Thoughts?

Thanks for all the time and energy you've put into this.

Peter

[Christian Cox]

I can also try running additional tests on the live site, if you approve, since the problem does not occur in our cloned site on a different server. I would need to be able to deactivate plugins and activate a default theme temporarily. I could activate a Maintenance mode plugin during those tests if you would prefer not to show the site during testing. If that is not allowed, we can ask the host company to help set up a clone of the site in a staging environment so we can run tests in staging without affecting the live site.

Is there a good way for you to communicate directly with the host?
I'm not sure how their support system works. If it's like ours, you need a client login for their system to submit tickets for support. Our policy is to communicate via the support forum (https://toolset.com/toolset-support-policy/), and I'd prefer to stick to that policy. I can write a message for their support team with the technical information, and you can copy + paste that directly into a ticket in their support forum, if that helps.

-----
Hello support, my name is Christian, from Toolset support, and I am assisting your client who is experiencing a problem in the WordPress block editor. Your client is using our plugin suite, which provides some editing features in the wp-admin Block Editor. The browser is receiving server-side errors for AJAX requests when editing a post in wp-admin at the following URL:
hidden link

Wordpress is attempting to load data from this URL, among others:
hidden link

Instead of receiving the expected JSON data, the browser is often receiving 403 errors, which indicate a security plugin or system on the server blocked access to the API for that AJAX request. I'm attaching a screenshot showing this issue in the browser console. This doesn't really make sense, because similar URLs are accessed by the editor when editing other posts, without similar security restrictions. The problem is sporadic. Can you help us determine the source of these server-side errors and help us provide a solution for our mutual client? When the errors occur, the post cannot be saved, and our client is losing their work. Based on a previous conversation between our mutual client and your support team, the client was under the impression that this is a Toolset problem, but did not provide technical details of that analysis. If you are able to tell me why a server-side error is being triggered here sporadically, that would help us troubleshoot the problem. We have not been able to replicate the same problem in a different environment using a clone of this site, and server-side errors like this security code are not issued directly by our software, so something else is going on here. Are your servers configured to send error messages like this for AJAX requests under specific circumstances? If there is something Toolset can do to prevent this error, please let us know so we can solve the problem. If you would like to access the cloned site in a different environment for comparison, please let me know and we can provide access.

-------

[peterS-27]

Thanks Christian! I've sent this note to the host. I'll let you know when I hear back. We can try you testing the production site sometime if it comes to that.

Thanks again for your help!
Peter

[Shane]

Hi Peter,

As christian is currently on vacation, i'm doing some followup for him.

Can you update me on the issue ? Did Christian's suggestion helped to resolve the issue ?

Thanks,
Shane

[peterS-27]

Hi Shane,

Sorry for the delay. I didn't see your note. The issue is still persisting unfortunately. Since I'm not a developer, I continue to believe the best solution here is for Toolset support to speak directly to my hosting support. Is that possible somehow?

Peter

[Shane]

Hi Peter,

There has been a ticket opened for this with our dev team to have a look at this.

I tried on your site in the 2 URL's that christian had posted in the notes for the thread however on both instances i'm not able to see the issue.

Both pages updated fine without throwing an errors. Right now i'm waiting on a response from our Dev team on their findings on the issue as there is another ticket opened with the same issue.

Can you verify that the URLs below are the ones that you are experiencing the JSON issue on.
hidden link
hidden link

Thanks,
Shane

[Nigel]

Hi Peter

I've been looking into this, let me comment directly with where we are at, while awaiting some feedback from the developers.

There appear to be a couple of issues affecting your site.

One is related to a known issue, described here: https://toolset.com/errata/unexplained-problems-on-backend-edit-screens-possibly-associated-with-json-errors/

That problem was first reported in relation to Yoast, and it seems fairly innocuous: for SEO purposes Yoast scans the contents of the posts being edited, and can be confused by our implementation of dynamic sources such that it submits an ajax request that includes an unparsed shortcode, which generates a 404 for that particular request. At face value that is harmless, and is why it hasn't received much attention before now. But recently we've had one or two other reports about problems with the back-end editors on certain hosts, and it appears that the presence of single quotes in that query from Yoast is raising security flags and prompting the blocking of some legitimate requests (giving 403 errors) which affects the funcionality of the editor.

I did some checking on your site, and it appears that the SEO plugin you are using (SmartCrawl Pro) suffers from the same issue.

So I've raised the priority of that existing issue so that it can be worked on sooner, to see if we can intervene so that the SEO plugins don't make those problem requests with an unparsed shortcode, and I'm linking this thread to that internal ticket.

At the same time, your site also appears to experience intermittent issues when trying to edit pages containing Views, where sometimes the page loads in the backend and is editable, and other times fails to load at all, or partially loads but the browser console reports invalid JSON responses and 500 errors on such requests.

The intermittent-ness likely reflects the load on the server at the time of loading the page edit screen. On a local copy of your site I could see that the 500 errors relate to a PHP Maximum execution time exceeded error. I found that increasing the PHP setting for max_execution_time resolved the problem, and you may need to speak to your host about doing the same on your server. Although your site is large, the View I inspected on the Archive of... page didn't look overly complex, and I've also passed that to the developers to take a look at to see if they can identify why the page needs so long to load.

So I see 2 issues affecting your site, both of which have been passed to the developers.

For the first—relating to the SEO plugin—I suggest you check if its settings allow you to disable it on particular pages (i.e. pages that contain a View and an image block using dynamic sources in particular) and on Views Content Templates. Or you may need to temporarily disable it while making edits to such pages.

For the second, while we investigate why the page takes so long to load in the editor, I suggest you ask your hosting company to increase the max_execution_time setting.

Shane will follow up when we have some feedback on either of these from the developers.

[peterS-27]

Thank you Nigel! That is very helpful. I'll look into what I can do about SmartCrawl and talk to the host about max execution time.

Peter

[peterS-27]

Hi there,

I hadn't tried to edit the page in question for about a month now. I went to it just now and it says "Updating failed." Any idea why this is happening? Any updates on the Yoast/SmartCrawl situation?

Thanks!
Peter

[Shane]

Hi Peter,

I checked on the escalated thread for this and saw that this issue was resolved in our views version 3.5.2

So updating to the latest version of our Views plugin should resolve this issue for you.

Thanks,
Shane

[peterS-27]

Hi Shane,

Thanks. I don't actually have the Views plugin activated. Toolset refers to it as a "legacy" plugin that is only needed for older sites. Should I download and activate it anyway?

Peter

[Nigel]

Hi Peter

Just to clarify, there were two issues arising from this thread.

One related to max_execution_time errors, and occurred because of the number of taxonomy filters included in your View along with the setting to only show filter options that would produce results, and some optimisation was done for that case which should significantly reduce the page load time and prevent the updating failed issue. Those changes were included in Views 3.5.2, or Blocks 1.5.2, the two are equivalent and if you were using Blocks (I don't recall), please continue with Blocks.

The second issue related to 404 responses in the browser console arising from your SEO plugin: that issue is ongoing and is not resolved yet, hence we'll leave this thread escalated until we have some further news on that.

[peterS-27]

Great - thank you Nigel!