Skip Navigation

[Resolved] I am not able to edit, disable, or delete Toolset custom code

This thread is resolved. Here is a description of the problem and solution.

Problem:

The customer was unable to disable a custom code in Toolset settings due to a 403 error caused by their hosting security system, which blocked Ajax requests to admin-ajax.php, labeling it as an exploit attempt. The firewall prevented changes that required Ajax, such as disabling custom code or modifying certain settings within the Toolset plugin.

Solution:

We identified the issue as being related to the firewall blocking Ajax requests. The customer contacted their host to whitelist the necessary URLs, which allowed them to enable and disable custom code successfully. However, the issue persisted when making changes to the search and pagination section in a view. As a workaround, we moved the CSS from the Search and Pagination section to the Loop CSS, and the problem was resolved, allowing the customer to save the changes correctly.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Our next available supporter will start replying to tickets in about 2.43 hours from now. Thank you for your understanding.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 12:00 9:00 – 12:00 9:00 – 12:00 9:00 – 12:00 9:00 – 12:00 -
- 13:00 – 18:00 13:00 – 18:00 13:00 – 18:00 13:00 – 18:00 13:00 – 18:00 -

Supporter timezone: America/Sao_Paulo (GMT-03:00)

Tagged: 

This topic contains 32 replies, has 3 voices.

Last updated by Mateus Getulio 2 months, 3 weeks ago.

Assisted by: Mateus Getulio.

Author
Posts
#2726166

I am trying to:
I am trying to disable a custom code in toolset > settings > custom code. However, it gives me an error that the changes cannot be saved. Link: hidden link

Link to a page where the issue can be seen:

I expected to see:

Instead, I got:

#2726831

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

Screenshot 2024-08-22 at 09.06.12.png

Hi there

The message shown in the UI doesn't give details of what the error was.

If you are familiar with your browser dev tools, you could open those, switch to the Network tab, then try one of the actions like activating/de-activating a code snippet.

That will submit an ajax request. If you select that in the Network tab, you can check the Response, as shown in my screenshot (which was for a successful request).

Does that have any more details of the error?

If the request reports a 500 server error then you should be able to find details of the error in your debug.log.

If you haven't already, turn on the debug log by editing your wp-config.php file and change the line with WP_DEBUG like so:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('WP_DISABLE_FATAL_ERROR_HANDLER',true);

That will create a debug.log file in your /wp-content/ directory which you can examine in any text editor. Try the action again that triggers the error, then inspect the log.

Let me know what you find.

Also, I expect this problem likely occurs because of some conflict with code from another plugin or your theme. You could confirm that by disabling non-Toolset plugins and switching theme and trying again, in which case it should be possible to determine the source of the conflict by a process of elimination.

#2727253

Hi Nigel,

I am not familiar with the developers tools; however, are you able to send me a video on how this is done? I can probably follow along.

I disabled my plugins and theme; however, the issue still remains. Please see the video for the full process of what I did.

Here is one error I got with toolset:
wp-views/vendor/toolset/toolset-theme-settings/compatibility-modules/controllers/toolset-theme-integration-settings-abstract-controller.php on line 56

Video: hidden link

I would attached the txt file of the log I got, but I can only upload an image.

Thank you,
Andrew

#2727338

Found another issue, I am unable to save my views when I edit the search and pagination section only. Other sections work fine and save. Link: hidden link

Not sure it is related.

#2727360

I added the code to have a debug log you provided in your first message. I also received this depreciation issue: wp-content/plugins/cred-frontend-editor/vendor/toolset/toolset-common/toolset-forms/classes/class.file.php on line 142

#2727586

Mateus Getulio
Supporter

Languages: English (English )

Timezone: America/Sao_Paulo (GMT-03:00)

Hello Andrew,

Regarding the save issue, I checked it and it looks like other users who were having the same issue were able to fix it by installing the Toolset Blocks and enabling the Legacy views in the Toolset Settings > 'Show both the legacy and Blocks interface and let me choose which to use for each item I build':

https://toolset.com/forums/topic/cannot-save-minor-change-to-view/#post-2110117
https://toolset.com/forums/topic/toolset-views-not-saving-mainly-taxonomy-filters/#post-2626077

Can you test it to see if it gets the issue fixed?

Regarding the issue with the snippet, to debug it further and suggest the best way to fix it, I'm afraid I'll need access to the the admin area.

