Filter gform_notification_email and global $post problem 1.5.rc3.4

Gravity Support Forums » Plugin Support » Gravity Forms

pronamic
Member

In the topic http://forum.gravityhelp.com/topic/sending-form-to-author-of-post i see some examples of how to adjust the notification e-mailaddress. Unfortunately this does not work on WordPress 3.1-RC2-17315 and Gravity Forms 1.5.rc3.4.

The global $post variable is in all cases 'null' within the 'gform_notification_email' filter.
http://pastebin.com/qENCX4wy

I guess this filter is not called within the WordPress loop (anymore?). I see that the processing of an form is executed within the 'wp_loaded' action.

add_action('wp_loaded', array('RGForms', 'maybe_process_form'));

It looks like WordPress is parsing the query variables after executing the 'wp_loaded' action. Therefore it is not possible to use the global $post variable or the query variables. The wp() function (global $wp->main()) function is executed after the 'wp_loaded' action.

I have found a way to fix this problem, but now the wp() function wil be called twice:

function notificationEmail($eMailAddress, $entry) {
wp();

global $post;

if($post) {
$eMailAddress = get_the_author_meta('user_email', $post->post_author);
}

return $eMailAddress;
}

I guess it's not meant to be to call the wp() function twice. Why do you use the 'wp_loaded' action hook for processing the forms? I guess this issue is also causing troubles with the use of {embed_post:*} variables (http://forum.gravityhelp.com/topic/variable-embed_post-not-working-15rc34). It feels kind a buggy and not well thought out.

Posted 13 years ago on Friday January 21, 2011 | Permalink
Alex Cancado
Administrator

We did make a substantial change in Gravity Forms 1.5 that is causing this issue. Previously, the form processing (entry creation, notification, etc...) was being executed with the form rendering logic, very late in the WP life cycle. That worked well in most cases, except when handling confirmation redirects. Because the confirmation was handled so late in the process, the HTTP headers had already been sent and we weren't able to perform a real redirect. We were forced to fully load the page and perform a redirect via javascript, which caused some issues and annoyances for our users. That issue became an even bigger problem with the PayPal addon, that requires a redirect to PayPal.
We decided to fix that problem by moving the form processing code way up in the life cycle so that we could perform a real redirect.

The wp_loaded hook seemed to be a good choice, but you do have a good point. I don't see a problem with the {embed_post:*} variables as they don't rely on the global $post variable and they seem to be working Ok. However, this does pose a problem for users that were relying on the global $post variable in their hooks.

I have played around with different hooks, and it seems like the "wp" hook is a better choice. It happens early enough that the headers have not been sent yet, but the global $post variable is already available.
Send me an email to alex@rocketgenius.com if you would like to try it out.

Posted 13 years ago on Saturday January 22, 2011 | Permalink
pronamic
Member

Is the 'init' action hook not a better choice?

The {embed_post:*} variables are working, but they are always replaced with the homepage post fields.

I guess the following code is causing this issue:

common.php:466
http://pastebin.com/w1H9uSr9
$embed_posts = $query->query($_SERVER["QUERY_STRING"]);

The $_SERVER["QUERY_STRING"] is empty in my case and WordPress didn't parse the (global) query parameters. How should $query->query load the correct post or page in that case?

See also:
http://forum.gravityhelp.com/topic/variable-embed_post-not-working-15rc34#post-16805

Posted 13 years ago on Monday January 24, 2011 | Permalink
Alex Cancado
Administrator

The global $post variable isn't loaded at that point yet (same problem as wp_loaded).
Do you have an issue with the "wp" hook?

Posted 13 years ago on Monday January 24, 2011 | Permalink