Skip Navigation

[Resolved] Toolset causing “critical error” in WordPress

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

Problem: Toolset is causing a critical error in WordPress.

Solution: Increasing the available memory on the server and in the wp-config.php file configurations seems to solve the problem here.

This support ticket is created 3 years, 4 months ago. There's a good chance that you are reading advice that it now obsolete.

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.

No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.

Sun Mon Tue Wed Thu Fri Sat
8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 - -
13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 - -

Supporter timezone: America/New_York (GMT-04:00)

This topic contains 12 replies, has 2 voices.

Last updated by dmfzw 3 years, 4 months ago.

Assisted by: Christian Cox.

Author
Posts
#2112271

Toolset is causing the following message to appear in certain WordPress front end pages:

"There has been a critical error on this website."

We've disabled all other plugins to confirm that the issue is caused by Toolset but we're not sure how to fix it. Any ideas?

Also, we'd like to privately provide the site address and URLs.

Thanks

#2112321

Hi, I'll be glad to take a closer look and sort out the problem here. I will activate private reply fields for your next reply so you can share login credentials securely. Please include at least one of the URLs where the problem can be reproduced. Any URL you share in a reply will be automatically obscured from public view, but login credentials should be shared only in the private reply fields.

If you include FTP information I can troubleshoot further by turning on error logs with temporary modifications to your wp-config.php file. I'll try to get more information about the critical errors and give you some feedback.

#2112609

Thank you, I'm investigating now and will give you an update shortly.

#2113597

Hi Christian,

Thank you for your response. It's good to narrow the issue down to the resized images.

We haven't changed server recently but we did integrate the website with Stackpath CDN a few weeks ago, around the time we started noticing these errors, so that may tally with your findings. We spoken to Stackpath a few times and each time they said the issue was either server or plugin related. So I spoke again with them today and gave them the information you provided- they said that the root issue still seems to be with Toolset and possibly also the server, as when they bypassed CDN the error still persisted.

Please see their screenshots:

hidden link

hidden link

At this point i'm not sure what to do? I guess we could get around the issue by using the default images instead of the resized images, but that being said, some of the author pages still have the error (I'm guessing this is because these pages are still using the resized images?).

What would you recommend?

#2113601

Hi again Christian,

Sorry, I didn't see your later response until posting ( ^ it didn't post first time round, but I've posted it anyway as it might yield some insight). I'm thrilled you were able to get some success with the memory limit increased and would be more than happy with you jumping back in and restoring the temporary changes once the memory has been increased.

However, I informed my host and they said the following:

==
When I test the url with curl, a HEAD request returns status "200 OK", but a GET request does return status "500 Internal Server Error":
===

Currently, no errors are being logged by apache or php when I test this request. I am checking if I can get more useful information by raising the verbosity of the logging. I will continue to keep you updated with my progress.

The global php settings for each php version can be adjusted via the MultiPHP INI Editor in WHM, and the php settings for a specific cpanel account or domain can be adjusted via the MultiPHP INI Editor in cPanel.

It looks like the php memory_limit was set differently in different php versions in the server:
===
[root@host 1242339]# read -p "Setting names: " _list && whmapi1 php_get_installed_versions | awk '($1 ~ /^-$/){print $2}' | while read _ea_ver; do _ver=$(scl enable ${_ea_ver} "php -v" | head -1 | awk '{print $2}'); printf "\n%s: %s:\n" "${_ea_ver}" "${_ver}"; for _ini in $_list; do scl enable ${_ea_ver} "php -i" | grep -Pim1 "^${_ini}\b" ; done; done
Setting names: memory_limit

ea-php72: 7.2.34:
memory_limit => 400M => 400M

ea-php73: 7.3.29:
memory_limit => 400M => 400M

ea-php74: 7.4.21:
memory_limit => 128M => 128M
===

