Big bump on this one @patrick… something simple to fix this issue feels very very important for those of us who are building real, server connect heavy apps!
Would it be preferred to control this per server action or would it also be okay when we just output all actions in debug mode?
If you’re adding a global option (whether it’s per server action or everything), could a line be included in the output to remind us that setting is on?
If you output everything, some queries can return too much data so it is evicted from the developer console (still accessible via dmx.app.data though), but more problematic some things like blobs can break the JSON structure
I think outputting everything in debug mode would be too simple a solution for me. An “Output all” switch per server action would be great.
So when the switch is on, everything outputs.
When it is off, just those with the output option checked will output.
What would also be great is that if debug is off, this “output all” option does not happen, even if the switch has been left on.
1 Like
I had always envisioned a toggle per server api. If just using the server debug toggle, I fear new users will wonder why their app breaks when moving to production or turning off debug. In other words, they don’t realize that the output tick of a specific action is what really controls the output that is used at the client.
To be clear, I am not advocating for a toggle per api exec step, just one toggle per api.
2 Likes
Hello Everyone! I'm having difficulty debugging an API called via the browser, where the output I insert only appears at the end of processing and worse, only the last interaction with the set value, but the ideal would be to be able to follow the evolution of the set value. How do you debug an API with several processes and need to visualize the processing progress?
It would be interesting if Output checkboxes could be bound to expressions, and then is easy e.g. checking an environment variable to see if debug is on or off
@Teodor can helpme? Thank you so much!
I'm thinking the standard reply here is that you should start a separate post. And you can get help there. Yours doesn't really apply to this post subject.
Hi @baub, this topic is about "Output for debugging only", my question is about "Output debugging", i think that exist correlation! but tks for your advice!
actually the post is for a feature request. Not troubleshooting issues....
Please start a separate thread and we can get you on your way to solving the issue.
you can also check out my wappler monthly meetup video talking about troubleshooting API's...
1 Like
Wappler 7 BUMP! 
1 Like
The inability to distinguish production output from debugging output may be my least favorite Wappler thing.
2 Likes
OMG… I think about this topic almost ever day at the moment Ken…
It is my least favourite thing too.
I set a ton of outputs on to debug, and then lose track of what I actually need to be set and end up leaving them all on.
Who knows how much data my app wastes.
The lack of this feature is actually a major productivity and stress issue.
I can’t imagine it would be that hard to implement. 
This would be a delightful addition for 2025!
Bump…an everyday need (at least for me)
2 Likes
What about a simpler solution?
A global setting which forces output on all api actions when set.
Then you can just activate it, debug then deactivate
In the next update, when you toggle the " bug" icon in the bottom toolbar - all output of the server actions will be outputted when the development target is running.
2 Likes
Thanks for working on this George!
I use docker in dev to reduce the differences with production.
Will this option work on a docker dev environment?
Good catch! Will make sure it works also on the local docker dev environment
1 Like