PLEASE NOTE: These forums are no longer utilized and are provided as an archive for informational purposes only. All support issues will be handled via email using our support ticket system. For more detailed information on this change, please see this blog post.

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

  1. In the topic 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.

    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) {

    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 ( It feels kind a buggy and not well thought out.

    Posted 13 years ago on Friday January 21, 2011 | Permalink
  2. 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 if you would like to try it out.

    Posted 13 years ago on Saturday January 22, 2011 | Permalink
  3. 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:

    $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:

    Posted 13 years ago on Monday January 24, 2011 | Permalink
  4. 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