Can you please share temporary admin login details?

Note: Your next reply will be private and please make a complete backup copy, before sharing the access details.

regards,
Mateus

#2728660

Mateus Getulio
Supporter

Languages: English (English )

Timezone: America/Sao_Paulo (GMT-03:00)

Hello Andrew,

Thank you for sharing that information.

I'd like to ask permission to make a copy/staging version of your site where I can debug this closely without affecting the live site.

I'll make sure to delete this copy as soon as we get this issue fixed.

I'm afraid of debugging directly on the live site and cause issues to your visitors. Also, it is important to test a different setup as part of the troubleshooting.

Thank you, please let us know.
Mateus

#2728783

Hi Mateus, yes please feel free to make a copy. However, before you do, please deactivate the Paid Membership Pro plugin as this can cause issues in my payment gateway.

#2732246

Hi Mateus, may I reactive the custom code? My users will be using the site soon.

#2732262

Mateus Getulio
Supporter

Languages: English (English )

Timezone: America/Sao_Paulo (GMT-03:00)

I apologize for it, in my test copy the snippets are working properly, hence me needing to debug on the site, I'll be careful.

The snippets have been re-enabled.

#2732263

No worries, thank you! It is working!

How were you able to deactivate and active the custom code from the backend?

#2732265

Mateus Getulio
Supporter

Languages: English (English )

Timezone: America/Sao_Paulo (GMT-03:00)

All right,

I checked it and I believe I found the issue.

Upon looking into the console log, I found the following error:

/wp-admin/admin-ajax.php:1 Failed to load resource: the server responded with a status of 403 ()

GoDaddy Security - Access Denied
Block reason:
Exploit attempt denied by virtual patching.
URL: <em><u>hidden link</u></em>

In essence, there's a firewall in place blocking Ajax requests performed by Toolset, that's why I couldn't replicate the same issues in a different environment.

Some Toolset content is updated with a page reload, for those, you won't have any issues. But for content such as the code snippets and a few areas within the views edit screen that are editing with Ajax, without reloading the screen, as long as the block is in place you'll have issues with it.

I'd recommend getting in touch with your host provider, and ask them if it is possible to open the access for the URL /wp-admin/admin-ajax.php. They should be able to add it to the allowlist.

This will fix the issues you're experiecing.

#2732304

Thank you Mateus! I am amazed how you troubleshooted this. I will get in contact with them and allow the url to be allowed! I will update you with my results.

#2733240

Hi Mateus,
Here is Godaddy's reply (Godaddys Firewall). It looks like the two possible solutions is to Whitelist the IP Address or allow a portion of a URL path allowed.

I am a bit confused:
- The IP address making the Ajax call, is that Toolset's IP Address or Mine? If it is mine, then any time I get this issue, I can check to see if my ip address changed and whitelist it.
- Do you see a possible solution with the portion of the URL? I am not clear how this would work.

"So, to resolve this kind of block, we would either have to:

- allow the IP/IPs on the firewall from:

hidden link

We only found requests made from 2 IPs, 1 of them appears to be your current IP (173.21.184.4), and the majority of requests were from 179.0.72.164.
We've now allowed both IPs on the firewall from the above link to ensure these requests no longer get restricted.

- allows parts of the URLs being accessed on the firewall from:

hidden link

As in this case, the URL being accessed is in the admin section you won't be able to allow the full path on the firewall because it contains the word 'admin'. And admin paths cannot and shouldn't normally be whitelisted to keep the site secure and prevent any possible abuse.

You can further double-check with the plugin support team, to have them confirm the IPs used by Toolset to perform calls.
Allowing those IPs or IP ranges on the firewall should be sufficient and as far as we can see right now, the majority of calls were made from: 173.21.184.4.

If allowing the URL will be necessary here, then something like this ('-ajax.php') may need to be whitelisted instead of the absolute path.
However, our recommendation would be to keep using the option to allow IP/IP ranges instead - as it's more secure.

More details on how to allow IPs or URLs on the firewall can be found in the below guides:

hidden link

hidden link

Please let us know if you continue to experience issues after the latest changes or if we can assist you with anything else.

Best Regards,"

#2733252

Since they whitelisted my IP address and Toolsets IP address, it has fixed the issue! I am now able to disable / enable the custom code in toolsets custom code section in the settings.

This did not solve the issue over making changes to the search and pagination section in a view.