I have increased them for you to 512M:
===
[root@host 1242339]# read -p "Setting names: " _list && whmapi1 php_get_installed_versions | awk '($1 ~ /^-$/){print $2}' | while read _ea_ver; do _ver=$(scl enable ${_ea_ver} "php -v" | head -1 | awk '{print $2}'); printf "\n%s: %s:\n" "${_ea_ver}" "${_ver}"; for _ini in $_list; do scl enable ${_ea_ver} "php -i" | grep -Pim1 "^${_ini}\b" ; done; done
Setting names: memory_limit

ea-php72: 7.2.34:
memory_limit => 512M => 512M

ea-php73: 7.3.29:
memory_limit => 512M => 512M

ea-php74: 7.4.21:
memory_limit => 512M => 512M
===

But I still get "500 Internal Server Error" when I try the test request:
===
HTTP/1.1 500 Internal Server Error
Date: Tue, 13 Jul 2021 18:35:23 GMT
Server: Apache
X-Powered-By: W3 Total Cache/2.1.5
Link: ; rel="hidden link"
Link: ; rel="alternate"; type="application/json"
Link: ; rel=shortlink
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Vary: Accept-Encoding,User-Agent
Referrer-Policy: no-referrer-when-downgrade
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
===

From the response headers, it looks like the site might have an object cache enabled. I tried checking this with wp-cli:
===
[****@host public_html]$ wp cache type
W3TC file
===

and attempted flushing it, in case the error status itself had been cached:
===
[****@host public_html]$ wp cache flush
Success: The cache was flushed.
===

but I still got the error status:
===

Server: Apache
X-Powered-By: W3 Total Cache/2.1.5
Link: ; rel="hidden link"
Link: ; rel="alternate"; type="application/json"
Link: ; rel=shortlink
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Vary: Accept-Encoding,User-Agent
Referrer-Policy: no-referrer-when-downgrade
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
===

I am still checking what other useful information I might be able to coax the site into logging, and will continue to keep you updated with my progress.
==

So it looks like they're saying that even with memory increased, they're not able to resolve the errors?

I'll post more info from them as I get it, but what would you recommended with this in mind.

Thanks again for all your help, we really do appreciate it.

#2113635

Okay I added this line to the wp-config.php file again:

define('WP_MEMORY_LIMIT', '512M');

It seems to be required to set the limit here explicitly, even after bumping the memory limit setting on the server.

Then I activated the resized image shortcode again in the Template Layout here:
hidden link

Now I can see the resized image appear here with no errors:
hidden link

The 420x480 resized and cropped image is here:
hidden link

Can you take a look and confirm?

#2113637

Hi Christian,

Wow! The pages and images seem to be loading now without issue. I'll continue to check through everything but, without wanting to tempt fate, it seems like the issue has been fixed. You've done wonders here, thank you!

#2113643

Great, that's excellent news. If you're comfortable making the changes, you will need to revert the temporary workarounds I put in place as explained in my previous comment. If the replaced image shortcodes and Views begin working as expected, we can fairly assume the issue was a simple memory limitation and increasing the memory settings at the server level and also in the wp-config.php file will effectively solve the problem.

Let me know if the errors return after you revert the temporary workarounds I put in place. Otherwise, feel free to close out here if the errors are resolved.

#2114399

Hi Christian,

Would it be possible for you to revert those temporary changes for me, just so I know everything is back correctly?

Thanks!

#2114567

Would it be possible for you to revert those temporary changes for me, just so I know everything is back correctly?
Done! I have reverted the temporary fixes and the changes are ready for your review.

#2114633

Thanks Christian, that's perfect! Everything seems to be in working order - thank you for your assistance.

One last thing, would it be possible to make the following replies private from public view as there's some private information in there:

https://toolset.com/forums/topic/toolset-causing-critical-error-in-wordpress/#post-2112685
https://toolset.com/forums/topic/toolset-causing-critical-error-in-wordpress/#post-2113493

Thanks again!

#2114673

Sure, they are private now.

#2117099

My issue is resolved now. Thank you!