[Resolved] 500 and 404 Errors from Page with CRED

Hi, I'll be glad to take a look. First, let's try to narrow down the source of the problem.
- Temporarily deactivate all plugins except Types, Views, Layouts, CRED, and any WooCommerce plugins needed to create these Orders. If you need to activate a Maintenance Mode plugin that's fine.
- Temporarily activate a default theme like Twenty Seventeen. Test again.
- If the problem was resolved, reactivate your parent theme, then child theme, then plugins one by one until the conflict is revealed.
- Turn on server logs to get some more information about what's failing. If you're not familiar with server logs, I can show you how to activate them temporarily. Go in your wp-config.php file and look for define(‘WP_DEBUG’, false);. Change it to:

define('WP_DEBUG', true);

Then add these lines, just before it says 'stop editing here':

ini_set('log_errors',TRUE);
ini_set('error_reporting', E_ALL);
ini_set('error_log', dirname(__FILE__) . '/error_log.txt');

Reload the page that causes a 500 error. This will create an error_log.txt file in your site's root directory. Please send me its contents. Once that is done, you can revert the changes you made to wp-config.php.

Let me know what you find out and we can go from there.

Hmm, I don't see anything in this log that indicates a 500 error. Warnings and notices shouldn't be causing 500s. If you can't run the tests on your live site, I'll need to work on a site clone. I can log in to your wp-admin area and use the Duplicator plugin to create a clone of your site, then install it locally to try to reproduce the errors. If that's okay with you, please provide login credentials in the private reply fields here.

If that's not okay, the other options are:
- You create a Duplicator clone and provide a download link for me
- You create a zip backup of your site's plugins and themes folders, as well as a SQL dump file from your database

Hi Jesse,

Christian is currently on holiday today but will be here tomorrow to continue here.

Regarding the duplicator package you don't need to create an account as when the duplicator is being restored locally on Christian's server then he is able to create an account there.

Also I've enabled the private fields for you to provide the duplicator package.

Thanks,
Shane

I'm not able to recreate these 404 and 500 error calls to admin-ajax.php on my local clone of the site, so there must be something else going on. Do these errors appear after performing a search in the custom search View, or after submitting the CRED form, or are there other specific steps I should take? After performing a search I see an alert popup that the JS has been reset.

Check out the file error_log (not error_log.txt, which we created) in the root directory of your site. It looks like this error log has been up and running for a while, and I'm able to see quite a few 500 errors in here. Most recently they seem to be related to the X theme's WooCommerce files:

PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_loop_prop() in /path/to/wp-content/themes/x/woocommerce/loop/pagination.php:13

That could certainly cause issues like you're experiencing in calls to admin-ajax.php, but again I'm not able to replicate those on my local environment. Is it possible your new host has calls to admin-ajax.php blocked somehow on the backend? If you open the Network tab in the debug console, are any calls to admin-ajax.php successful? I'm not able to tell from the screenshot you included earlier.

Okay I will stand by for your updates on this. You should be able to find 500 error messages in one of the two error logs that correspond to each 500 failure to the admin_ajax.php file, so that might be useful to your host for troubleshooting. Let me know if there's anything else I can do to assist.

Sure, I can try that. I will activate private reply fields again here. Another thing I would ask Host Gator is if you can test on a different version of PHP. I have been testing on 7.1.12. It looks like your current server is on 7.1.17. That should be fine, but if it's simple to switch to something else I think it's worth a shot. Anything greater than 5.3 should be okay. I can also see that your server's MaxInputVars setting is 1000. This is a bit low, and I would ask about increasing it to 5000 if possible to prevent wp-admin issues when saving posts with lots of custom fields.

Okay I imported these forms and Views but I'm still not able to replicate the problem locally. I am able to see that there are some 65 Views on this custom search page, which is quite heavy. Some other tests you could try:
- Limit each View to only 1 result temporarily
- Turn off AJAX updates on all these Views temporarily
- Test any nested Views independently of each other elsewhere on the site to isolate problems with any one particular View