Output for debugging only

In troubleshooting, I often tick the output of server connect actions – works great. I may do this to several different actions while I am trying to figure things out.

Once I’ve resolved the issue, it sometimes is hard to remember which actions need to remain in the output. In other words, I’m going back and turning output off on all my troubleshooting steps, but sometimes I turn off an output that needed to remain on!

This request is to have a toggle on the settings of a server action/library that when ticked, outputs everything from every action contained within.

So when troubleshooting, tick one box, and all output is generated. It would operate independent from the output tick box on the individual actions.

That would be amazing @mebeingken.

This actually feels like a really simple addition to Wappler that could make a big difference in development time!

A great idea. :ok_hand:


I’m soon going to have to go through all my server actions and try to work out which outputs were real, and which were for debug.

It would be amazing to have this simple feature added so I never have to go through that process again!

trying to not get too far off on the subject, but talking about debugging. An issue I am always changing around is a value in an insert is the wrong type. But which one? Dreamweaver you used to be able to test the output outside of the browser and would say field such and such is wrong type. then you know to change. Would be nice to add a feature like that…


This would be an amazing productivity feature for me… I need to go through my app now and turn off all the outputs I set for debugging… it would save me so much time never to have to do that again! :slight_smile:

What about an additional debug_output that outputs when a SC expression resolves to true?

That way in the SC config I can add:

Debugging output = $_ENV.environment != production

And evaluate in the core files the single SC action output as debug_output || output


:rocket: :rocket: :rocket: :rocket: :rocket: :rocket: :rocket:
:rocket: :rocket: :rocket: :rocket: :rocket: :rocket: :rocket:

I am developing two really complex mathematical server actions at the moment, and I really need all the outputs set for debugging purposes - so be set on for about 40 different steps.

I want all those steps except two to have output off when the debug is complete.

I have to turn off 38 outputs, and leave the correct two on.

Then I have to test a very complex app function to be sure I left the correct two still with output on.

Then I find a bug and need to do it all over again.

This is an incredibily time consuming and error prone process!

:pray: :pray: :pray: :pray: :pray: :pray: :pray: :pray: :pray: :pray: :pray: :pray:
can this much voted for feature be added
to version 5 asap?
:pray: :pray: :pray: :pray: :pray: :pray: :pray: :pray: :pray: :pray: :pray: :pray:

Thank you! :slight_smile:

1 Like

You can select multiple steps and enable/disable output in bulk.


I wish we had this every single day…Output for functionality needs to be separated from output for debugging.


bumping this request as well.

Bump, beg. :slight_smile:

Is the request eventually for additional option for output on debug only?

As there is no way for us to see which output is real and which is for debug…

It’s the only way I can see it done with finer control.

What about an additional output_debug_flag as SC option and an output_debug as SC file key-value?
That way in the SC config I can add:
output_debug_flag = $_ENV.environment != 'production'
And evaluate the returned output data as (output_debug && output_debug_flag) || output

1 Like

Correct. Just a single tick box for the entire API, that when selected will output everything.

The workflow then, is to only tick the output of actions that are needed in the browser. When I run into trouble and need to start troubleshooting, I tick the new debug output option so I can see everything. When I’m done, I turn it off so only the action outputs remain.

And as Jon notes, controlling via ENV would be ideal.

@george @mebeingken After giving it another thought I think that the current output understood as returned data in the response might not be ideal for debugging purposes.

Why not create a new panel somewhere in the UI called Output/Debug that shows this debugging data? Instead of tampering with what the returned response is it could be populated from console.log

That way we separate these two concerns. Because by mistake we could return data in the response that should be kept private.

This panel could also handle JSON format with trees with expanding/collapsing nodes and search.

1 Like

I’d love this…especially in that things like timestamps could be added, and actions that have their value change over time could be seen.

BUT I would prefer something over nothing. A debug panel seems to be a better solution, but also a more involved feature add.