Hello @vfontj,
Sorry for the late response. And thank you for the extra information to help me sort this out for you. If don’t mind, let me ask a few additional questions.
All of the questions I’ll ask are to help me investigate, find the root cause, and formulate a solution strategy. Victor, thank you for helping me with this.
The stand alone kint debugger still works fine. But with either plugin loaded, the form stops loading after an error.
- “But with either plugin loaded” – To clarify, if an error occurs, the form does not load with either the Kint Debugger and Debug Toolkit plugins. Is that correct?
- When this happens, what function are you using from Kint?
- Without either debugging plugin, does the form load with an error?
- What kind of error are you getting: notice, warning, or fatal error?
- What is the error?
The debug toolkit plugin displays 1 whoops error that has nothing to do with this form. The php error log is showing that an array value is not being initialized properly. Old school PHP debugging works fine though.
It sounds like there’s some competing styling happening. Let’s talk about it.
Variable Inspection:
The new version of Kint gathers up all of the rendering and displays it at a fixed position at the bottom of the screen.
Action: Switch to using
vdump()
instead instead of
d()
. Notice that vdump()
renders where the content would appear. Does this give you the information and debug experience you want and need when working with Formidable Forms?
How about Whoops?
Whoops attempts to overlays the entire screen to provide you with detailed information and help for a notice, warning, and fatal error. From what you are describing, it the form and/or something else is competing for the same top-level view.
My Action: Thank you for reporting this edge case. Currently, I’m not modifying the out-of-box experience with Kint or Whoops. But for Whoops, it seems we need a way to (1) disable it if you don’t want it and (2) handle the top-level display competition.