debug_kit
debug_kit copied to clipboard
cakephp
Cannot watch template variables if Form has notEmpty() rules
This is a (multiple allowed):
-
[x] bug
-
[ ] enhancement
-
[ ] feature-discussion (RFC)
-
CakePHP Version: 3.5.8
-
DebugKit Version: 3.11.3
What you did
Use modelless Form with notEmpty() rule, assign it to template variables, and click the Variables tab of the DebugKit.
What happened
Get Serialization of 'Closure' is not allowed error.
What you expected to happen
Template variables can be watched.
Why this issue happened
notEmpty() uses Closures internally and ToolbarService calls serialize() here.
(Reported by powder_mikan in #japanese cannel on Slack)
Looks like the __debugInfo of Form is returning closure instances. Perhaps we should have Form or the Validator remove the Closure instances out?
Thank you for your comment. I didn't know DebugKit calls __debugInfo(). Then it would be an idea. But first, let me try to fix this walker. If it ensures that the return value doesn't contain any closures, this kind of issues will no longer happen.
It was not so easy :disappointed: At first I was planning to replace closures with string '(closure)' recursively. But it would break objects in view variables, or runs into infinite loops if I don't take care.
I wonder if we should try storing data that isn't the serialized variables. I don't know what that would be, but Debugger::exportVar() might be a good place to start or use as inspiration.
If we don't need to use serialize(), then I think the built-in var_export() may be a good function. It can stop when recursion detected.
Not using serialize() may make expanding variable contents much harder as right now we rely on being able to traverse objects/arrays and generate the nested HTML structures. We wouldn't be able to do that with the output of var_export().
Hmm. It seems to be harder than I thought. Indeed, using var_export() doesn't make sense as we would get Call to undefined method Closure::__set_state() instead of Serialization of 'Closure' is not allowed.
But I think traversing variable like Debugger::exportVar() is not a good idea either, as if the following variable is assigned, DebugKit has to export recursively until max depth:
$array = [];
$array['array'] =& $array;
It would make DebugKit slow.
We could keep max-depth shallow, like 3 or 4 levels, as a way to prevent slowdowns. I don't think we'd be able to use Debugger::exportVar() as is, because we'd still want a way to create clickable HTML out of the variable dumps.
Oh sorry, I forgot about this issue. Now I am thinking fixing Form::__debugInfo() would be safe, as I am not sure if using Debugger::exportVar() doesn't cause another issues like this.
