I am trying to: create a form
Link to a page where the issue can be seen: backend - see screenshot
I expected to see: a nice shiny new form ready to be deployed
Instead, I got: a constantly turning icon, a pile of console warnings and a broken form.
Note, i'm creating this form as a test. This site has 3 forms. they were all working fine. Today the client reported that one form is redirecting to a 403.
I've tried updating all plugins, core is up to date, theme is up to date. I've adjusted the faulty forms redirect settings to all options, checked access settings and re built .htaccess. I've also checked the server / cpu.
A 403 typically indicates some type of security restriction. I can see you have a few other plugins active. Can you temporarily deactivate everything but Toolset and activate a default theme like Twenty Nineteen? If you need to keep the Coming Soon plugin active, that's fine.
Clear your browser cache, then retest. If you still get the 403 error on wp-admin/post.php, I'll need to take a closer look. If the error is gone, reactivate your theme, then other plugins one by one until the error returns. Let me know what you find out and we can go from there.
Can you copy + paste the entire Form code here for me to review? I can't imagine why saving a Form would be producing a 403 error, other than some server-side configuration. I'll try to see if any broken HTML markup structure could be at play here.
It might be related to the content inside the Form, unique to this Form. For example, you have quite a few fields with very long slugs. As a test, I would back up this Form's contents somewhere and begin by removing all fields except form_messages and post_title and submit. Then try submitting the Form, and see if a 403 is produced. if not, try adding other fields one by one until the problem returns. Let me know if the problem is resolved by temporarily removing most of the custom fields.
Thanks Christian,
Tried to remove all fields as suggested but 403 error persists.
This form has been working for years, it was moved to this site in November of last year, and has been working.
Has there been an update that would cause the slug length to be a factor?
This is a live site, with adverts running to promote the Recruitment for the firm. They are fielding telephone calls at the moment.
Recap:-
Form was working.
Other forms ARE working
Cannot save edits to original form
Cannot Finish wizard to create new form for this post type BUT CAN FOR OTHER POST TYPES (see screenshot for form just created)
Have turned off all plugins
have activated 2019 theme
site is now down for over 12 hours.
It must be an issue with the medical info post type and recent toolset updates?
Do you want a login?
Thanks for the summary, I'm not aware of any recent changes that would have affected slug length, and I'll have to dig a bit deeper to discover more. I'd like to create a clone of your site using the Duplicator plugin so I'm not affecting the live site during testing. If that's okay with you, please provide login credentials here.
In the meantime, we could check the server logs for any additional information. 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');
Try to complete the form wizard once again. If any back-end errors are thrown, this should 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 and delete the log file.
Well the good news is I was able to create a clone of your site. The bad news is the Form saves successfully on my local environment, with nothing in the logs to indicate reason for failure. So it would appear to be a configuration issue at the environment level. At this point, it's probably best to get your host company involved to see if they can help pin down why this specific request is returning a 403 error. They'll have more detailed access to the servers and can troubleshoot issues on their own environment more effectively than either of us can. Let me know if there's anything you need from me to facilitate this discussion.
Thanks Christian, have raised a ticket with my hosts. Can we keep this open in case they have any questions on toolset ?
Thanks,
D
Yes of course, I'll set the ticket to be pending your update. It will stay open and send you a reminder if it's about to close. Then just reply "I'm still waiting" or something like that and the ticket will stay open longer.
I'm not sure, perhaps you should ask the people who told you this. Our software comes with SQL injection prevention measures, so an extra layer of security on top of that may be unnecessary.
I did ask them, they advised I ask the plugin developers.
Thanks for your help so far Christian, appreciated.
My issue is resolved now. Thank you!
