On a site I administer there is a need to handle webform results, and have the admin view them, then convert some to content type. I am starting out with a custom module, have enabled the module, and trying to get the hook mymodule_webform_submission_presave to fire off when doing an edit, at this stage just print_r the $node and $submission, so I can see that it's getting that far, and what I have access to.
However many times I edit and save the webform result with garbage data, I'm not getting the print_r happening.

mymodule_webform_submission_presave($node, &$submission) {
  
 
  print_r($node);
  print_r($submission);
}

I've also tried _update.

Any clues what I'm doing wrong?

Accepted answer

Use the second parameter for print_r to tell it to return the output so you can display it raw or using one of the numerous output functions.  For example...

 print_r($node, true);

Also popular is using <pre> tag to format the output... 

  drupal_set_message("<pre>". print_r($node, true)."</pre>");

My preference is using devel's function, together with PHP's get_defined_vars ...

  dsm(get_defined_vars()); 

See https://www.php.net/manual/en/function.print-r.php ...

"Return Values

If given a string, int or float, the value itself will be printed.
If given an array, values will be presented in a format that shows keys and elements. 
Similar notation is used for objects.

When the return parameter is true, this function will return a string. 
Otherwise, the return value is true."

Also, this is often helpful when there is no place to display on the screen...

watchdog('mymodule', "submission: %submission", array("%submission" => var_export($submission, 1), WATCHDOG_DEBUG);

var_dump, var_export and print_r all have that same second parameter that returns structured output so it can be displayed or used as a string.

Being able to debug your $submission is key to webform development. You're on the right road. 

Enjoy!

Most helpful answers

Hey, nobody mentioned my best buddy, yet: debug()

It ships with core, so it's always available. Only when debugging views or other huge nested objects, things get hard (=slow).

This function is my Swiss army knife for every occasion. ;-)

I will if I can ever get more than a vanilla test site to install ;)

In the meantime "Drupal compatibility is enabled by default in the variable backdrop_drupal_compatibility within BACKDROP_ROOT/settings.php" as per https://docs.backdropcms.org/converting-modules-from-drupal

 

Might want to change that to:

  backdrop_set_message("<pre>". print_r($node, true)."</pre>");

Comments

Use the second parameter for print_r to tell it to return the output so you can display it raw or using one of the numerous output functions.  For example...

 print_r($node, true);

Also popular is using <pre> tag to format the output... 

  drupal_set_message("<pre>". print_r($node, true)."</pre>");

My preference is using devel's function, together with PHP's get_defined_vars ...

  dsm(get_defined_vars()); 

See https://www.php.net/manual/en/function.print-r.php ...

"Return Values

If given a string, int or float, the value itself will be printed.
If given an array, values will be presented in a format that shows keys and elements. 
Similar notation is used for objects.

When the return parameter is true, this function will return a string. 
Otherwise, the return value is true."

Also, this is often helpful when there is no place to display on the screen...

watchdog('mymodule', "submission: %submission", array("%submission" => var_export($submission, 1), WATCHDOG_DEBUG);

var_dump, var_export and print_r all have that same second parameter that returns structured output so it can be displayed or used as a string.

Being able to debug your $submission is key to webform development. You're on the right road. 

Enjoy!

Might want to change that to:

  backdrop_set_message("<pre>". print_r($node, true)."</pre>");

I'm aware of drupal compatibility and use it on a few sites.  I was just making the point that when writing afresh, it is best to use backdrop functions.

If you're having issues with getting your site to work @apperceptions, you may want to post specific queries in the forum or come along to Office Hours

Thanks, I don't need help. I need time :)

It's not an either/or with BD and D7, it's both. It will be for a long time still. Things that work seamlessly in both are best.

D7 is still my go to solution until I can get BD to work as easily, especially with existing sites. For new sites, I like BD. Also, there is the question of available and maintained modules etc. Many clients are still trying to move from D6! For most of them, the answer is D7 and then, maybe, on to BD, if the modules are there. Hopefully, I can help with that and convert a few in the process.

In the meantime, I've had more than my share of "the Drupal way" and not too open to replacing that nonsense with a new "way". I'll figure my own way, thanks.

 

indigoxela's picture

Hey, nobody mentioned my best buddy, yet: debug()

It ships with core, so it's always available. Only when debugging views or other huge nested objects, things get hard (=slow).

This function is my Swiss army knife for every occasion. ;-)