[Résolu] Unable to use Kint debugger CRED Forms

[Auteur]

Publications

[alexG-4]

I've come to rely on the very useful Kint Debugger plugin. The way the plugin works is that you insert d( <somePHPvariable>) into your code, and it displays the value of that variable in the HTML of the page being debugged.

But I can't use it with CRED forms.

With the normal operation of the form, when the form is submitted, and page reloads and Kint output gets lost.

So I tried setting "Submit this form without reloading the page (use AJAX)"

However, I then get the message "There was an error while submitting the form", which I believe is triggered by the d() call.

Is there a way to over-ride that check so I can use Kint to debug my forms?

Thanks.

(BTW - Kint also works with the Debug Bar plugin, which directs Kint's output to another location - but unfortunately that output also gets over-written when the page reloads.)

[Christian Cox]

I'm not familiar with this particular plugin, but I can check. Can you tell me exactly how you want to use this with Forms? Are you trying to debug the field values before the page with the Form is rendered, or global $_POST values, when the Form is submitted or form validation messages...?

[alexG-4]

Hi Christian

At the moment, its during my form validation, and also on completion.

Apart from this quirk, this little plugin has been a godsend to me. It's an incredibly easy way to see the structure of variables - invaluable to someone unfamiliar with the innards of WP and the conventions of toolset. Worth recommending to other users.

Thanks.

[Christian Cox]

Let's take Toolset out of the picture for a moment. What would happen if you used d($something) in a save_post hook? In my local testing, it blocks publishing a post. I'm not sure this debugger is meant for use outside a basic template. It seems like you would be better off writing to the server log and following it with tail -f for debugging purposes.

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');

Now in your code, you can write to the logs using error_log():

error_log('this is text');
error_log(print_r($complexValue, true));
error_log( 'now: ' . time() );

On the command-line you can tail that file, which will show you updates as they are written.

cd /your/root/directory/
touch error_log.txt
tail -f error_log.txt

CTRL + C to stop the tail.

[alexG-4]

Thanks Christian

That gives me a good alternative.

That last step is a new idea to me.

Is this the right place that documents how to set this up?
lien caché

I worked out another way to get at this easily: I display the error_log.txt in a browser window, and then hit refresh every time I send new output there.

Thanks!

Alex

[alexG-4]

My issue is resolved now. Thank you!

[Christian Cox]

Yes, if you're using a hosting company you would have to figure out how to ssh into your server to run this type of tail, and the document you linked to has some relevant information. I can't say for sure if it's accurate for your hosting company/service. At any rate, it sounds like refreshing frequently was effective enough to help you figure out the problem.